Re: QuickForm isn't

Hi, Seth Price wrote:

When I initially started having problems last year, I started extending the base classes to get the functionality that I wanted. After a significant amount of work, I was able to fix a few of my complaints. But I started to find things that couldn't be fixed without patching the main code, and then I started to tweak things where I knew that it would need much more work past the functionality that I used. And while rooting through the code, it had just gotten to the point where I felt that I was only adding more bloat that was causing me problems in the first place. Somewhere in there I gave up on something that others could use, and started working on something that would get me through my project. I was pretty sure I sent in patches somewhere, but I can't find an email where I did, so maybe I didn't. To show that I am not completely full of shit, here is a link to my package (no warranty provided with code, if I never think about it again it would be too soon, good luck): http://pricepages.org/temp/QuickForm.zip

Well, I had a brief look through your code (using a visual diff application) and must admit that your rants here contained a bit more symbols than your changes to QuickForm. Also I should congratulate you on doing some completely useless work. If you had a look at the actual DTD for XHTML, then you would have noticed that the contents of the name attribute of form elements are defined as CDATA, not as NMTOKEN. Therefore brackets [] are perfectly valid within element names. They are invalid in the id attributes, but no one actually forces you to have identical names and ids. As for allowing nested groups, this can't be *fully* implemented in current QuickForm version without Some Major Changes. And we'd rather not do such changes now, since they may lead to Some Major Bugs. It will be possible to nest Containers in QuickForm2, however.

I suppose that I should issue a public apology for the rant part of the rant. I had just wasted two days fighting with QuickForm, my tendonitis was coming back, and I was getting frustrated. This is after I spent several weeks last year fighting with it. Bertrand, Alexey, thanks for all your hard work on QuickForm, it really is appreciated in my own special way. But yes, the simplest quickform usage noticeably slows down the page. A complex form is like a DOS attack on my computer. Maybe it's just due to Mac's poor LAMP performance (which is also very true), and my computer is old anyway, but do I see the same problem when I upload the script to the Linux server.

That's strange, since Bertrand does his development on Mac. I am sure that he'd notice such issues if they were indeed common. I also think the only part of QuickForm that can have a *severe* negative impact on performance is the Renderer subsystem. What renderer are you using?

I wish that I kept some of my APD traces so I could show you. I called QF2 vaporware because I saw no package available for download on PEAR (even if alpha quality), doesn't everything condense from vaporware? Maybe my terminology is just confused?

http://en.wikipedia.org/wiki/Vaporware As you can probably see, the term has quite a negative ring to it. It implies that we promised something, but did not deliver.

That all said, after I recieved the first responses to my rant I started working on my own Form class. It won't be as full featured (or as complex) as QF or QF2, but it should do what I want with the minimum of extra code. I'm basing it on designs in QF and QF2, and you are free to use any of my code, but at the moment it is vaporware. ;) If there is interest, I'll post it to the list when it's usable.

Well, have fun. I'd like to point out, though, that I became QuickForm developer after I decided that maintaining the package itself is a bit easier than maintaining a private fork of it. On the other hand, I didn't start with pissing off existing QuickForm developers back then. :-D