cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Event handling in Woody
Date Fri, 26 Sep 2003 08:59:02 GMT
TO ALL:
I invite you to look at the "Various", "Flowscript" and "Car selector" 
Woody samples in the latest CVS. These demonstrate the styling and 
event-handling features I added to Woody, and I'd be interested in 
having feedback on this.


Marc Portier 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? 


Well, we can consider, as you say above, that the form is the 
articulation point between the user and the application. With this 
definition in mind, having elements in the form only related to this 
communication makes sense.

And this somewhat already is the case with the <aggregate-field> widget 
that holds data only of interest to the application. And will be also 
the case with the event-dispatchers we talked about. So I finally have 
no problems with having a non-visual <app-data> widget.

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


In that case, it's not only about verbosity, but about complexity caused 
by too much hyperlinking !

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


Cool.

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


Nope. No real useful example. And even less considering that 
"on-value-changed" is triggered also in the form loading phase.

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


Ok. I'll add it.

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

<snip/>

I solved points 3&4 as follows :
- <wd:action> are considered as "intra-form" actions : they never 
validate and always redisplay the form
- <wd:submit> (new widget that extends action) are considered as 
"form-exit" actions. They have an additional "validate" attribute that 
define if form validation should occur (true by default). For example, 
this allows a "cancel" button to be written as <wd:submit id="cancel" 
validate="false"/>

An noticeble thing, though : calling Field.getValue() _validates_ the 
field's value, meaning that even if the whole form should not be 
validated, local validation messages can appear, related to the event 
handlers that have been triggered. This gives some useful feedback to 
the user when an intra-form action cannot be performed because the 
fields used by this action are invalid.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message