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 >> >