Hi Sean, Initially, the framework used many interfaces and factories but as someone pointed to me (Henry Story I think), interfaces create a fragile API and you can't share logic. Once they are defined they can hardly evolve without breaking existing implementation classes. That why I progressively removed all interfaces from the API.
Concerning the suggested solution, I don't see how it requires you to subclass Router? Sub classing just Finder should be enough in your case. Also, in most situations, you shouldn't even need to subclass Finder. I'm open to continue this discussion for post-1.0 evolution. For now, let's gain more experience with the current API. I'm also interested in hearing more opinions on this. Best regards, Jerome > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis > Envoyé : vendredi 26 janvier 2007 21:15 > À : [email protected] > Objet : Re: Newbie question on the Resource changes in RC3 > > 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 > > >
