Re: Account Request : phpHtmlLib

<waboring@3gstech.com> wrote : > 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. I think you are going a bit too fast here. :) I have looked at the form code of phphtmllib and I did not see what QuickForm is not able to do already, apart from the svg/wml/xml stuff but that's another story and IMO doesn't have much to do with HTML forms. ATM, the form processor, if I am not mistaken, is only posting (why not allow to use $_GET BTW ?) a hidden value to let the object know what's going on. This is not safe, hidden fields can be modified by user before being posted. And this can already be handled by the developer in a flexible way. For instance, what if you have 2 or more actions for your form ? IMO, if you want to make a form processor, you should use sessions. QuickForm uses element objects. Developers can add their own elements too, there is for example a date element, and a javascript calendar popup coming in the next release. I guess it's what you call widgets ? We also have renderers, something I haven't seen in phphtmllib, that are very flexible and can be customized, using pear template engines or any other engines. If I am not mistaken, phphtmllib looks more like a framework and as such will be very difficult to integrate in PEAR, and probably in any existing application. What we've tried to make with QuickForm was just about dealing with HTML forms. If you want layout, then use a template engine. If you want validation, then write your validation class. If you want to process the data, then use DB_DataObject or whatever, you don't have to write a wrapper around a wrapper. This makes the use of QuickForm very flexible in any kind of environments. >> 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. Obviously, you don't know what you are talking about here. HTML_Table_Sortable doesn't exist yet AFAIK, and was supposed to be an extension of HTML_Table. An extension, by definition doesn't reinvent the wheel, it uses the wheel. And for HTML_Select_Common, it has nothing to do with QuickForm, I already said I was against this package, which in fact is just a silly data container and as such should be called HTML_Silly_Datacontainer_States, HTML_Silly_Datacontainer_Countries... As a reminder, I would just say that phplib, binarycloud, midgard and other frameworks didn't make it into PEAR for the same reasons, because they could not be used as independent components. That's the main problem I see with phphtmllib, even if its code and API is nice and well thought. I would suggest you rethink your proposal for more independent pieces that could work together and with other existing pear packages. Bertrand Mansion Mamasam