Re: Account Request : phpHtmlLib

Personally I think phpHTMLLib excellent and should definately be part of PEAR in some form. It has the potential to help us parse ASP.NET pages, something which I've experimented with here: http://www.sitepointforums.com/showthread.php?threadid=112379 Most important is I think phpHTMLLib brings a solid and mature API to PEAR which other related classes could conform to. As I see it phpHTMLLib comprises of three main parts (correct me if I'm wrong here Walt); - The core XML vocabularies with the base class XMLTagClass which make a solid basis for representing any XML vocabularily. - The widget classes which is where you'd extend to build a class for rendering HTML calendars for example (HTML_Table could be ported to extend phpHTMLLibs basewidget class for example) - The form processor By having a solid API to conform to, we can help prevent some of the wheel re-invention that seems to be happening with classes like HTML_Table and HTML_Table_Sortable or HTML_QuickForm and HTML_Select_Common. Otherwise phpHTMLLib is mature and rich (the widgets available would already add alot more to PEAR::HTML_).

It seems to me that you should break it up into various elements or else call it a template system (e.g., HTML_Template_PhpHtmlLib).

Think it's important to understand that phpHTMLLib is not a template engine. It's a class library that can be used to build XML documents. It bears most similarity with QuickForms HTML_QuickForm_input class and subclasses but is alot richer in that it encompassed the complete HTML and XHTML vocabularies as well as SVG and WML. phpHTMLLib would be something that a template engine could use to "bind" a template to (i.e. template parser reads template and compiles into PHP script populated with phpHTMLLib class). Agree that it probably needs to be broken up a little to fit with PEAR. The UI_ namespace could be a really good move to place everything UI related in future. Perhaps the HTML_ namespace could be renamed UI_HTML_. Of course this breaks alot of backward compatibility or means extra work for maintainers. Alternatively divide phpHTMLLib up across multiple namespaces, using mainly the XML namespace then the HTML namespace for some classes as well as creating two more namespaces - SVG and WML. phpHTMLLib could then divide up like this; XML_Container (the base class of phpHTMLLib - currently Container) XML_BaseWidget (the base class for creating any widgets like calendars for example - currently BaseWidget) XML_TagClass (the base class for all XML vocabs represented by phpHTMLlib - currently XMLTagClass + XMLTag) HTML_TagClass (everything under phpHTMLlibs HTMLTagClass right now) HTML_ActiveTab, HTML_CSSContainer, HTML_DataList, HTML_FooterNav, HTML_ImageThumbnailWidget, HTML_InfoTable, HTML_NavTable, HTML_RoundTitleTable, HTML_TextCSSNav, HTML_TextNav, HTML_TreeNav and HTML_VerticalCSSNavTable (phew) - these are all of the HTML related widgets currently in phpHTMLLib SVG_TagClass (everything under phpHTMLLibs SVGTagClass right now) SVG_Graph (the widgets currently in phpHTMLLib) WML_TagClass (everything under phpHTMLLibs WMLTagClass right now) The form processor I'm not sure about. Perhaps HTML_FormProcessor ? I think HTML_FormProcess shouldn't extend XML_Container though. Anyway, reckon phpHTMLLib could fill a big gap in PEAR right now. The API is solid and could be the platform for all sorts of "widgets" that make building PHP pages easy. It could also be the library that parsers like HTML_Template_Flexy "bind" to, as Alan's been doing with QuickForm so far. Looking forward to XUL support as well... Walt - hope you don't mind my suggestions - realise that makes alot of work for you - may be you could get some other maintainers to help out?