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
