On 1/25/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Rahul,
I do not completely follow you answer.
<snip/>
Let me take a quick detour, I'll come back to your specific questions
in a paragraph. Generally speaking, a dialog is meant to be a complete
model of the page flow for the task at hand, and shouldn't be
interlaced with any delegation to the faces-config.xml nav rules.
However, there are cases such as a site navigation menu bar that might
be part of the header / footer etc. for consistent site L&F, wherein
for a better separation of concerns for all the flows one may want
avoid modeling these "global" site navigation links into each dialog.
The code snippet I provided in the last message was meant to be for
such a scenario, where the "action" attribute of these header / footer
menu links has a MB expression which first stop()s the active dialog,
if it finds one, and subsequently can rely on nav rules in the
faces-config to render the appropriate view knowing that the dialog
has been properly terminated.
Assume the following:
1) stateId = "start"
Display the view /editVendor_1
Outcome Next state
-------- -----------
success page2
cancel end
2) stateId = "page2"
Display the view /editVendor_2
Outcome Next state
-------- -----------
success save
cancel end
3) stateId = "save"
Execute the action #{vendorDialog.save}
Outcome Next state
-------- -----------
success end
failure start
4) End state stateId = "end"
Execute the action #{vendorManager.listAllVendors}. faces-config.xml
will take over form here.
5) dialog-config.xml
<dialogs>
<dialog name="addVendor" scxmlconfig="dialogs/addVendor.xml"
dataclassname="com.foo.Vendor" />
</dialogs>
6) Using Shale 1.0.4
What does the dialog's scxml file look like?
<snap/>
Thanks for taking time to draw this out, heres the body of the
untested addVendor.xml file (I've folded most of the view IDs into the
state IDs but its possible to use <shale:view/> custom action if we
don't want to):
<scxml xmlns="http://www.w3.org/2005/07/scxml"; version="1.0"
xmlns:shale="http://shale.apache.org/dialog-scxml";
initialstate="editVendor_1">
<state id="editVendor_1">
<transition event="faces.outcome" cond="${outcome eq 'success'}"
target="editVendor_2" />
<transition event="faces.outcome" cond="${outcome eq 'cancel'}"
target="end" />
</state>
<state id="editVendor_2">
<transition event="faces.outcome" cond="${outcome eq 'success'}"
target="save" />
<transition event="faces.outcome" cond="${outcome eq 'cancel'}"
target="end" />
</state>
<state id="save">
<transition event="faces.outcome" cond="${outcome eq 'success'}"
target="end" />
<transition event="faces.outcome" cond="${outcome eq 'failure'}"
target="editVendor_1" />
</state>
<state id="end" final="true">
<!-- MBs specified declaratively (such as expr below) have to
return a String, though one may:
(a) discard the return value, or
(b) use a DialogContextListener to invoke procedural bits
instead-->
<onentry>
<var expr="#{vendorManager.listAllVendors}" name="discard"/>
<shale:view viewId="/foo"/> <!-- Lets say we want to end at /foo -->
</onentry>
</state>
</scxml>
Note that we did not use faces-config navigation here, which is
probably for the good since the entire page flow for this task is now
captured in this model.
Where does the code you mentioned below go and how is it called?
<snip/>
As mentioned above, that would be inside the method called by the MB,
if at all we wanted to stop an active dialog and delegate to the
faces-config navigation.
-Rahul
Paul Spencer
Rahul Akolkar wrote:
> On 1/25/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
>> I have a dialog that adds a vendor. If the dialog successfully add the
>> vendor, or the dialog is canceled, then I want to end the dialog with a
>> call to the action #{vendorManager.listAllVendors}. The view to display
>> upon the completion of the action is configured in faces-config.xml.
>> How to do I configure this ?
>>
> <snip/>
>
> For v1.0.4, this requires a bit of knowledge of the internals (the
> recent DialogHelper addition to trunk really simplifies this ;-).
> Knowing that the active DialogContext is stored as a request-scoped
> attribute with key Constants.CONTEXT_BEAN, its possible to end the
> dialog like so:
>
> <code>
>
> DialogContext dcontext = (DialogContext)
> FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get
(Constants.CONTEXT_BEAN);
>
>
> dcontext.stop();
>
> </code>
>
> You can guard the stop() with a not null and isActive() predicate, if
> deemed necessary. The good thing is this will also do the necessary
> book-keeping cleanup associated with the DialogContextManager for you.
> Assumes the view displayed (via the faces-config nav rule) is not part
> of any dialog at that point.
>
> -Rahul
>
>
>> Paul Spencer
>>
>
