Fair enough, maybe a little history would help: This project started as a Restlet to XWork bridge. After a bit, I realized there were some handy parts of Struts that I wanted to use, so I leveraged some of the Struts knowledge (e.g. FilterDispatcher, etc) to invoke xwork. Restlet is doing a nice amount of work for me managing the conversations.
The @URITemplate came from one of the APIs (don't remember which), but no associated tools are used. I simply snagged the name of the annotation in an attempt to be a little more conforming. All of the annotations are handled by the wirings in Spring (there's a page describing configurations, but any object factory should work). Bean descriptors (there are a few different types, 'annotated' being one) are used to configure both the Restlet and the Struts action components and link them together. Yes, the above descriptor configuration will supply the @ResponseClass information to the JaxbContext, making it able to marshall the XML automatically. Variations of the response are handled by decorating the xml marshaller with a JSON or Badgerfish implementation, specified by an "alt" parameter. Re: A list of the useful portions for struts, some points of interest: - caching: A Restlet eventually calls an xwork DefaultActionProxy through restlet handlers. Those handlers have various implementations for caching by associating a URI with the resulting XML entity. - general learning: different approaches give insight, or just seeing how something was implemented might generate ideas. - Using Restlet as a front end: Restlet does a bit of work (multiple params in uri, uri to restlet mapping, etc). This project really just binds a restlet to an action. It probably wouldn't be much to move that configuration (currently in a separate spring config) to the struts.xml. - Testing framework: it was pretty easy to build in a testing framework for the actions that runs in-memory or remotely. There are probably other areas of interest for both probjects (for example, this project doesn't yet use params to determine CRUD behaviors as it should). -Troy On Sun, May 25, 2008 at 12:10 PM, dusty <[EMAIL PROTECTED]> wrote: > > Coolness for sure. I noticed the @URITemplate annotation. That is from > the > WS-REST api? How is that implemented in your example? Is that through > Restlet? > > Is one of the values that it will automagically marshall the XML model > based > on the annotation @ResponseClass? What about a List of things? > > These are the two areas where I think it could help the Struts2 REST > implementation. I think a more "native" Struts2 approach is easier rather > than introducing Restlet in front of Struts. > > > > tdeast wrote: > > > > Hi all, > > I've been working on a project to provide restful services using struts2: > > http://code.google.com/p/fulworx/ > > > > I'm trying to gauge any interest on using any of the code / concepts in > > this > > project for the struts rest plugin. I believe some of the approaches > I've > > taken may dovetail nicely. My goal with this was making restful > > development > > as simple as possible. This project is not a plugin (hence it's not in > > the > > registry), but I'd rather it contribute to the existing plugin if > > possible. > > > > Any thoughts? > > > > Thanks, > > Troy > > > > > > -- > View this message in context: > http://www.nabble.com/Struts2-REST-project-tp17432050p17461247.html > Sent from the Struts - Dev mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
