Hi Jerome,
> Hi Jerome,
>
> Jerome Louvel <contact <at> noelios.com> writes:
> > Hi again,
> > 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.
I had a chance to look at the new code and I'm afraid these changes are not
as helpful as I'd hoped.
The original problem was that I couldn't
parameterize Resources with my state because construction of resources
was controlled by the Finder which only understood two constructor
signatures.
With the above changes, I now have control over construction of resources
by extending Finder and overriding createResource(). The problem is that
I can't parameterize the Finder because, just like with Resource
before, Finder construction is not under my control. I cannot say:
new Finder(context, myState);
The Router insists on it's known constructor forms so I can't set state.
I still think the right answer is to allow use of a resource factory.
So a way to do this is to add a constructor,
Finder(Context context, ResourceFactory factory)
The code in createResource checks for and uses the factory, else it does
what it does now.
In Router, add:
attach(String uriPattern, ResourceFactory factory)
attachDefault(ResourceFactory factory);
I think that does it.
Sean
