Hi Ryan, The latest changes (default constructor) should make the integration with Spring easy. We already have several integrations examples at http://wiki.restlet.org If anyone is aware of any blocking issue for the integration of Restlets with such third-party frameworks, please let us know.
There is also an integration example with the JBoss Seam framework that was provided by Diggory Briercliffe and that he is currently improving based on latest Restlet changes. We will try to expand the documentation to cover those integrations in more details along the way. Best regards, Jerome > -----Message d'origine----- > De : Ryan Daum [mailto:[EMAIL PROTECTED] > Envoyé : samedi 27 janvier 2007 18:42 > À : [email protected] > Objet : Re: Newbie question on the Resource changes in RC3 > > For what it's worth, as much as I am enjoying using Restlet, > I think it's a mistake to go 1.0 without Restlet being > friendly with injection systems like Spring. They are > extremely popular and gaining in popularity, and are often > part of existing deployed systems that may want to make use > of the framework. Having examples of configuring Resources > and Applications this way would do a lot to boost the > popularity of the package, IMHO. > > Ryan > > > On 1/27/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > >
