Hi all, Thanks Chris for the feed-back on your migration process. Following your suggestions and comments, I've just checked in those changes:
- Added Resource.setVariants() and setIdentifiers() methods. Can be easier than doing a getVariants().clear() then a getVariants().addAll(newList). - Improved Javadocs for the org.restlet.Handler class to explain what is the default behavior of each handle*() method. Best regards, Jerome > -----Message d'origine----- > De : Chris Winters [mailto:[EMAIL PROTECTED] > Envoyé : lundi 21 août 2006 20:17 > À : discuss@restlet.tigris.org > Objet : Re: Restlet 1.0 beta 18 released > > Jerome Louvel wrote: > > ... > > - Following the advices of API design gurus Eamonn McManus > and Joshua > > Bloch), I've refactored the whole API in several ways: > > - Set most of the member variables to "private" instead > of "protected" > > for better encapsulation and evolving capabilities > > I think it's useful for subclasses be able to 'set' many of these > members without manipulating the initial reference. For instance, a > Resource subclass should be able to do call 'setVariants()' > to assign a > list of variants that it puts together itself rather than > having to use > list operations to remove everything and add it back in order. > > I'll put together a patch where I think this makes sense. > > > - Separated the Handler concept into a Chainer (similar > signature) and a > > Handler (new method specific to find the target resource). > Handler now > > directly > > derives from Restlet. The goal is to provide a cleaner > separation of > > roles. > > > > - The Resource interface doesn't derive anymore from Restlet. The > > responsability of the control and handling of incoming > calls is moved to the > > repurposed > > Handler class. > > When I first started modifying the sample app to reflect the > changes I > didn't quite understand the motivation for these changes, or > even that > they really needed to be considered together. I kind of liked > the idea > of the Handler finding the correct Resource and then just passing off > control to it. > > But after investigating the Handler's 'findTarget( call )' method and > how it's used, the changes make sense. The Resource is still > responsible > for making its different Representations known, but it only needs to > deal with PUTing itself. Another object (Handler) is responsible for > making the Resource available at an address, or as the result of some > other operation like a search. > > More to come... > > Chris > > -- > Chris Winters ([EMAIL PROTECTED]) > Lead Software Developer > Vocollect Healthcare Systems > > CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and > intended for the addressee(s) only. It may contain privileged and/or > confidential information. If you have received it in error > you are not > authorized to disseminate it in any manner; please delete it and any > copies and reply to the sender that it was misdirected. > > >
