leo leonid wrote:
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
well, I think my point is that we are getting into a position where everyone develops a feeling of 'having a limited understanding'
simply put I hate it when I have to read every line of code to understand what a method is doing, and IMO, Leo, in those cases we should not hide behind some intelectual correct 'it might be my limited understanding'
so feel free to point us to these occasions whenever you encounter them, nobody should feel offended, right?
as argumented before: those cases prevent us (and potential new contributors) to efficiently send in patches to fix bugs and add functionality
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.
yep, that's the idea
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?)
if I get it correctly you're saying that the <ft:aggregate-widget> after transformation and styling is not showing the top-level validation errors
have you checked at which level we're missing this info? 1/ validation never executed on the form model level 2/ transformer doesn't inject the validation error in the fi: stream 3/ stylesheet ignores it
last remark makes me think we should probably provide some ft: tag to explicitely position those top level validation messages?
also, your report sounds like you have the 'visa' test-case for this ready? sharing it might give us a head-start to clear out (bugzilla sounds useful for this?)
/leo
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
