On 10/22/07, Matt Raible <[EMAIL PROTECTED]> wrote:
> One thing I think we should change is /orders/{id};edit to /orders/{id}/edit
> - much like Rails 2.0 supports.
Yep, shouldn't be too hard to support both really.
> Also, is "Resource" required as the suffix for classes? I think this is
> something that might turn off users because they're so used to using
> "Action". Can we make this customizable? If so, maybe we should allow
> "Controller" as well (if you want to attract folks familiar with Rails).
Nope, completely optional; I was just looking for something to help
distinguish them from regular Struts actions. Changing to Controller
might be nice for consistency as you mention.
> How does the rest-plugin work for Actions/Resources in sub-packages? Does it
> add an extra directory name in the URL?
Yep, just like regular zero config actions. The one major feature
that is missing is url templates, so you can specify something like:
/users/{username}/tags/{id} I'm thinking of adding support for
wildcards in namespace names to core to support something like this,
so that, in the end, the template could be specified on the action
similar to the Rest JSR.
> Lastly, I really like where you're going with this support in Struts,
> primarily because I believe there's a lot of good points in the "Life Above
> the Service Tier"[1] article posted to TSS recently. It'd be very
> interesting to develop a sample application that uses SOFEA principles -
> possibly using the rest-plugin and YUI. If SOFEA is a productive way to
> develop web applications for SOA backends, Struts (and other request-based
> frameworks like Stripes and Spring MVC) could be ahead of the game because
> they aren't as tightly coupled to rendering server-side pages as the
> component-based frameworks like JSF, Tapestry and Wicket.
>
> In reality, I doubt SOFEA will eliminate the usage of popular server-side
> page rendering frameworks like PHP, RoR, ASP.NET and all the Java ones.
> However, it would be nice to have a framework that supports both server-side
> and client-side pages and treats SOFEA architectures as first-class
> citizens. After all, what if the "component" is the widget framework (YUI,
> Dojo, Ext JS)? I believe components at the UI layer (instead of in the web
> framework) is a very compelling idea for companies that support "polygot
> programming". [2]
Completely agree. A lot of Struts developers have started moving to
more Ajax-centric approaches where the server-side is mostly static
html and DWR. I think that Rest provides a more useful and ultimately
flexible solution, especially if you get things like XML and JSON
encoding for free like in this plugin.
Which reminds me, this plugin is targeted towards HTML-based web apps
that want to expose their information in machine-readable ways (XML
and JSON), but another thing I'm thinking about is how to better
support the case where XML and JSON are the primary formats, but you'd
want a simple, automatic XHTML view to make testing and debugging
easier. For this, you'd want XHTML to be generated by the framework
from the data without needing to write custom templates. Still
thinking how exactly that would work, but it would be a huge
productivity tool to have an automatic XHTML view of your app during
the early stages of development.
Don
>
> Matt
>
> [1] http://www.theserverside.com/news/thread.tss?thread_id=47213
> [2] http://memeagora.blogspot.com/2006/12/polyglot-programming.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
