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]
