Re: Account Request : phpHtmlLib

Harry Fuecks wrote:

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

----The form stuff is more of an entire Engine, rather then just the FormProcessor class itself. The engine includes FormProcessor class -- which is contains the logic to process any/all forms (based on the engine). It handles errors, confirmations of data, success and enables the creator/user of the class to change how it manages the display/output of the state of the form. For example, you can tell the class to not automatically render the form errors. This lets you move the error display to another placement in the layout of the page, put it in a popup, hide it, whatever. There are a lot of little bells n whistles like this. FormValidation class -- which provides a base class for doing some basic types of form element validation. This class can be extended to provide localized error messages that come from any place you like. FormContent class -- which contains the form fields (FormElement classes), and the various methods to manage the data associated with the FormElements. It keeps the layout seperate from the management from the FormElement (form fields++) FormElement class --which is the base class for all form fields. A FormElement can be as simple as a password input box, or as complex as you like. The point is to make managing forms and data very simple. Take a look at the FECheckBoxList class. It is 1 FormElement that can easily be dropped into a form with 1 line of code. It handles a list of checkboxes w/ clickable text. || The Form engine could be its own project that could be broken up into the core, which would be: FormProcessor, FormContent, FormValidation, FormElement and the base FormElement children: FEText, FEPassword, FESelect, FECheckbox, FETextArea, FEButton, FEHidden and the specialized elements: FEName, FEEmail, FEEmailMany, FEDomainName, FEIPAddress, FENumberFloat, FENumberPrice, FEUrl, FEUrlStrict, FEListBox, FEMultiListBox, FEDataList, FECheckBoxList, FERadioGroup, FEYesNoRadioGroup. I currently have a FormWizard class under development that would allow you to chain Multiple FormContent child classes together to provide a step by step wizard interface .

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_).

--agreed. The API for phphtmllib has been around for a while now, and is completely stable. I use it on many personal projects, as well as on a few commercial products at my current place of employment. Our entire prouct is based on phphtmllib. It goes through QA daily.

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.

---the current FormProcessor and Form engine classes don't extend the XML containers now, so this is correct. It sounds like you are basically advocating a replacement of the current HTML_* classes with the phphtmllib API. Then, possibly reworking the HTML_* classes as they exist now to use the ported phphtmllib API. This of course would be a big change for me. I am sure there are folks that are currently using the HTML_* classes that might object to this. I am sure I can port the phphtmllib classes into pear to conform to your 2nd suggestion above in a few days of work no problem. If I were to move phphtmlib into PEAR as described above, it would provide a lot more features to PEAR for building/rendering XML based

entities in a W3C compliant manner.    There are a lot of subtle features that the phphtmllib API already provides, such as building W3C complaint XML/HTML/XHTML, SVG documents (WML is not part of the W3C).  Switching between HTML and XHTML (transitional, strict) is as easy as 1 flag change in a constructor of the HTMLPageClass. 
 The downside to breaking the API into several projects is how would one easily install all of the packages.  Say I wanted everything that phphtmllib provides today? pear install XML_Container

pear install XML_BaseWidget pear install XML_TagClass pear install HTML_TagClass on and on could there be a super package? pear install UI that would install all of the phphtmllib ported APIs/classes ? Also, where do stand alone functions fit into PEAR ? I have many "helper" functions that build tag classes with their most common used attributes. Such as function html_a($url, $content, $class=NULL, $target=NULL, $title=NULL); This builds an Atag with <a href="$url" >$content</a> and the $class, $target, $title attributes if they are non-null. There is a "helper" stand alone function for every XML, HTML, SVG, WML tag. All the tags that are defined in the W3C spec (WML isn't in the W3C) are supported in phphtmllib. I guess I would agree to doing the 2nd suggestion of breaking phphtmllib lib up as it exists today. Long term, I believe it would be a good thing for PEAR to have in its bag of tricks. The downside is breaking compatibilty with the current web apps that use phphtmllib. I guess I could create a compatibility layer for those folks (me included). This would be painfull in the short term, but I guess that is the price to pay for moving into PEAR. Long term, I think its a good thing. Obviously the first suggestion of creating a new UI category would be easier for me and current users of phphtmllib, but is it the right thing for PEAR? The key point I take out of this is, that its most important to move the API and the features into PEAR then it is to have "phphtmllib". Short term this is painfull for me as phphtmllib as it exists today would cease to exist. That being said, the long term benefit is a solid, easy to use API for all PHP users, which is one of the reasons I created phphtmllib to begin with. Walt