Re: [Text_Wiki] Text_Markup , some necessary evolution of Text_Wiki ?

Paul M Jones <[email protected]> Mon, 23 Jan 2006 09:40:24 -0600
Newsgroups gmane.comp.php.pear.devel,gmane.mail.eyebrowse.user
Message-ID <[email protected]>
Hi Bertrand,

Here's a link to the archive for a memory-refresher on the  
(vaporware) Text_Markup follow-on to Text_Wiki:

     http://textwiki.tigris.org/servlets/ReadMsg?list=users&msgNo=137

And now:

On Jan 23, 2006, at 9:10 AM, bertrand Gugger wrote:

> then I put some pressure on Paul, so Justin and I became devs on  
> Text_Wiki.

... pressure I was happy to receive, and thanks for doing so.  :-)


> Outer the improvements what will naturally give, some next  
> extensions will occur in the optional renderings:
> * pdf was planned and asked since long time
> * I examine the possibility to docBook a little
> * I have a quick made TiddlyWiki render, case somebody interested...

I've had a little look at DocBook too, and while we may not be able  
to do PEAR-Doc easily, DocBook itself looks not very hard at all.

> Naturally, I'm very happy about how all things turn out, I want to  
> thank Paul to have put that stuff in here ... and sure also the  
> numerous contributors.

My thanks to you and Justin and everyone else, too.  You guys have  
done a great, great job.  :-)


> Now, I believe that package has to evolve
>
> * first of all the doc is outside pear, I request it to be inside  
> (Paul ?) (rendering docBook belongs to it)
> * the name "..._Wiki" itself hides the real purpose, transforming  
> text and markup inside, I like the Text_Markup name which came out  
> couple of time (I would hate Text_Wiki2)

I like Text_Markup too (see earlier link).

> * we miss some global coherence tests as , say (html) <i><u> ... </ 
> i></u> and more ... I would point out Text_Markup mission cannot be  
> to correct but refuse, eventually

I completely agree; the next version (Text_Markup) needs testing as  
part of the contribution process.


> * the file structure of the package leads to too many files (as we  
> accord to the 1 class/ 1 file rule) but as such we slightly don't  
> respect the CS for naming classes and anyway:
> [bertrand@ancilla Text_Wiki]$ find . -name '*.php' -print | wc -l
> 481
> the next extensions will explode that to more than 500 classes.

Agreed that the filespace gets gigantic, but I'm not sure how to  
overcome that while keeping both flexibility and adherence to one- 
class-one-file.


> - we lack some practical examples

Yeah.  :-(



--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.   <http://solarphp.com>

Savant: The simple, elegant, and powerful alternative to
Smarty for templates in PHP.   <http://phpsavant.com>

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php