On Apr 8, 2004, at 8:54 AM, Marc Portier wrote:
Hi there,
just found a small glitch in the aggregate-binding which is somewhat related to a broader discussion IMHO
(yeah, I know its related to the bug we closed only yesterday, just that I found out a nicer test after that)
[just an apetizer]
The context under which I found the issue:
- definition holds an aggregate-widget (stolen from the aggregate binding sample from Vadim) the thing has:
Thanks for pointing this out. I ran into the same problems, but lacking the proof, I assumed the problem must be my limited understanding of cforms, as it is usual the case, and potentially with this one, too:
Well, apart from those datatype conversion issues, I'm malcontent with current aggregatefield and its widgets. Strictly speaking its the <ft:aggregate-widget/> that is IMHO insufficient conclusive. Since there was aggregatefield widget, "used to edit the value of multiple fields through one textbox" [wiki], I never considered it not complete without it's complementary widget.
Then the aggregate-widget have been introduced, and even though it's misleading name, I expected it to fill the gap, say, it could be "used to edit the value of one textbox through multiple fields". Partly it does it, but to notice some of it's shortcomings, consider the following use case: you need way to input for a 16 digit credit card number that needs to be validated in multiple respects (required, number, mod10), very similar to the one in the form1 sample, but different in the way you present the form to the user. Cause you want to ease correctly composing such a long number by splitting it up to 4 fields, 4 digits each, that then gets reassembled and validated.
But where I expected to get the validation errors assembled in a way as well, they just get lost, due to the widget replacement (of <ft:aggregate-widget id="visa">), hmmm, unsatisfying. (or do I get the whole thing totally wrong?)
/leo
