Re: QuickForm isn't

From: Date: Tue, 10 Oct 2006 23:00:02 +0000
Subject: Re: QuickForm isn't
References: 1  Groups: php.pear.general 
Request: Send a blank email to pear-general+get-25384@lists.php.net to get a copy of this message
Seth Price wrote: >I find myself drawn to QuickForm because I like the idea. Create >elements, define rules for them, add them to a form, and it does the >rest for you. It should be that simple. But I find myself fighting >with it. I feel like I should be able to develop faster, but I get >the feeling that I would have been better off without "Quick"Form. If it doesn't fit your requirements, don't use it, there are other form classes out there that might fit your needs better. >What is the best form building software out there? Does anything >exist? Am I just using the wrong language? Are all the good packages >written in Python and Ruby? There is nothing in Ruby like QuickForm. In Python, FormKit is a copycat. Other solutions like formencode do things differently. >I really haven't been able to find >anything. I understand that some of this is baggage due to PHP <= 4. >QuickForm2 is vaporware at the moment, and I don't know if it solves >any of these anyway. If QuickForm2 fixes these, count me in. Your >thoughts on any of these questions would be very much appreciated. QuickForm2 is not vaporware. It just takes time to write the code and organize the API. There are already some commits done in CVS and a wiki has been setup to discuss such things. >Why does QuickForm bother me so, you ask? Let me tell you where I've >been frustrated. Many of these are small things, and many were >bugging me a year ago, so sorry if I'm a bit fuzzy. > >- Perhaps the single largest problem with QuickForm is its bloat. >Should the argument be an array? An object? A string? Trick question! >It can be anything! To figure out what the arguments are, I suggest your read the manual and look at the examples. >I was working on a set of forms last fall, and >they were running slow. 30 seconds to render a form is pitiful. So, I >profiled it, and found that most of my time was spent in QuickForm & >parent classes, trying to figure out what type my arguments were. I'm >looking at the use of is_array(), is_string, is_object(), etc. Be serious, it doesn't take 30 seconds to render a form :) PHP being a dynamic language, the issue you are facing with types would not exist in Java or C. You might want to consider switching to another language. >Really, that's just disgusting. There should be one, simple, well >defined, set of arguments. If it doesn't work, throw an error and >crash. Programmers should just fix their own damn code. I ended up >doing everything right, so it used the fewest cycles, and the script >still takes forever to run. Too much bloat, plain and simple. Could be better, could be worse. >And if the one function doesn't work for some reason, there shouldn't >be 10 other methods that *might* do the job (or more likely they just >screw things up internally if you touch them). At most there should >be another, backup, powerful function that lets you really do >something advanced. And I shouldn't need to understand the entire >internal code path just to use it (been there, done that, wish I >could have that day+ back). > >- Groups and Arrays. I should be able to create dynamic forms, where >I don't know how many items there will be until runtime. QuickForm >seems to rely on the idea that everyone always knows the exact ID of >an element. This doesn't work for dynamically created elements. Wrong. >But hey, groups and arrays aren't valid XHTML anyway, because "[]" >aren't valid ID chars. So in my version of QuickForm I've replaced >them with a ":" separator. Just another ugly hack in already bloated >code. Not only ugly but also silly hack. >And how about that Array renderer also? When extending it I got the >distinct impression that I was pushing it to the limits. Especially >if you're trying to nest things in a tree-like structure. I had to >build a stack into the class to keep track of where I was in the form >structure. It looks to be a holdover from before PHP supported objects. QuickForm doesn't support tree-like structures or nested groups. This is documented. >- Advanced Validation. QuickForm has the basics covered, like "Is >there a value here?". Unfortunately, anything more complex is a pain. >For example, what I spent a number of hours trying to get a good >solution for this afternoon was if an option is selected in a given >select list, then validate a set of fields. Otherwise, ignore the >fields. What is the best way to $form->addRule() this?? It sounds >simple, but I can't find anything that isn't another ugly hack. Wrong. You have different kind of rules, you can write your own as well. You can also use addFormRule() if your rule is more complex. >- Javascript Validation. It's a pain in the ass to write JS for >QuickForm that isn't basic. A form with dynamically created groups is >impossible to get the needed IDs to use with document.getElementById >(), and really, I shouldn't need to anyway. Wrong. You can define element ids by yourself. >Also, if I want to create a dynamically produced .js file and link to >it from my header, I can't without rendering the JS, then removing >the <script> tags that are hard coded into the function. Useless. >- Access keys and labels. You'd think that a nice form class would >make it easier to make accessible forms, but it's a pain. Trust me. >But I've extended the renderer and done it anyway. Go me. Wrong. Just like ids, you can define accesskeys by yourself. If you want pure XHTML and labels, you can now use Mark's renderer: <http://pear.php.net/package/HTML_QuickForm_Renderer_Tableless/> >- Select element. There should be automatic validation. Maybe there >already is. I can't tell. This is indeed not in QuickForm but it is easy to implement by yourself. >I want some options disabled, I want >optgroups, I want a line selected by default, but not valid (ie >"Please select from the following options"). All of these should be >implemented, and some of them are in my version of >HTML_QuickForm_select but it's a real pain to have to extend the base >class when trying to use something in the basic HTML spec. Yes, I understand you want a lot but you don't do much to get it done. >Well here I am, and I have more complaints, but I feel like this is a >good place to start. I feel better after ranting on all this. Is >there a good, well designed, form class out there? Is QuickForm2 >heading in the direction to solve these problems? I would be willing >to help work on QuickForm2 but I have a project that needs to show >some progress quick. Sure ;) I could have guessed so. -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - blog

« previous php.pear.general (#25384) next »