On 3/12/07, Pich <[EMAIL PROTECTED]> wrote:
Hi! You understood my purpose of the common dialog correct, using it as a subdialog from any other calling dialog. I now changed the "common.confirm" dialog to this (I hope I understood your suggestion correctly): <dialog name="common.confirm" start="confirm"> <view name="confirm" viewId="/transfer_register_confirmtransfer.jsp"> <transition outcome="back" target="dummyView"/> <transition outcome="confirm" target="dummyView"/> <transition outcome="cancel" target="dummyView"/> <transition outcome="dialog:transfer.performTransfer" target="dummyView"/> </view> <view name="dummyView" viewId="/jsp/common/dummy.jsp"> <transition outcome="dummyTransition" target="dummyEnd"/> </view> <end name="dummyEnd" viewId="/jsp/common/dummy.jsp"/> </dialog> However, this hade no impact and I still ended up on dummy.jsp when clicking the button resulting in transition "confirm" on view "/transfer_register_confirmtransfer.jsp", and not (as I wanted) in the "executeTransferAction" action in the calling dialog. Do you think this is a bug?
Yes, this definitely sounds like a bug. Could you file an issue in our tracking system[1], please? Your example use case will be helpful in tracking it down. Craig [1] https://issues.apache.org/struts/browse/SHALE
Regards Pich craigmcc wrote: > > On 3/9/07, Pich <[EMAIL PROTECTED]> wrote: >> >> Hi, I have a question regarding Shale sub dialog. >> >> I have these to dialogs: >> >> ...... >> ...... >> <action name="prepareConfirmTransferAction" >> method="#{performTransferUseCaseBean.prepareConfirmTransfer}"> >> <transition outcome="success" >> target="confirmTransferSub"/> >> <transition outcome="failure" >> target="performTransferView"/> >> </action> >> >> <subdialog name="confirmTransferSub" >> dialogName="common.confirm"> >> <transition outcome="confirm" >> target="executeTransferAction"/> >> <transition outcome="back" >> target="performTransferView"/> >> <transition outcome="cancel" >> target="cancelTransferEnd"/> >> <transition >> outcome="dialog:transfer.performTransfer" >> target="prepareNewTransferAction"/> >> </subdialog> >> >> <action name="executeTransferAction" >> method="#{performTransferUseCaseBean.executeTransfer}"> >> <transition outcome="success" >> target="receiptTransferView"/> >> <transition outcome="failure" >> target="confirmTransferView"/> >> </action> >> ...... >> ...... >> >> >> <dialog name="common.confirm" start="confirm"> >> >> <view name="confirm" >> viewId="/transfer_register_confirmtransfer.jsp"> >> <transition outcome="back" target="dummyEnd"/> >> <transition outcome="confirm" target="dummyEnd"/> >> <transition outcome="cancel" target="dummyEnd"/> >> <transition >> outcome="dialog:transfer.performTransfer" target="dummyEnd"/> >> </view> >> >> <end name="dummyEnd" viewId="/jsp/common/dummy.jsp"/> >> >> </dialog> >> >> >> The problem is that when the subdialog reaches the dialog "confirm" the >> transition outcome does go back up to the calling dialog. For example, if >> view name "confirm" get transition outcome "confirm" page dummy.jsp is >> shown, and not executeTransferAction which I want. >> > > It looks like there's an issue with the end state of the subdialog. > What appears to be happening is that the dialog manager: > * Sees the "confirm" response from state "confirm" in the subdialog > * Transitions to "dummyEnd" > * Sees that this is an end state, so it exits > instead of displaying the associated view, > returning the same outcome that it was > entered with "confirm" > * This outcome is then used to drive the > transition from the "confirmTransferSub" > state. > >> I had this working with Shale 1.0, but since i upgraded to Shale 1.1.0 I >> have not been able to get this to work. Has anybody else this problem? > > The dialog functionality was substantially changed between 1.0.3 and > 1.0.4, so it looks like we introduced a behavior change. I presume > what you're really after is showing the confirmation dialog page > before returning to whatever main dialog called it (this is precisely > the kind of use case subdialogs were designed to support)? If so, try > making what is now the "dummyEnd" state a <view> state instead of an > "<end>" state, and have it transition to an end state next. > > If that works, we'll probably need to review how end states are being > processed to see what happened to the view id at that point. If it > doesn't work, then we'll definitely need a bug report so we can get > this addressed. > > Craig > > >> >> Regards >> >> Pich >> -- >> View this message in context: >> http://www.nabble.com/Shale-sub-dialog-tf3376354.html#a9396652 >> Sent from the Shale - User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Shale-sub-dialog-tf3376354.html#a9429909 Sent from the Shale - User mailing list archive at Nabble.com.