Re: Account Request : phpHtmlLib

<alan@akbkhome.com> wrote : > Finally had a chance to look through phpHtmlLib. > > From what I can see, it is a extremely heavy way of representing all > HTML elements. + a few cute widgets (groups of HTML elements) > > One of the key features it shares with HTML_Common, is that it uses > private variables to store _attributes, _tag, _content. > It then goes on to use setters/getters for all these variables, and adds > a few utility ones (in some of the upper level classes), like > $htmlelement->set_class('someclass'); > $htmlelement->set_id('someid'); > > (at this point, I ran screaming and shouting, for god sake, HTML > elements are so simple, why not just have public variables, and save > memory, speed by just using variable access, rather than setters/getters...) > > On top of the ContainerClass + XML Class, which is pretty similar to > HTML_Common, except they actually implement renderers (toHtml), > > ontop of this, is the huge array of HTML_Tag_A, HTML_Tag_BR, > HTML_Tag_IMG etc. - while cute, a 1600 line file, to define stuff that > could be done in a few lines with somethink like a vistor class, and > with no major benefits... > > While I'm certain, there are people who are out there and like > developing like this, and I can see some value of it being in pear (I > dont think I'd be running to use it ;) > > Looking at it, I would say > = merge what's relivant into HTML_Common (make a fat class fatter), If you do so, I guess QuickForm will have to be renamed SnailForm. ;) > = rethink the Tag_A/BR/IMG... classes - just use a static array for flag > lookup, based on tags. Don't rethink them, just get rid of them for performance reasons and because, as you stated, they are pretty useless. Plus they will be a pain to maintain as new tags will probably appear from time to time, whether they will be xhtml or not is not the point. > = put the widgets under use the HTML_Widget_* +1 on this one, addition of widgets is an interesting idea. But IMO, these widgets will have to rely on something like HTML_Common (SVG_Common, WML_Common if needed) and that's probably not what Walt is wanting to do. > = change render to toHtml? - I think this is what PEAR has mostly used.. ToSvg, toWml, dnd while you are at it, change all the methods names to PEAR CS (no underscore). > I've not really examined the SVG classes, but I didnt find much more > than a set of almost empty clases representing all the SVG tags.. > > Have to admit, it makes HTML_Lite (what was > HTML_Element/HTML_Template_Flexy_Element) seem like a good proposition.. A good proposition for what ? Bertrand Mansion Mamasam