[woody] using on-activate handlers

[Jeremy Quinn <je...@media.demon.co.uk>]

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

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.

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

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?

Thanks for any suggestions.

regards Jeremy

Re: [woody] using on-activate handlers

[Jeremy Quinn <je...@media.demon.co.uk>]

On 28 Nov 2003, at 13:12, Jeremy Quinn wrote:

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

<snip/>

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

My apologies .... this issue is erroneous .... I found the fault, it 
was mine.

regards Jeremy

Re: [woody] using on-activate handlers

[Jeremy Quinn <je...@media.demon.co.uk>]

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

Re: [woody] using on-activate handlers

[Sylvain Wallez <sy...@apache.org>]

Jeremy Quinn wrote:

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

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

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

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

What do you think?

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

Re: [woody] using on-activate handlers

[Jeremy Quinn <je...@media.demon.co.uk>]

On 27 Nov 2003, at 14:17, Ricardo Rocha wrote:

>
> Jeremy Quinn wrote:
>
>> I am having problems using on-activate handlers.
>> <snip/>
>> Would it break Woody terribly if on-activate handlers could
>> be called BEFORE the row-action's action-command?
>
> Or, even better, two handlers: BEFORE and AFTER.
>
>> 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').
>
> With the before/after event model you could determine which row is 
> about to
> be deleted "before" and synchronize with the persistence layer "after".
>
> This could be generalized further to provide support for "before", 
> "on" and
> "after" handlers for a other types of events...

That sounds like a good idea

WDOT?

regards Jeremy

RE: [woody] using on-activate handlers

[Ricardo Rocha <ri...@apache.org>]

Jeremy Quinn wrote: 

> I am having problems using on-activate handlers.
> <snip/>
> Would it break Woody terribly if on-activate handlers could 
> be called BEFORE the row-action's action-command?

Or, even better, two handlers: BEFORE and AFTER.

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

With the before/after event model you could determine which row is about to
be deleted "before" and synchronize with the persistence layer "after".

This could be generalized further to provide support for "before", "on" and
"after" handlers for a other types of events...