Hi Kyrre, I would be interested to read more about the other resource patterns that you found. We might want in the future to support some of them in Restlet directly. We packages reorganization in Restlet 1.2, we have more room for this. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-----Message d'origine----- De : Kyrre Kristiansen [mailto:kyrre_kristian...@yahoo.co.uk] Envoyé : mardi 7 avril 2009 16:28 À : discuss@restlet.tigris.org Objet : RE: Resource factories Hello, all. *rant alert* I came over this discussion, and wanted to share my experiences with creating resources. I started playing around with restlet before it became 1.0, and am generally very, very pleased with it. One of the things I use it for is my own prototype environment, where I can throw together some quite impressive applications in a matter of hours.. After creating a whole host of different resource types, I started seeing some quite distinct patterns in my resources, at least the simplest ones. This resulted in using Generics on my resources, where I created a class, ListResource<T extends Referrable> (where Referrable is an interface, with one method, getId() ). I already have a generic DAO implementation based on the Referrable interface. In addition, I created a ResourceConfig<T extends Referrable> that I could pull off all the things I need for the ListResource (including the DAO, that's why it's parametrized), as well as a FormBuilder<T extends BaseObject> interface for building my objects based on a Form. All this leads to ListResource being a concrete class that relies solely on one object, the config, and that works with any resource that represents a Referrable subtype and is a top-level "list resource". This, however, is where my trouble starts. Because at run-time, the system cannot differentiate between a ListResource<Foo>.class and a ListResource<Bar>.class due to type erasure. At the moment I have to subclass ListResource for each type I am using it for, but hopefully making a parametrized Finder class that can then be attached to a Router, will solve my troubles. Has anyonw tried this? I have, BTW, also a solution for SingleResource<T extends Referrable>, but this is not used as much as my ListResource, so I didn't describe this. The big, unsolved task is to make the resources and interfaces available for more complex resource hierarchies where you have to check for the existence of a parent resource before you allow creation and modification of a child resource. Twenty or so more resource types under the belt, and I might get there ;-) *end rant* ------------------------------------------------------------ Kyrre Kristiansen --- On Thu, 26/3/09, Jerome Louvel <jerome.lou...@noelios.com> wrote: > From: Jerome Louvel <jerome.lou...@noelios.com> > Subject: RE: Resource factories > To: discuss@restlet.tigris.org > Date: Thursday, 26 March, 2009, 1:20 PM > > > > > > Hi all, > > I've just found time to read this thread and enjoyed it very much. > It's hard to find the best balance between so much points of views and > ways to deal with instantiations, wiring of objects, etc. so it's nice > to hear that the current design has more advantages than drawbacks. > > As Tal mentioned, we are redesigning the Resource API to support > client-side resources and focused use of annotations. I didn't intend > to change the way resources are instantiated though. But, if we can > adjust the new design to accommodate more use cases, I would be > interested to explore. > > > Currently, we are working on Restlet 1.2 M2 which will give you a > chance to play with the new resource API and provide feed-back. > > > > > Best > regards, > Jerome > Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios > Technologies ~ Co-founder ~ http://www.noelios.com > > > > > De : Tal Liron > [mailto:tal.li...@threecrickets.com] > Envoyé : jeudi 26 mars 2009 > 08:49 > À : discuss@restlet.tigris.org > Objet : Re: > Resource factories > > > > Thanks to all > who replied on this. After a discussion on the code list, > it became clear that > the Restlety solution to configuring resources is to use > the Context. The > Context has a ConcurrentMap of attributes, described as > so: > > "This > is a convenient mean[s] to provide common objects to all > the Restlets and > Resources composing an Application." > > > > So, that's it! > The nice thing about contexts, too, is that they pass > through restlets along the > way. So, even if you configure your Application context in > a certain way, you > can apply filters or whatnot along the way to adapt the > configuration. For > example, a DebuggingFilter might enable all the > configuration aspects that have > to do with debugging. It's then easy to add/remove such > a filter, even > on-the-fly, without reconfiguring the whole > application. > > > > > -Tal > > > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=15779 74 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1594985
