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.
---apples and oranges. You are comparing QuickForm ( a form mechianism)
to tag rendering here. phphtmllib does both.
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.
---evidently you didn't look close enough. You can do a GET request if you like. The default
just so happens to be a POST, and you can easily have more then 1 action for a form. Obviously
QuickForm vs. phphtmllib's form engine are attempting to do similar jobs. That is fine, even stated in the
PEAR FAQ that there can be 'competing' projects. I'm sure I could go through QuickForm and find all
types of issues that phphtmllib's engine can do better. Thats not the point here. Just look at the different
template engines in PEAR. they all do the same basic thing of providing a template engine, but they still
coexist in PEAR.
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 ?
---no. You are referring to FormElement child classes. Widgets build complex reusable blocks for different types of
documents, XML, HTML/XHTML, SVG. Such as NavTable for HTML/XHTML (which is trivial to have HTML output
verses XHTML strict), and the SVG widgets for building SVG graphs.
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.
----phphtmllib is not a template engine. So this is moot. All of the rendering is done by
the classes themselves, and provide a multitude of features that a template engine has a hard
time doing, such as turning an html template to XHTML Strict and make both types validate in the
W3C validator. Anyways, I'm not trying to advocate how to build and render html. I'm just trying to get another
mechanism into PEAR that I already know is usefull for many folks.
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.
---there is no reason you can't use the phphtmllib form engine in the same manner. The layout
is seperate from the form processing. You handle the data how you want when the action is taken,
and you can do your own validation if you so wish. It can do a lot of things.
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
--the wheel he was talking about re-inventing here was phphtmllib and the widgets
it already provides.
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.
The way phphtmllib would be moved into pear would enable pieces to be used as seperate components.
You can just use the HTML classes if thats all u want, or the SVG
classes if thats all you want. I don't see
why the phphtmllib classes/api can't be moved into PEAR. No class structure will be everything to everyone
and its ok if you don't like it. There are a lot of folks that already find it usefull, as I do. I am still convinced that
there is room for phphtmllib and it's apis in PEAR.
Cheers
Walt