Re: Account Request : phpHtmlLib

<waboring@3gstech.com> wrote : >> 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. In FormProcessor, I see : /** * This method does the logic of * doing the form processing */ function _process_form() { $this->_form_content->form_init_elements(); if (!@$_POST[FORM_VISITED]) { $this->_form_content->form_init_data(); } It's using $_POST and it's hardcoded. Unless you override the method, it won't use $_GET. For the actions, you seem to use: define("FORM_ACTION", "_form_action"); $this->_form_submit_action = $_REQUEST[FORM_ACTION]; It seems you rely on the submit button value, which can cause problems in multilingual applications. Unless you use a hidden, in which case you endup with only one action. > 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. As for forms in PEAR, we already have HTML_Form, OOHForm and QuickForm. I am not against another package but it will have to fulfill a new need. Your form engine, as I said, does not provide anything new or better compared to OOHForm or QuickForm. That's the main reason why I don't see it making it in PEAR. > I'm sure I could go through QuickForm and find all > types of issues that phphtmllib's engine can do better. Please do... :) > 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. Template engines is a different topic that is prone to subversion. But the idea is that they provide different interfaces with more or less logic included in the template itself. In that sense, they all provide different added value to the user. >> 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. OK, I was referring to FormElement then. Anyway, the idea of widgets is interesting and definitely there is a need for that in PEAR. I don't know how this could be added from phphtmllib to PEAR, without the form stuff and by making it use HTML_Common and/or something more complex like your tag stuff. BTW, could you explain what's the idea behind the IMG, BR, etc. tags ? It looks like it adds a lot of overhead for doing simple things. >> 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. External renderers have been asked by users for a long time and they are definitely a must have in a form class. QuickForm uses a visitor design pattern for its rendering tasks. It makes it easy to add new renderers. By looking at StandardFormContent that seems to extend FormContent, I didn't find it very flexible neither extendable. >> 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. Do you have groups of elements ? How do you validate them ? I am asking because it has always been very tricky in QuickForm and I spent a long time working on that one. > 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. Well, I like the idea of widgets, just not the implementation. You might consider HTML_Table (in PEAR) as a widget. Please, look at how it's implemented and let me know how far we are from your idea of widgets. IMO, every HTML widget should rely on HTML_Common. Regards, Bertrand Mansion Mamasam