[jira] Commented: (SHALE-423) Subdialog not returning to calling dialog
[
https://issues.apache.org/struts/browse/SHALE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40542
]
Ruben Stranders commented on SHALE-423:
---
This bug also affects version 1.0.4. I believe shale-usecases-1.0.4 is not
working properly because of this. Also, it seems that this bug is related to
[SHALE-386]. Try the following example (the simplest I could think of):
dialog name=dummy start=start
view viewId=/page.jsp name=start
transition outcome=success target=exit /
transition outcome=cancel target=exit /
/view
end name=exit /
/dialog
dialog name=dummy wrapper start=start
subdialog name=start dialogName=dummy
transition outcome=success target=success /
transition outcome=cancel target=cancel /
/subdialog
end name=success viewId=/success.jsp /
end name=cancel viewId=/cancel.jsp /
/dialog
Indeed, the view is sent back to /page.jsp after pushing the 'success' button.
If I push again, the view is correctly sent to success.jsp. Oddly enough, I
only have to push the 'cancel' once. After a little experimenting, it seems
that the order in which the transitions are defined whithin the subdialog
determines whether the button has to be clicked twice. Try swapping the
'success' and 'cancel' outcomes within the subdialog of 'dummy wrapper'. Now
the success button works, but the cancel button doesn't.
Subdialog not returning to calling dialog
-
Key: SHALE-423
URL: https://issues.apache.org/struts/browse/SHALE-423
Project: Shale
Issue Type: Bug
Components: Dialog
Affects Versions: 1.1.0-SNAPSHOT
Environment: Windows XP, Eclipse 3.2
Reporter: Per Jansson
When calling a subdialog from any other dialog, the sub dialog does not
return attention to the calling dialog. In my example use case a common
confirm page is to be shown (using subdialog) before returning to calling
dialog and continue.
..
..
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/
/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/
/view
end name=dummyEnd viewId=/jsp/common/dummy.jsp/
/dialog
If transition from view confirm is confirm the page flow ends up on view
/jsp/common/dummy.jsp instead of returning to the calling dialog and action
executeTransferAction.
For more information:
http://www.nabble.com/Shale-sub-dialog-tf3376354.html#a9399479
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHALE-409) Shale 1.0.4+ breaks AJAX4JSF
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40544 ] Todd Bush commented on SHALE-409: - Doing more investigation into this issue, I found the problem is within ViewPhaseListener.afterRenderResponse. Within this method, the code is basically removing all entries within the RequestMap during the second loop through the map. Since AJAX4JSF relies on requestMap entries while parsing the outgoing HTML, all expected entries are missing. Once I commented out the second loop, AJAX4JSF works correctly. I'm sure any other technologies which rely on requestMap entries after the render response phase will suffer from a similar problem. Thanks Shale 1.0.4+ breaks AJAX4JSF Key: SHALE-409 URL: https://issues.apache.org/struts/browse/SHALE-409 Project: Shale Issue Type: Bug Components: View Affects Versions: 1.0.4, 1.0.5-SNAPSHOT Environment: WinXP, AJAX4JSF-1.0.6, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View) Reporter: Todd Bush I've successfully implemented AJAX4JSF-1.0.6 with Shale-1.0.3, but when I attempt to upgrade Shale to 1.0.4 (also 1.0.5-SNAPSHOT) the a4j functionality stops working. I receive no stack trace or other server side error. I do receive a javascript error A4J is undefined. Viewing the output when running Shale-1.0.3, this javascript URL reference exists or A4J ... !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:acegijsf=http://sourceforge.net/projects/jsf-comp/acegijsf;headtitle/title!-- HTTP 1.1 -- script type=text/javascript src=/crown/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.xhtml /scriptmeta http-equiv=Cache-Control content=no-store /!-- HTTP 1.0 -- With Shale-1.0.4, the same page is missing the javascript URL reference for A4J ... !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:acegijsf=http://sourceforge.net/projects/jsf-comp/acegijsf;headtitle/title!-- HTTP 1.1 -- meta http-equiv=Cache-Control content=no-store /!-- HTTP 1.0 -- Also, a Nabble references detailing the same problem http://www.nabble.com/Solved!-A4J-is-Undefined-t3152071.html http://www.nabble.com/AJAX4JSF---Shale-1.0.4-t3148641.html Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHALE-419) Translate Shale/Clay/Dialog resourcebundles to Norwegian
[ https://issues.apache.org/struts/browse/SHALE-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hermod Opstvedt resolved SHALE-419. --- Resolution: Fixed Available in nightlies from 20070314 Translate Shale/Clay/Dialog resourcebundles to Norwegian Key: SHALE-419 URL: https://issues.apache.org/struts/browse/SHALE-419 Project: Shale Issue Type: Improvement Components: Application Affects Versions: 1.0.4 Reporter: Hermod Opstvedt Assigned To: Hermod Opstvedt Priority: Trivial Just to make sure I remember to translate the resourcebundles into Norwegian. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
