cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Mon, 08 Nov 2004 09:49:36 GMT
Jonas Ekstedt wrote:

>On Sat, 2004-11-06 at 16:13 +0100, Daniel Fagerstrom wrote:
>>Please submit your patch to Bugzilla so that it doesn't get lost among 
>>all the mails. See for 
>>instructions. It is also good to have a Bugzilla entry so that you can 
>>add refinements to your code there.
>I have wondered a bit about Bugzilla. Is it only supposed to be bug
>fixes that appear there or are ideas okay as well. I thought it might
>clutter the bug database if I introduced half finished stuff there.
We use bugzilla for new ideas and project planning also, not only as a 
bug db. Prefix the subject line with [Patch] and mark your patch as an 
enhancement. Of course you can new ideas and half finished stuff there 
as long as you describe what it is. It would be very bad if we didn't 
have a structured way for non committers to contribute ideas.

>>>Instead of the original RequestProcessor there is instead a
>>>WidgetPopulator. It works similar in that it is added as an attribute to
>>>the request in Form.js.
>>Why is it added to the Request, wouldn't it be more natural to bind it 
>>to a variable in the flowscript instead?
Never mind, it made sense when I read the code.

>>But as long as it is bounded to the widget hierarchy so that the widget 
>>hierarchy cannot be replaced by another model, does the widget populator 
>>by us something in its current form?
>Well I think it is useful to some extent. With the WidgetPopulator you
>can use JXTemplate to hide widgets instead of having to do it in flow
>setting individual widget states. This way none of the proposed logic
>widgets are needed (choose, when etc.).
AFAIR, choose/when is a replacement for union. Union is part of the type 
definition, while widget states for hiding and skip validation of parts 
of a form in a multi page form context is a presentation concern. I 
agree with that the WidgetPopulator is a convinient way to handle 
validation in a multi page form context. Possibly it could be to set the 
widget states for handling hiding and validation thru that mechanism, I 
have no idea how, though. And as I have described earlier in this thread 
I prefer the widget hierarchy to be a passive data structure that is set 
from a request processor.

>Another way of doing the same, which I think was the agreed upon way to
>do it is to populate all widgets that has a request parameter present.
>This works out the same way with one little caveat. Some day someone is
>going to do
><jx:if test="${user.role == 'admin'}">
>  <ft:widget id="bigDangerousButton"/>
>and will be in for a mighty surprise.
I don't follow you here can you give some more details for that scenario.

> On the other hand, as has been
>pointed out previously collecting widgets in a something like a
>WidgetPopulator won't work unless you use flow.
Why wouldn't it, can you give a pointer.


View raw message