Re: Re: [Text_Wiki] Text_Markup , some necessary evolution of Text_Wiki ?
Seth Price <[email protected]> Mon, 23 Jan 2006 10:07:45 -0600
| Newsgroups | gmane.comp.php.pear.devel,gmane.mail.eyebrowse.user |
|---|---|
| Message-ID | <[email protected]> |
I should point out that more information about my version of HTML_BBCodeParser can be found here: http://beeblex.com/lists/index.php/php.pear.dev/40992 >> * 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. You guys should pay more attention to my posts about HTML_BBCodeParser. I already have code like that written for HTML_BBCodeParser, and it is not tied to XHTML. It already validates the correct nesting of tags. It can then "refuse" as you said, but it can also simply ignore bad tags, delete them, or correct them. The default is to correct the bad tags when possible. It can validate and correct (or refuse, if you set the option) anything with an XML-like nested structure. > 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. You could always use a structure more similar to HTML_BBCodeParser, but I was hoping to get away from that, because I like the structure of Text_Wiki better. Maybe some sort of hybrid is in order. While I'm on the subject, I just got done with a rather nice (IMHO) ASCII renderer for my version of HTML_BBCodeParser. You should be able to transplant it into Text_Markup if it's better than what is already in Text_Wiki. ~Seth On Jan 23, 2006, at 9:40 AM, Paul M Jones wrote: > 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 > > > -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php