struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: [shale] Dialog question
Date Wed, 25 May 2005 04:54:49 GMT
On 5/24/05, gvanmatre@comcast.net <gvanmatre@comcast.net> 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, gvanmatre@comcast.net 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message