struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dusty <>
Subject Re: RESTful form tags
Date Sun, 22 Jun 2008 03:46:32 GMT

This brings up something I have been thinking about.  I have been spending
about 80% of my time in S2 and 20% in Rails.  I don't want to get
theoretical but I need to be a little abstract to make a point....I think.

There is a difference between RESTful design and REST implementation.  One
the design side you are trying to create a well organized set of resources
and a repeated programming convention that makes it easy for others to
follow.  On the implementation side you are concerned about readable-urls,
the same action producing xml/json/html, invoking actions based on HTTP
method, determining format by http header or file extension, etc, etc, etc.

I find that a readable, and guessable url api is over-valued.  Invoking
actions from HTTP method = over-valued as well as producing two different
formats with the same code by just changing the extension = over-valued. 
However, organizing your logic into resources and repeating how you do
things over and over is under-valued.

Creating a traceable path for not only future developers to follow, but for
you to follow yourself weeks/months later creates tremendous value for a
software project.  The more you magic you create and implementation you
hide, the less patterns emerge for developers to "follow".  There is no such
thing as Pure REST. 

Which brings me to my point, I think:  The implementation (technical) part
of REST is much easier in Rails.  There are two key pieces that make that
so.  1) They provide an easily configurable in/out routing system and b) The
S2 action/method metaphor is really trying to be the contoller/action
metaphor in Rails, but is limited by S2's original action class per method
pattern (which relates to the routing system).

In my UI I have things like <s:url/> and <s:form/> and <s:action/> that
going to need to address resources.  The routing system should make it easy
for me to both recognize incoming urls and to define rules for outbound url
html.  Is the answer to create a custom tag library for <s:form/> that hides
the url details? or use a <s:url/> and reference that in <s:form>.  I think
making the action param evaluate is moving in the wrong direction, making it
even more forced.  A centralized REST routing system would be better so that
we can just reference it when we need to talk to resources.

I think this is what is holding me back from using the REST plugin.  I have
plenty of S2 RESTfully designed applications, but without the routing
support I feel like I am fighting the framework to make it do things like
URLs that people think RESTful systems should do.

I have derailed a bit, but I felt like it was important.  So if no one can
grok this and run with it then -1 for Dusty for wasting your last 3 minutes.

Al Sutton wrote:
> imho the best way of doing this would be allowing the action parameter 
> of the s:form tag to be evaluated (according to the S2 docs it currnetly 
> isn't). That way people could use either <s:form action="/pet/%{id}" 
> ....>...</s:form> or construct something like /pet/%{id}/delete using a 
> URL object which is then handled by the existing rest code.
> This would eliminate the need for any more tags, which i think would 
> make things easier for others to get to grips with.
> Al.
> Jeromy Evans wrote:
>> Is there any interest in creating restful form tags?
>> I've created variations of the s:form tag (create, destroy, index, 
>> update) that simply and/or enforce the restful conventions.
>> Basically, the action attribute of s:form is removed and replaced with 
>> a resourceURI attribute that understands the convention and context.
>> eg. a create tag knows that if the current uri ends with 
>> "/pet/editNew" then the target URI is "/pet" (and the resourceURI 
>> attribute doesn't need to be specified).
>> I've found them a useful simplification.  Eventually the s:action tag 
>> also needs to be substituted with one that knows which method to 
>> invoke based on the current context.
>> I don't think these belong in the rest plugin as we eventually want to 
>> achieve independence of the tag implementation though.
>> Any interest?  If not I may just push them onto googlecode.
>> cheers,
>> Jeromy Evans
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View this message in context:
Sent from the Struts - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message