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
smime.p7s
Description: S/MIME cryptographic signature
