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 <[EMAIL PROTECTED]> 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
>
>
