Can you elaborate on the first two bullets (*)? I'm not familiar with either.
I'm not inclined to be for the idea of mixing architectures by including action based struts in JSF/Shale so I'm not big on the third bullet (*). Shawn -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Wednesday, December 21, 2005 5:52 PM To: Struts Users Mailing List 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]
