cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: [woody] using on-activate handlers
Date Fri, 28 Nov 2003 13:12:38 GMT

On 27 Nov 2003, at 23:41, Sylvain Wallez wrote:

> Jeremy Quinn wrote:

Thanks for your response Sylvain.

>> Hi All
>>
>> I am having problems using on-activate handlers.
>>
>> I have them attached to several buttons, but they do not really help.
>>
>> I have one attached to a <wd:row-action id="delete" 
>> action-command="delete"/>, but it appears to get called after the 
>> delete, so I do not appear to be able to find out which row was 
>> deleted, so I cannot remove that object from the persistence layer. 
>> (the returned index is '-1').
>
> Yep. Row actions are particular actions that have a built-in event 
> handler that is always called first. For this kind of application, 
> you'll need to use a "normal" action and remove the repeater row by 
> yourself as part of the event handler (a few lines of code, actually).

It worries me that I have to muck around with the internals of Woody to 
make this work.
Would I not be relying on the particular way this aspect of Woody is 
implemented?
What if that implementation changes in some way? It does not feel very 
robust.

>> I have one attached to a <wd:row-action id="down" 
>> action-command="move-down"/> and a <wd:row-action id="up" 
>> action-command="move-up"> button, but my handler gets called AFTER 
>> woody has moved them, complicating the issue of replicating the move 
>> in the BizData (the binding does not replicate the row order, so 
>> moves have no effect on BizData, if it is a Bean.)
>>
>> ie. calling event.getSourceWidget ().getParent ().getId () gives you 
>> the index of the row AFTER the move has already taken place.
>
> Same problem here...

What did you think of Ricardo's suggestion, the ability to specify 
whether the custom action is called before or after the built-in 
action?

>> Furthermore, because the Up button incorrectly shows on the top row, 
>> and the down button incorrectly shows on the bottom row, if the User 
>> clicks them, the row cannot be moved, so you get the 'correct' index 
>> of those rows.  =:-0
>
>
> Sorry, I lost you here...

I can see from the code in 
RowAction.Move[Up|Down]Action.generateSaxFragment that the code 
attempts to ensure that it does not place an Up Button on the top row, 
or a Down Button on the bottom row.

I was referring to the fact that this does not work in my circumstances 
(reason unknown, is it because I am using Beans?) because I do indeed 
see an Up Button on the top row and a Down Button on the bottom row.

Because the Binding code makes (in my case) the wrong assumption about 
the importance of ordering in my Bean's Collection, and fails to 
maintain that ordering when it copies updated row-data back to my 
Collection, I have to work behind Woody's back to replicate the move 
action on my Collection, by hand. (This in itself feels very strange, 
if you have a move action, why ignore the new order?).

Because I have to replicate the same move, and I need to know which row 
was moved, and my handler is called after the move has already 
happened; when I ask for the index of the moved row, I get the index of 
the row's destination, not the index of the starting point.

Because the the Up/Down Buttons are inadvertently shown on the Top and 
Bottom rows, handling those buttons becomes a special case ..... the 
index I get back from them will represent the starting point, not the 
destination, because Woody obviously could not move them.

This appears a bit fragile, if the underlying implementation changes, 
my work-arounds will break.

>> IMHO, this is making things a lot more difficult than they really 
>> need to be .....
>>
>> Would it break Woody terribly if on-activate handlers could be called 
>> BEFORE the row-action's action-command?
>
>
> You're the first one to report this kind of problems.

Sorry !!!
But I do believe I have a valid use-case ..... if I am finding these 
problems now, others will find them too ...

I only want to to see Woody as widely accepted, and useful as possible, 
please do not take what I say as criticisms.

> Two solutions come to mind:
> - change the order as you suggest it. It seems to make sense at first, 
> but won't someone come tomorrow with good reasons for doing it the 
> other way?

Allow the call-order to be specified with a new attribute, with 'after' 
being the default?

> - use a regular action and "manually" use the row-action's event 
> listener using its java class name, i.e.
>    <on-action>
>      <... your event listener here ...>
>      <java class="o.a.c...DeleteRowListener"/>
>    </on-action>

BTW. I cannot find o.a.c...DeleteRowListener, were you referring to a 
built-in class?

> What do you think?

Interesting ....

In the case of needing special Application-Specific handling of 
deletion, because I am using a particular back-end that has special 
requirements, it is *not* too much to expect me to provide that special 
treatment myself ;)

But in the case of Move-Up, Move-Down buttons, it seems I have to give 
them special treatment, because I am using a List of Beans, instead of 
an XML nodeset, and this seems wrong. If you have move buttons, the 
implication is that the order is important ;)

Should Woody behave so differently depending on whether your model is 
XML or Bean?

So, I think there are two issues here .....

1) It would make certain use-cases easier to handle if we could specify 
on built-in action buttons that the custom-action should happen 
'before' or 'after' the built-in action.

2) It does not make sense to have built-in Move Buttons, if the new 
ordering is not maintained for a List of Beans in 
RepeaterJXPathBinding.saveFormToModel.


As an aside, I attempted last night to begin to implement some custom 
event-handlers (to implement the above) in JavaScript. My handlers 
obviously need access to the Bean being edited, to apply the 
workarounds.

I found, as soon as I passed my Bean via showForm (screen, {bean: 
bean}) as viewData to my event handlers, I started getting some very 
strange exceptions. I have highlighted the issue in a post to Cocoon 
Users (not available in the Archives yet). The subject is: 'Re: 
deleting repeater-rows'. Unfortunately this problem appears to make all 
of the above pretty academic ;)

Many thanks for your feedback.

regards Jeremy


Mime
View raw message