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.
