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=1577974
