Re: Resource factories

[Tal Liron]

Just to join the choir -- In addition to Rhett's standard solution, you can also use Restlet's application Context.getAtrributes() to set the referred type for each resource class, which they could then read at runtime. Just an option; I prefer Rhett's solution. By the way, having worked extensively with other run-time type information (RTTI) systems, such as those in C++ and in C#, I have to say that I really do consider Java's "type erasure" to be a feature. Sure, you have to do the work on your own, as in this case, but the automatic alternatives are all #$%#^$. At least you know exactly what's going in Java. -Tal Rhett Sutphin wrote: Hi Kyrre, On Apr 7, 2009, at 9:28 AM, Kyrre Kristiansen wrote: 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? This isn't specific to Restlet, but the way I handle this "feature" of generics is to define a method like this: public abstract class ListResource<T extends Referrable> extends Resource { // ... public abstract Class<T> referrableType(); // ... } If you wanted to do it in a way that doesn't require subclassing, you could do public class ListResource<T extends Referrable> extends Resource { public ListResource(/* whatever parameters */, Class<T> type) { // ... this.type = type; } public Class<T> referrableType() { return this.type; } } Rhett 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 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1579025