Re: Text_Markup , some necessary evolution of Text_Wiki ?

--Apple-Mail-28-814010762
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	delsp=yes;
	format=flowed

You guys are talking about a version 2 of Text_Wiki. I have already =20
written a version 2 of HTML_BBCodeParser, and have been thinking =20
about version 3. I think we have a bit that we can learn from each =20
other's packages. It sounds like you are mis-reading my words, and =20
assuming that it my HTML_BBCodeParser is only applicable to BBCode =20
because that is the package name. This is not so.

* It is not tied to BBCode, most of the code is only tied to stack =20
based parsing. *
The only code that is BBCode specific in the core is the parser. And =20
the parser can easily be changed to parse any tag-based code. (And =20
because it can parse all tags with only one regex, it is much faster =20
than the old parser or the Text_Wiki parser.)

A good object oriented design in Text_Wiki will allow for both Wiki =20
style tags, and BBCode/HTML style ones. Therefore, I think my parser =20
would be a good place to start for the BBCode/HTML tags, because of =20
its efficiency and speed.

* My version of HTML_BBCodeParser is also not tied to HTML. *
Just a few days ago I finished up an ASCII renderer for it. It is =20
more advanced than other ASCII renderers because it implements a =20
basic box model, and therefore can handle proper indenting of lists. =20
It also does line wrapping, to fit email widths. And it would not be =20
possible without a stack based validator.

You might realize at this point that HTML_BBCodeParser has outgrown =20
almost all jargon in its name, so that is why I was considering the =20
name Text_Markup for it. I think I have code that you could use.

Just a few days ago, I started designing what could amount to a =20
version 3 of HTML_BBCodeParser. Here are my rough notes about =20
requirements and design. It is similar to what Paul linked to. The =20
first half was written in a post to the QA list. The second half was =20
written simply to remind myself the design I was thinking of when I =20
have time to do more work on it.

 =46rom email Jan, 19th '06:
Examples of other things that I may like changed that would require =20
possible BC breaks [in my version of HTML_BBCodeParser]:
- Stack based renderer
	- This would allow easy use of things like Text_Highlighter in =
the =20
[code] tag. It is pretty, but I don't see a good way to use the =20
Highlighter as is.
	- But the best implementation of the new renderer would require =
more =20
filter changes.
- Why are all filters extended from BBCodeParser itself? It would =20
make more sense to simply use a BBCodeParser_Filter class. This has =20
led to odd bugs like #5844.
- Some of the tags behave unexpectedly, at least if you are used to =20
vBulletin, phpBB, and/or InfoPop style tags (example: [quote] tags). =20
Now would be a good time to change that functionality.
- Should newlines automatically be replaced with <br /> by default? =20
That is what I would expect. (But they aren't.)
- The parse() method seems mis-named. Not only does it parse, but it =20
verifies and renders too. We can keep qparse(), but I think that the =20
other methods should be sorted out to allow for more control. More =20
control would be useful when storing already-parsed-and-verified-but-=20
not-rendered tokens in database for performance reasons.
- The current code for adding and removing filters on-the-fly works, =20
but is kind of a hack to get around odd design stuff. I could rework =20
that.
- The filter's _definedTags format seems kind of dumb in places. I =20
could think of some more appropriate flags for tags.
- While I'm at it, I should take a look at Text_Wiki again. I =20
remember there were some nice things in there from when I was looking =20=

at that code...

More stuff Jan, 20th '06 [design ideas]:
- Stack based parser will do better with tags like [raw] and [pre] also
- Maybe a object approch similar to Text_Wiki, but stack based stuff, =20=

like HTML_BBCodeParser2
- Parsing:
	- Text_Markup calls Text_Markup_Parse_BBCode (subclass of =20
Text_Markup_Parse)
	- Text_Markup_Parse_BBCode calls all needed objects, like =20
Text_Markup_Parse_BBCode_Align. It is better this way because then =20
Text_Markup_Parse_BBCode can parse out all BBCode tags with one regex.
	- Other markup languages without tags can then act more like the =
=20
Text_Wiki parser and regex one token at a time.
- Validating:
	- Stack based validating through the renderer(s).
	- Call validate on whichever renderer you want to use, and it =
should =20
have the nessesary information to validate the tree. Keep the =20
validator from HTML_BBCodeParser
	- If you want to render to more than one renderer, then call =20
validate on each one of them.
	- Text_Markup_Render_XHTML::validate() subclass of =20
Text_Markup_Render::validate(), so validate can be overridden if =20
needed. I can't think of why that would be needed though.
- Rendering:
	- Text_Markup_Render_XHTML::render() subclass of =20
Text_Markup_Render::validate()
	- We can then use a stack based renderer, and do neat things...
- Output:
	- We can export anything rendered, but but for performance =
reasons =20
we might want to store validated text in the database.
	- Thus, we may want a serialized array as output.
	- But we should also include the version number so we can re-=20
validate if there is a lower version number.
	- To re-validate, we will also need to store enabled filter =20
information and other options.
~Seth

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

> Seth Price wrote:
>
>> It sounds like you are agreeing with my emails to the PEAR QA =20
>> list  about my version of HTML_BBCodeParser.
>
> No, I replied as I could , once.
> You finally persuded me this HTML_BBCodeParser is definitively =20
> deprecated
> or at least very oriented.
>
>> Here are links to copies of  the relevant emails.
>
> I follow all mails, they are nice archived now.
>
> Please, remind this thread is not specifical to BBCode. (I did not =20
> quote what is planned for this peculiar parser)
>
> Don't take my rudeness bad, I'm more about efficiency, possibly =20
> short minded.
>
> For the note, I have really some 100K sources I built only for the =20
> art of it , I don't care they are in trash, so wouldn't I for your =20
> code.
>
> I talk that way only in some hope of more cooperation.
> =E0+
> --=20
> toggg
>
>


--Apple-Mail-28-814010762--