[cforms] validation errors on (was Re: [cforms] widget values: set, get, validate, readfromrequest, parse, fireEvents,... generateSAXEvent)

[Marc Portier <mp...@outerthought.org>]

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/
mpo@outerthought.org                              mpo@apache.org

Re: [cforms] validation errors on (was Re: [cforms] widget values: set, get, validate, readfromrequest, parse, fireEvents,... generateSAXEvent)

[Marc Portier <mp...@outerthought.org>]

Vadim Gritsenko wrote:

> Marc Portier wrote:
> ...
> 
>>> 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
> 
> 
> 
> <ft:aggregate-widget/> does not output anything into the stream, that's 
> why validation errors are not shown on it. Either 
> EffectWidgetReplacingPipe needs to be changed, or you can simply use 
> <ft:validation-error/> to position and output aggregate widget's errors.
> 

thx for clearing out Vadim,

given the fact that the positioning remains an issue I think the latter 
is the correct way of working for aggregates that get split out in the 
template

> Vadim
> 

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Re: [cforms] validation errors on (was Re: [cforms] widget values: set, get, validate, readfromrequest, parse, fireEvents,... generateSAXEvent)

[Vadim Gritsenko <va...@reverycodes.com>]

Marc Portier wrote:
...

>> 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


<ft:aggregate-widget/> does not output anything into the stream, that's 
why validation errors are not shown on it. Either 
EffectWidgetReplacingPipe needs to be changed, or you can simply use 
<ft:validation-error/> to position and output aggregate widget's errors.

Vadim