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 http://wiki.apache.org/cocoon/ProjectManagement 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?
True
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"/>
</jx:if>
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.
/Daniel
