Hi again,
The ResourceFactory that you describe is already incarnated in the Finder
class whose main purpose is to "find" (and/or instantiate) target resources
for a given request. The default Finder class creates a new instance of the
target Resource class for each call but you can implement other strategies.
To facilitate the creation of Finder subclasses, I've exposed the
"resourceClass" property with a getter. I've also extracted the Resource
creation logic from Finder.findTarget() into a Finder.createResource()
method. By default, findTarget() invokes createResource(), but this should
facilitate the implementation of pooling mechanisms if required. Finally,
I've added a "finderClass" property on Router that will automatically create
the right Finder instance for you when calling attach("/uri/...",
myResource.class). Changes are already in SVN.
Best regards,
Jerome
> -----Message d'origine-----
> De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis
> Envoyé : jeudi 25 janvier 2007 21:41
> À : [email protected]
> Objet : Re: Newbie question on the Resource changes in RC3
>
> A couple other notes about the idea of a Application-defined
> ResourceFactory.
>
> It must be thread-safe.
> It provides inversion of control.
> It allows me to decide policy regarding Resource allocation
> (one-per-call,
> thread-safe stateless, singleton, pooling, etc).
>
> The more I think about it, the more I think this is a really
> good hook to
> have in addition to the basic attach("...", Resource.class).
>
> Sean
>
>
>
