You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by David Bowers <vi...@gmail.com> on 2005/09/29 00:41:39 UTC
[shale] I miss ActionForward.. am I missing something?
I am investigating using struts on an upcoming project, and I will need to
figure out a way to port some of my custom struts security preprocessing to
Shale. In my most current Struts implementation, I use a chain to test
several attributes on a request to authenticate it, (things like cookies or
whether the user needed authentication to view the current request) and
establish the session. If I need to forward a user to some intermediate page
for further security processing (like a login page), I changed the
ActionConfig attribute on the ServletActionContext, and then allow the Chain
to redirect the request according to what was I changed in the ActionChain
attribute. (If this doesn't match exactly with the current 1.3 release, it's
because I adapted the Chain part of it to Struts 1.2). I very much like this
seperation, where my security preprocessing commands are only concerned with
the Context, and I don't have to manipulate the Request in each Command that
might need to forward, include, or redirect.
As I look at shale, I don't see a way to do something similar. If I wanted
any Command in my preprocessing chain to redirect a request or process
something differently, it looks like I would have to manipulate the
HttpRequest object manually. Of course, I could build my own ForwardBean,
put that in the Context as a new attribute, and build my own machinery to
process this, but it seems like what I'm doing is a pretty standard type of
thing, and I'm wondering if I'm missing something since something like this
does not exist.
It seems like a simple Forward bean could be included in the Shale
framework, an attribute could be added to the ShaleWebContext for it, and
the ShaleApplicationFilter could pay attention to it, at least for the
preprocess part.
Also, in my current struts implementation, I assign custom security
attributes to each Action, and this is one of the things my custom
preprocessor looks at. If I were to move to Shale, it looks like the best
place to put these custom security attributes would on my backing beans,
unless I wanted a whole new configuration file for these attributes, which I
don't. Does that sound right?
Thanks in advance.
David Bowers
Re: [shale] I miss ActionForward.. am I missing something?
Posted by David Bowers <vi...@gmail.com>.
Just to try to understand this better... what if the pre-processor did
something like this?
FacesContext fcontext = swcontext.getFacesContext();
UIViewRoot newRoot = fcontext.getApplication().getViewHandler()
.createView(fContext,"login.faces");
fcontext.setViewRoot(newRoot);
return true;
Would I gain anything by doing it this way? The code is a bit longer. Or
would I actually lose a little bit of flexibility because I would have to
forward to a faces controlled view. One advantage is that I am not tied into
the servlet APIs. If I had control over what class was actually
instantiated, I could extend the ShaleWebContext and provide this
functionality in a single method: swContext.setViewRootString("login.faces
").
My preference would be something like this: which looks a bit more like
Struts classic. I would overload the constructor for MyCustomForwardBean (my
own ActionForward "replacement") with an optional boolean property for
redirects.
swcontext.setForward(new MyCustomForwardBean("login.faces"));
return true;
Then this command would be invoked as part of a chain nested under my main
pre-processing Command. When the nested chain completes, my "master"
pre-processing command would pull the forward attribute out of the context
and send it off appropriately. I really liked the abstraction from Servlet
interfaces that an ActionForward bean allowed.
On 9/29/05, Craig McClanahan <cr...@apache.org> wrote:
>
>
> It should not be necessary to manipulate the request object manually. The
> "preprocess" chain is executed by ShaleApplicationFilter (as the name
> implies) *before* FacesServlet is invoked ... and, from within a command,
> you can do either a redirect or a forward in the usual way. The important
> detail would be to make sure that your preprocessing command then returns
> "true" instead of "false" ... this tells ShaleApplicationFilter that you
> have already created the response, so it skips the usual chain.doFilter()
> call that passes the request along to the original servlet.
>
> To do a redirect:
>
> HttpServletResponse hresponse = (HttpServletResponse)
> swcontext.getResponse();
> hresponse.sendRedirect("foo.jsp");
> return true;
>
> To do a forward:
>
> ServletContext scontext = (ServletContext) swcontext.getContext();
> RequestDispatcher rd = scontext.getRequestDispatcher("/foo.jsp");
> rd.forward((ServletRequest) context.getRequest(),
> (ServletResponse) context.getResponse());
> return true;
>
> It seems like a simple Forward bean could be included in the Shale
> > framework, an attribute could be added to the ShaleWebContext for it,
> > and
> > the ShaleApplicationFilter could pay attention to it, at least for the
> > preprocess part.
> >
> > Also, in my current struts implementation, I assign custom security
> > attributes to each Action, and this is one of the things my custom
> > preprocessor looks at. If I were to move to Shale, it looks like the
> > best
> > place to put these custom security attributes would on my backing beans,
> > unless I wanted a whole new configuration file for these attributes,
> > which I
> > don't. Does that sound right?
>
>
> That would make sense. Then you can use <managed-property> settings in
> your faces-bean.xml file to set the appropriate security values, without
> having to hard code them.
>
> Thanks in advance.
> >
> > David Bowers
> >
> >
> Craig
>
>
Re: [shale] I miss ActionForward.. am I missing something?
Posted by Craig McClanahan <cr...@apache.org>.
On 9/28/05, David Bowers <vi...@gmail.com> wrote:
>
> I am investigating using struts on an upcoming project, and I will need to
> figure out a way to port some of my custom struts security preprocessing
> to
> Shale. In my most current Struts implementation, I use a chain to test
> several attributes on a request to authenticate it, (things like cookies
> or
> whether the user needed authentication to view the current request) and
> establish the session. If I need to forward a user to some intermediate
> page
> for further security processing (like a login page), I changed the
> ActionConfig attribute on the ServletActionContext, and then allow the
> Chain
> to redirect the request according to what was I changed in the ActionChain
> attribute. (If this doesn't match exactly with the current 1.3 release,
> it's
> because I adapted the Chain part of it to Struts 1.2). I very much like
> this
> seperation, where my security preprocessing commands are only concerned
> with
> the Context, and I don't have to manipulate the Request in each Command
> that
> might need to forward, include, or redirect.
>
> As I look at shale, I don't see a way to do something similar. If I wanted
> any Command in my preprocessing chain to redirect a request or process
> something differently, it looks like I would have to manipulate the
> HttpRequest object manually. Of course, I could build my own ForwardBean,
> put that in the Context as a new attribute, and build my own machinery to
> process this, but it seems like what I'm doing is a pretty standard type
> of
> thing, and I'm wondering if I'm missing something since something like
> this
> does not exist.
It should not be necessary to manipulate the request object manually. The
"preprocess" chain is executed by ShaleApplicationFilter (as the name
implies) *before* FacesServlet is invoked ... and, from within a command,
you can do either a redirect or a forward in the usual way. The important
detail would be to make sure that your preprocessing command then returns
"true" instead of "false" ... this tells ShaleApplicationFilter that you
have already created the response, so it skips the usual chain.doFilter()
call that passes the request along to the original servlet.
To do a redirect:
HttpServletResponse hresponse = (HttpServletResponse) swcontext.getResponse
();
hresponse.sendRedirect("foo.jsp");
return true;
To do a forward:
ServletContext scontext = (ServletContext) swcontext.getContext();
RequestDispatcher rd = scontext.getRequestDispatcher("/foo.jsp");
rd.forward((ServletRequest) context.getRequest(),
(ServletResponse) context.getResponse());
return true;
It seems like a simple Forward bean could be included in the Shale
> framework, an attribute could be added to the ShaleWebContext for it, and
> the ShaleApplicationFilter could pay attention to it, at least for the
> preprocess part.
>
> Also, in my current struts implementation, I assign custom security
> attributes to each Action, and this is one of the things my custom
> preprocessor looks at. If I were to move to Shale, it looks like the best
> place to put these custom security attributes would on my backing beans,
> unless I wanted a whole new configuration file for these attributes, which
> I
> don't. Does that sound right?
That would make sense. Then you can use <managed-property> settings in your
faces-bean.xml file to set the appropriate security values, without having
to hard code them.
Thanks in advance.
>
> David Bowers
>
>
Craig