Hello Rhett,
That's not at all a bad idea! I keep forgetting about the fact that classes
themselves are generic. I'd still have to make a subclass of finder to add the
extra class parameter to my resource (I really like the idea of creating a
resource per request, mostly for the reasons stated in this thread already).
That, however is not a big deal.
------------------------------------------------------------
Kyrre Kristiansen
--- On Tue, 7/4/09, Rhett Sutphin <rh...@detailedbalance.net> wrote:
> From: Rhett Sutphin <rh...@detailedbalance.net>
> Subject: Re: Resource factories
> To: discuss@restlet.tigris.org
> Date: Tuesday, 7 April, 2009, 5:49 PM
> 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
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1579419
