Hi Jerome, Jerome Louvel <contact <at> noelios.com> writes: > > You can get your state in two ways: > > 1) Get your Application instance via the Context > > As explained in the other email, you can do get you state inside your custom > Finder then use it in the createResource() method to populate your > resources.
Understood, and hopefully I made my point about why I am pushing for an alternative. > 2) Attach a custom Finder directly to the Router: > > Do: myRouter.attach(uriPattern, new MyFinder(context, myState)); > You are not obliged to use the attach() methods taking a Resource class as > parameter. Sure enough, this will serve my purposes. My concern about frameworks that require inheritance still stands (and I think the framework builder ought to be concerned too). I'm also sad that I have to extend Router AND Finder to get this to work. The good thing, I suppose, is that I may be able to get away with only having two subclasses for all our apps. Of course, if my state changes dramatically, then I have to make more subclasses. My point being that developers using Restlet potentially suffer greatly if they need this capability. Seems to me it would be a much simpler model for a programmer to only have to create a factory. If I need another factory I can create one and it is sensible to do them as anonymous classes. The Routers and Finders on the other hand... > IMHO, the current solution is very close to what you propose, just consider > that the Finder class is similar to your proposed ResourceFactory. I think there are issues with the inheritance approach that not only put excessive burden on the programmer using Restlet, but may hinder evolution of Restlet. I'll leave it to you whether my arguments are compelling. I have the essentials to do what I want and that's good enough for now. Best Regards, Sean
