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: [EMAIL PROTECTED] To: Struts Users Mailing List Sent: 12/21/2005 5:51 PM Subject: Re: [.do -> JSF/Shale] On 12/21/05, Garner, Shawn <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
