sorry for this late entry (quite off line this week)...
hoping the long wait didn't stop your thought train
(also haven't got time to check commit-mails so I don't really know how far you are already with this)
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
[on communicating from event handlers to controller]
Yep. But using hidden widgets for this doesn't seem the right solution for me. I thought of adding get/setAttribute on Widget (or only on Form?), but did not found a real need for it now. Maybe it's needed after all...
yes there is: as I explained there is obvious need for
1/ event listeners that only are responsible for dynamic effects on the 'view' (which can be handled by this)
2/ but in the general case there is obviously also need for event-listeners that hook up into the 'controller'
for the latter I find get/setAttribute only marginally better then hidden widgets: both add a loose contract where a strong one is possible, thus removing guidance from compile time check and introducing possible errors...
Mmmh... hidden widgets may actually be better in that case since they are typed, and can be checked at runtime since they have to be declared in the form definition.
What I don't like much, however, is that we introduce app-related things in the form definition. Or perhaps we should define a new <app-data> widget that is never sent to the client nor read from the request ?
We discussed some get/setAppContext() on the form before IIRC (when considering business related validation)
We somewhat agreed already then that it could be usefull, but I'm still not totally assured that it is really needed, nor if the form is the best place to put it.
In any case looking at your description of app-data: - never sent to the client - nor read from the request
we should ask ourself 'what has it to do with the form?' feels like dragging in concerns, no?
problem: event-handler needs to talk to controller! observation: they both know the form hack: lets abuse the form as the messenger?
I know above statement is putting it stronger then how I really perceive it, but I really want us to take a deep breath and think some more before just following the path of least resistance?
<snip/>
[on the event-dispatchers for everything]
Event-dispatcher may prove useful when there's a need to link the use-case controller to the widget tree, but I don't think everything should go through these dispatchers. In most cases, event handling will not require this relation to the controller and having to define a dispatcher for every widgets wanting to handle events will quickly become overly verbose.
I see your point. I guess I've been exposed to too much Java and XML: verbosity becomes a second nature ;-)
So I think we need both. And as I alreday mentioned, we can consider sending events to an event-dispatcher as a special case of event listener.
yes, that is the main point to hold on to!
I'll try to look to your additions asap so I can give the dispatchers a go as well
<big_snip>
Thx for removing my doubths on the changes for the repeater, although I will not have time until after the GT
</big_snip>
[other thoughts introduced...]
Some more thoughs that came to me :
1 - what about a <on-load> event handler that would be called once the widget tree is first set up ?
hm, for additional arbitrary setup that is totally form related and which you don't want to copy accross the different controllers that use the form (and would know themselves about the event anyway)
just out of interest: this means you would need to do things that currently can't be expressed in the woody-definition form? any examples in your mind already?
2 - I'd like to add a "disabled" property to <action> widgets. Depending on what happens on the form, we may want to allow or not certain actions.
yep
3 - I'd like to find an easy way to indicate if an <action> should terminate the form or if it's a intra-form action (such as add-row on a repeater) which leads to redisplay the form.
again this sounds (to me) like events that should go out to the controller that created the form which seems best entitled to close it down too.
in this case however the idea of some form related state 'displayOn/Off' being set makes more sense (then setAppData())
4 - similarily, I'd like to have a way to indicate if an <action> should try to validate the values. For example a "cancel" button will terminate the form without trying to validate it.
again, maybe just an eventhandler that can set a state-flag 'validationOn/Off' on the form?
For points 3 & 4, two solutions come to my mind :
- add 2 new attributes on <action> : validate="true|false" and end-form="true|false". Of course if validate="true", the form is redisplayed if validation fails even if end-form="true".
yes, quite a useful shorthand to the above event-handler that is setting form-state idea... (but essentially the same, no?)
- distinguish <action> and <submit> : an <action> would not terminate the form while a <submit> would. Both would have a "validate" attribute, but its default value would be "false" for <action> and "true" for <submit>.
What do you think ?
all makes sense IMHO.
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
