Actually it turns out that FacesContext is *not* available in the postprocess command. While I enjoyed the "learning experience" of how to set up my own precprocess and postprocess commands, I discovered I could not do what I wanted.
I checked the MyFaces implementation and verified that the FacesContext is "released" and the end of the service() method in the FacesServlet. DOH! If only Craig hadn't left us for vacation! He could of saved me some time :-( sean On 5/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Sean, > > > > The FacesContext would be avaiable in a registered preprocess or > > > postprocess > > > chain command. > > > Maybe a pre or post command could add a default Status to session scope, > > > mocking the DialogNavigation.getStatus(). > > > This might simulate being engaged in a dialog. I believe that the dialog > > > begins in reaction to invoking the navigation handler > > > and it is only invoked to respond to an action command. > > > > A postprocess command seems like it would do the trick. Thanks for > > the suggestion. I wasn't really familiar with all of the optional > > chain stuff you could do but I've done a little reading and I think > > you are correct. > > I believe that David Geary is starting Core Shale in (Oct.) after Ruby on > Rails > :-) > > > > > Do you think such a command might be useful in the shale project? I'm > > going to write one for myself but I could contribute the code (along > > with a working example) if this is useful for others. > > > One area of Shale that is in the works is AJAX support. The "remote" usecase > is > an example of how the backend would handle it. The implementation uses > commands > too. IMO, the more we encourage the use of javascript, the more people will > want this kind of feature. I would say that you should contribute your work. > I'm not a committer either. I've just been contributing by creating a > bugzilla > ticket and attaching the source. > > > > > > The action invoked in the popup would have to trigger a dialog status. I > > > see what you mean about the popup now. The page prior to the popup dialog > > > couldn't participate if a commandLink was not invoked. > > > > Right. This is my dilema. > > > > > I'm thinking that the FacesContext wouldn't be created yet. > > > > Good point (I hadn't thought of that.) I believe you are correct > > (FacesContext becomes available in service method of FacesServlet.) > > > > > I wonder if you > > > could create a component that performs a redirect or swaps out the view in > > > the render phase? You would have the FacesContext and you could use the > > > application to get the default navigation handler. Something like this: > > > > > > ViewHandler vh = context.getApplication().getViewHandler(); > > > UIViewRoot view = vh.createView(context, viewId); > > > context.setViewRoot(view); > > > context.responseComplete(); > > > > > > NavigationHandler nh = > > > context.getApplication().getNavigationHandler(); > > > nh.handleNavigation(conext, null, getNextDialogProperty()); > > > > I thought of this initially but it seems a bit odd to have a component > > whose only role is to "hijack" the JSF lifecycle. I do agree that the > > best way to handle this is by using the NavigationHandler and the > > stuff already implemented for dialogs if possible. > > I agree, the component is the wrong place for navigation logic. > > Gary > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
