Yeah, true enough. Although the 2 things I never "loved" with rails were resolving multiple action methods with all the different validations and before_ hooks, etc that you only wanted to run for one or two of the methods, and 2) empty active record models. But that's a different discussion :) I'll check out Vertigo and see if I can throw together some sort of hosted code. The problem with throwing plugins out there is I know I don't go near the ones that don't look active, so it's hard for me to expect someone else to.
On Fri, Feb 22, 2008 at 1:17 AM, Jeromy Evans < [EMAIL PROTECTED]> wrote: > Sounds good. If you can, I think you should share it. Host it at > googlecode, add it to the plugin registry and announce it on the users > list. There's plenty of S2 plugins hosted at googlecode, some that have > many downloads. If its popular and useful it'll soon be noticed. That's > how SmartURLs has migrated into the Convention plugin. > > The trouble with conventions, like one method per action vs multiple > methods per action, is that everyone has a different valid opinion. The > developer of the REST plugin chose to follow the conventions of > ruby-on-rails because its proven there. Your approach sounds good too > and I've also encountered the same issues regarding common behaviour for > methods (eg. for example, implement an Index interface and delegate when > appropriate). > > Brian P has also started an application stack including S2, conventions > and JPA on googlecode that's probably worth a look at : > http://code.google.com/p/vertigo-java/ > > I feel anything that increases the productivity of java developers is a > good thing, as is sharing what's been learnt. > > Blake Byrnes wrote: > > 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] > >> > >> > >> > > > > > > ------------------------------------------------------------------------ > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.516 / Virus Database: 269.20.9/1292 - Release Date: > 21/02/2008 4:09 PM > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
