Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (hermes.apache.org: domain of mfncooper@gmail.com
 designates 64.233.184.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=aPG7GykLwYfuMCdI25NFgVcwCZawLwWHh6psYmfnlI6ov56k4q9ZE5NLZdeAc2TgSzFT2KmIVN5ud7Lq1hCuMt/G8mCX9HEog4Ot/O1JyRV+t3pISjyflo4HCpg3X1g0tIQmX6mqpBKcnZXa6rHy8ncXhOM1oYGd5fcwcoyAyTQ=
Message-ID: <16d6c620050524215451c6ed2f@mail.gmail.com>
Date: Tue, 24 May 2005 21:54:49 -0700
From: Martin Cooper <mfncooper@gmail.com>
Reply-To: Martin Cooper <mfncooper@gmail.com>
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: [shale] Dialog question
Cc: Sean Schofield <sean.schofield@gmail.com>
In-Reply-To: 
 <052520050024.4266.4293C5AC000CD0D2000010AA22070016410A9D9B0E03020E9009@comcast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: 
 <052520050024.4266.4293C5AC000CD0D2000010AA22070016410A9D9B0E03020E9009@comcast.net>

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!
>=20
> 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 co=
ntext.  If the command was a Filter command the release could be in the pos=
tprocess method of the Filter command.
>=20
> >
> > If only Craig hadn't left us for vacation! He could of saved me some ti=
me :-(
>=20
> Forsure, I wish some of the the other struts guys would jump into shale. =
It would be rocking then.
>=20

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
>=20
> >
> > 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 Rub=
y 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 (alon=
g
> > > > 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 use=
s
> > commands
> > > too. IMO, the more we encourage the use of javascript, the more peopl=
e will
> > > want this kind of feature. I would say that you should contribute you=
r 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 st=
atus. I
> > > > > see what you mean about the popup now. The page prior to the popu=
p 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 th=
e view in
> > > > > the render phase? You would have the FacesContext and you could u=
se the
> > > > > application to get the default navigation handler. Something like=
 this:
> > > > >
> > > > > ViewHandler vh =3D context.getApplication().getViewHandler();
> > > > > UIViewRoot view =3D vh.createView(context, viewId);
> > > > > context.setViewRoot(view);
> > > > > context.responseComplete();
> > > > >
> > > > > NavigationHandler nh =3D
> > > > > context.getApplication().getNavigationHandler();
> > > > > nh.handleNavigation(conext, null, getNextDialogProperty());
> > > >
> > > > I thought of this initially but it seems a bit odd to have a compon=
ent
> > > > whose only role is to "hijack" the JSF lifecycle. I do agree that t=
he
> > > > 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