Re: HTML_QuickForm2 / new release

Hi Christian, Christian Weiske wrote:

The current released version crashes when outputting the form (CVS works) which is a big showstopper.

Can you clarify?

Of course. Just install HTML_QuickForm2 from pear (not the cvs version), create a new form object and echo it. You'll get a fatal error. This issue has been fixed in cvs quite some time ago, but it was a first "wtf?" when we tried out QF2.

Oh, thanks for clarification. In fact __toString() is defined in HTML_Common2 as abstract and thus should be implemented in HTML_QuickForm2. Since proper implementation would need Renderers, it was just made to throw an exception before these are done. I have no idea why PHP does not allow throwing an exception in __toString(). HEAD of current CVS has an implementation of Renderers done by Bertrand, there is also a branch out there with my implementation. We didn't consider either as ready for the release for some reasons, thus no release yet.

While I'm certainly tempted by your offer, I have a feeling that you and your colleagues haven't done necessary research before offering these resources: http://news.php.net/php.pear.general/29591

First - we're using QF2 only for some days now. Second - the colleague actually writing the QF2 code was already aware of this, just I didn't have the current knowledge level. Third - thanks for reminding me that asking questions is seen as a weakness.

OK, sorry for this, asking questions is not a weakness and I'm usually glad to answer them. It's just a matter of cognitive dissonance, when someone asks a basic question about a package that is quite complex even now (my checkout of HTML_QuickForm2 is close to 500 kb) and then demands application of their patches a couple of days later.

The first ones (ArrayAccess to e.g. use a form easily in Smarty, and rules in containers) have been attached to the tracker. We'd like to see them released soon so that we now that a) the direction in which we're going is correct and b) don't have to change our codebase afterwards too much.

"I want you to apply our changes NOW and release your package IMMEDIATELY so that we won't be burdened by keeping a private fork with the stuff only we need".

Alexey, I don't demand anything - I merely said that I'd be great if those patches could be reviewed, and if appropriate, released in a new version. If that would happen in time (soon), then we would have lesser burden with maintaining our own fork, that is correct.

I'd have no problems with your message if you did ask for a review, I had a huge problem only with "we'd like to see them released soon".

If there is anything holding you back or when the quality of our patches isn't high enough, just let me know and we do the best we can to meet your requirements.

The ArrayAccess patch http://pear.php.net/bugs/patch-display.php?> bug=15618&patch=HTML_QuickForm2.diff&revision=1231774581 violates the Principle of Least Surprise severely: $form['foo'] = 'text'; echo gettype($form['foo']); // Will output "object". WTF?

As Daniel already pointed out, with the increasing use of SPL some neat tricks get possible. While one might take a while to get used to, they help writing less - thus mostly more readable - code that does the same thing as method concatenation orgies. I also don't think that the behavior is such a surprise - who would use an object with array brackets [] if he didn't knew about the special interface?

Well, let's me put that another way. QF2 interface is modeled after DOM. So the shortcuts you propose are essentially shortcuts to DOM methods, correct? Accessing $form['foo'] maps nicely to getElementById(), in fact browsers behave quite like this. Now what is $form['foo'] = 'Whatever'; an equivalent to? setElementById()? Thankfully, DOM does not have such a method, probably because it won't make sense. There is also at least one other problem with accessing the elements this way in Smarty rather than passing them through some Renderer: javascript validation. It is form-wide stuff and should be built on rendering stage.

The Rule for Containers patch http://pear.php.net/bugs/patch-display.php?> bug=15619&patch=Rule_Compare_for_Container.diff&revision=1231775394 does exactly the same: If I do a $container->addRule('lt', 'Should be less that 4', 4); Do i expect 1) Container to contain less than 4 non empty elements? 2) Value of each element's in Container to be less than 4? 3) Sum of Container's elements' values to be less than 4? For those not bothering to read the patch: the answer is... (3)! Again, WTF?

I did not state that our patches are laid in stone and are correct.

But you did write "we'd like to see them released soon"...

I asked for feedback. The patch was actually something that solved a problem for us, and we implemented it.

Yes, that's what I said, it solves a very specific problem in a quite non-obvious way. A separate Rule modeled after Compare would be a lot better and won't require you to patch QF2. After all, we allowed adding one's own elements and rules for a reason.

The correct solution to the Smarty problem is of course an implementation of (some kind of) Array renderer, the correct solution of Rule for Containers problem is, probably, implementation of some kind of iterator for Rules. If you want to discuss the implementation details for these, then let's start by *discussing*

See above. We are willing to discuss and fix our patches. Teh problem with discussion is that nothing gets implemented. Having an implemented idea to discuss about is sometimes more productive.

In fact most of the features in QF2 were discussed a lot offlist between Bertrand and myself and described in the wiki before implementation.