On 5/24/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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! > > Could the context be created and released in the filter? I think that it has > a servletContext, request, response, and lifecycle in the shale web context. > If the command was a Filter command the release could be in the postprocess > method of the Filter command. > > > > > If only Craig hadn't left us for vacation! He could of saved me some time > > :-( > > Forsure, I wish some of the the other struts guys would jump into shale. It > would be rocking then. >
Speaking for myself, I'm not a JSF believer, so Shale isn't likely to "rock me" until there are some examples of how to use it without buying into the whole JSF enchilada, along with an explanation of why that would be a good thing for people not using JSF. Craig has said in the past that Shale isn't tied to JSF other than using some of the underpinnings, but I'm not seeing any evidence to support that in the code base today. -- Martin Cooper > Gary > > > > > sean > > > > On 5/23/05, [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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
