Hey Jeremy, Thanks for writing back. I was kind of starting to wonder if I wasn't supposed to be posting to this list :).
I really like portions of the REST plugin, but I wanted to be able to leverage a lot of the interface and class level patterns in Struts (ie, 1 class 1 action), so I ended up rewriting it to support class level actions grouped by package (instead of method level). My packages now have a GetAction, ListAction, CreateAction, RemoveAction, and New Action. Once I did that, I got a lot of freedom back to use the implementing patterns to do specific things that should always happen in a list action or a remove action. I also built it to support nested namespaces (similar to codebehind, but allowing nested resource ids and params as well), and to allow an annotation called AutoPopulate to allow JPA retrieval of objects between the Param id interceptor sandwich. I ended up with actions that hardly ever need configuration of any sort (inherited way to zero config). The REST plugin does handle json and xml responses, but I was finding that it didn't really work so well with hibernate objects. I also was mainly concerned with html fragments for Ajax requests and returning those. You can do this in the REST plugin programatically using the HTTPHeaders result, but I wanted something that guessed what I wanted by default, and let me override only when I needed to. Essentially, I wanted 1 method per action, default, inherited results, and the ability to override programatically. So my overall goal was to have really simple actions that could be reused by different content types and by ajax/regular html without much extra configuration or redundant request parameters. As far as I could tell in the REST plugin, the http methods against a resource are delegated to methods, but there wasn't a distinguished "ajax" handling of results by method. I've sort of rearranged that plugin to what I needed. I'm not even sure how to share back what I've got other than just posting them to a JIRA ticket or a sandbox and letting people take a look. Let me know how/if you are interested and I can put them up somewhere. (Maybe this should just go into another big plugin... my mini-framework also supports auto-back on post and a bunch of other things...). Blake On Fri, Feb 22, 2008 at 12:18 AM, Jeromy Evans < [EMAIL PROTECTED]> wrote: > Blake Byrnes wrote: > > I dealt with the ajax result discrepency (ie, if you make an ajax > request, > > you generally want a different result, but probably want to share the > same > > action) by writing a few things: > > 1) A sitemesh filter that ignores requests with the content header > > X-Requested-With=XMLHttpRequest > > > Nice idea. I'd been differentiating by extension (xhtml for ajax) which > has been getting out-of-hand. > > 2) An Interceptor and interface for dealing with Ajax requests that > allows > > you to specify a different result. The method is called "beforeResult" > > allowing you to change it if necessary. > > 3) A way to ask for views: sharing actions creates extreme complexity if > you > > have multiple pages that have different results under different contexts > > (ie, a get on a resource may return a specific html fragment if it is > > requested from a list view, which is different from what should happen > if > > it's requested from a regular "get" view on the resource). > > > > The REST plugin deals with similar issues through the RestActionMapper, > RestActionInvocation and ContentTypeHandler. > The first two for invoking the appropriate method and selecting a view > and the latter for handling other result types for the same action (xml, > json etc). > I think the REST plugin takes an excellent approach to this problem but > you may be able to apply some lessons learnt to them as well. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >