Re: Idea for a new Package - Chained Selectors

Hi Alan, Thanks for sharing your experiences with QuickForm, even if they seem to date back from QuickForm version 2. There are some points you raise that have been addressed and also some others that will be addressed in QF4 PHP5 version. Alan Knowles wrote: >I did spend (what must of been 2-3 months trying to integrate it as a >backend to Flexy), and in the end came to the conclusion it was not >technically feasible, and that having become familar with the design of >QF, I would be very unlikely to consider ever using it. QuickForm is already integrated with Flexy, using the Flexy renderer. Your attempts were made when there was no renderer in QuickForm so, indeed, I can imagine it might have looked technically infeasible. >Why? >- It mixes control (eg. it reads / writes $_GET/$_SET/$_SESSION), with >rendering, validation and data storage. (This is my biggest dislike of >the package, and I've made the same mistake in my code and regretted it >ever since. It causes considerable unpredictability to occur, when >working outside the standard operating procedures) QuickForm never touches the globals you are talking about (I guess you meant $_POST instead of $_SET ?). Eventually, it reads the content of either GET or POST in order to start the validation but it doesn't overwrite any submitted var. SESSION is only used by the controller and it is a different package. Eventually a QuickForm element could use SESSION in its own namespace for some required features. I have written a CAPTCHA element that uses SESSION to store the phrase. QuickForm manages the different processes of rendering and validation using a renderer and a validation object but those could also work independently, inside other packages for example. Using interfaces, it might also become possible to make them reusable with other packages that conform to a given protocol. It's funny that what you dislike is exactly what makes QuickForm useful :) >- The requirement of having to deal with &alias'es everywhere makes it a >minefield of potential mistakes. Yes, I hope we can fix that in version 4. The problem arises when you use groups, not with standard elements. >- It's not quick and simple to debug, print_r() on the main object >results in an excess of information. There is a toArray() function eventually. But this could also be worked out for version 4. >- The heavy use (an perhaps needless) of privates makes it almost >impossible to extend for other purposes. This will be clarified with version 4 thanks to PHP5. >- The migration path for QF to custom layout forms (that could be >visually designed by a wysiwyg editor) is messy to put it midly, (almost >all the form designs I do end up being visually layed out now - athough >alot are in XUL these days.) QuickForm provides renderers called 'static' which offer a total control of the design. So this point is IMO already addressed. >All that said, these are what my experience/opinion of the code is, and >I dont expect to find agreement in those points.... but I was asked why.... I hope you don't mind me clarifying some of your points. I appreciated that you took the time to explain your griefs about QuickForm exactly when we are in the process of planning version 4. This will hopefully make version 4 better, so do not hesitate to let me know if you think of something else or have any other idea. Anyone is invited to give some ideas. I have setup a wiki there: <http://www.mamasam.com/qf4> Bertrand Mansion Mamasam