RE: [.do -> JSF/Shale]

["Garner, Shawn" <sh...@pearson.com>]

 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.

All I want to do is use posted data (right now it is posting to
studentdata.do) 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.

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


Shawn

-----Original Message-----
From: craigmcc@gmail.com
To: Struts Users Mailing List
Sent: 12/21/2005 5:51 PM
Subject: Re: [.do -> JSF/Shale]

On 12/21/05, Garner, Shawn <sh...@pearson.com> wrote:
>
> so I can enter something like
>
> http://www.mycompany.com/mycontext/mymanagedbean.mymethod
>
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [.do -> JSF/Shale]

[Craig McClanahan <cr...@apache.org>]

On 1/2/06, Garner, Shawn <sh...@pearson.com> 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:

    http://localhost:8080/myapp/dynamic/mymanagedbean/mymethod.faces

(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!
    context.getExternalContext().dispatch(resultViewId);
    context.responseComplete();

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

All I want to do is use posted data (right now it is posting to
> studentdata.do) 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
trick.

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:

     http://localhost:8080/myapp/chain/foo/bar.faces

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
stuff.

Shawn


Craig


-----Original Message-----
> From: craigmcc@gmail.com
> To: Struts Users Mailing List
> Sent: 12/21/2005 5:51 PM
> Subject: Re: [.do -> JSF/Shale]
>
> On 12/21/05, Garner, Shawn <sh...@pearson.com> wrote:
> >
> > so I can enter something like
> >
> > http://www.mycompany.com/mycontext/mymanagedbean.mymethod
> >
> > 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>