struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [.do -> JSF/Shale]
Date Tue, 03 Jan 2006 01:16:23 GMT
On 1/2/06, Garner, Shawn <> wrote:
> I guess I don't understand either two methods of what your are suggesting.
> In using the remoting method I understand how the method is getting called
> however it is returning a list of things.  I want to go from there to one
> of
> the preconfigured jsf views.

You'll need to grab tonight's (20060103) nightly build to get the new
remoting code that I just checked in.  The included javadocs have some
reasonably extensive documentation on the Package Description page for the
new "org.apache.shale.remoting" package.

With that code, you'll be able to receive a URL of something like:


(assuming you have FacesServlet mapped to "*.faces"), which will formulate a
method binding expression "#{mymanagedbean.mymethod}" and then execute it.
The ".faces" part of the URL makes sure that the new JSF phase listener sees
this, which will find a match on the "/dynamic/*" pattern and execute the
Processor that does the method binding magic.

Within that method, you have some choices for how to create the response.
One way is to create it directly (like a JSF component renderer does) via
the ResponseWriter API.  If you've got a JSP page set up to do the response
already, though, you can do a RequestDispatcher.forward() to it:

    String resultViewId = "/ny/07/start.faces"; // Or whatever is
appropriate - note the .faces extension to trigger JSF lifecycle!

so you could dynamically calculate the context-relative path to the new

All I want to do is use posted data (right now it is posting to
> and decrypting the posted data and then going to a certain
> subcontext view  ny/07/start.jsp or ny/06/start.jsp or ia/07/start.jsp or
> ia/06/start.js based on values in the post.  This post will be coming from
> a
> customer's website which will encrypted and I have no control over their
> architecture or even which page they send from.  All I have control over
> is
> the URL on our site that they post the data too.

Using the request dispatcher approach, as described above, should do the

You said another approach other than remoting would be mapping distinct
> methods of a bean to a command.  Can you go over this method?

That doesn't exist yet, but it will involve implementing another Processor
mapped to a different pattern (say, "/command/*").  Now, envision that you
had a URL like:


which would pass "/foo/bar" in to the processor's process() method.  To act
like the old remote support, this processor could:

* Set up a ShaleWebContext (like the filter currently does)

* Look up command "/foo/bar" in the "remote" catalog

* Execute the command, passing in the constructed context

Within the chain, you could do exactly the same sorts of things you can do
directly in a method binding call, but gives you the flexibility to compose
the processing chain out of fine grained reusable commands (just like the
current remoting support does).

This is probably more work than it's worth for your specific use case
(compared to the method binding approach), but it will still be useful to
other folks who are already using Commons Chain for their business logic



-----Original Message-----
> From:
> To: Struts Users Mailing List
> Sent: 12/21/2005 5:51 PM
> Subject: Re: [.do -> JSF/Shale]
> On 12/21/05, Garner, Shawn <> wrote:
> >
> > so I can enter something like
> >
> >
> >
> > in my browser
> >
> > and it will call the mymethod method in my managed bean named
> > mymanagedbean?
> Shale won't directly do this for you today, but it would indeed be very
> easy
> to set something like that up -- the existing remoting facility maps
> context
> relative paths to a command (in the Commons Chain sense).  Any of the
> following approaches would be fairly simple:
> * Map all the interesting cases of "/mymanagedbean.mymethod" to a common
>   Command instance (that you would have to write at the moment) that
> would
>   inspect the incoming servlet path + path info and calculate the
> correct
> method
>   binding expression.
> * Modify the remoting support in Shale to do more generalized pattern
> matching
>   (versus straight string matching) so that you wouldn't have to
> literally
> configure
>   every possible managed bean method you want to call (presumably using
>   regular expressions or something).
> * Use an action oriented framework (Struts 1.x, WebWork, Spring MVC,
> etc.)
> for this
>   portion of your application, while using standard JSF stuff for the
> rest.
> On the first two points, you've piqued my interest enough to think that
> this
> sort of thing should be easier (in Shale) than it currently is.  The use
> cases for AJAX style requests (or, more generally, any sort of
> REST-style
> interface towards your application's mode data) are pretty compelling.
> The third point represents a personal bias that I will happily claim --
> if
> you are writing an application that is interactive with a *human* rather
> than with a *machine*, you shoud consider URLs to be an irrelevant
> implementation detail, rather than a fundamental architectural principle
> :-).  Yes, requirements for thngs like bookmarks complicate this a
> little --
> but application designers in an AJAX world are going to be faced with
> this
> kind of problem no matter what frameworks they are using.  What are you
> going to do if you end up using an AJAX-style approach that migrates the
> entire application into a singe page (which is an architectural style at
> one
> end of the extremes of what is reasonable with AJAX, but it's definitely
> going to need consideration)?
> Craig
> ****************************************************************************
> This email may contain confidential material.
> If you were not an intended recipient,
> Please notify the sender and delete all copies.
> We may monitor email to and from our network.
> ****************************************************************************
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message