Hi Vincent, Thanks for your comments. That's exactly the purpose of the snapshots, to get early feed-back in order to anticipate problems and potential errors in the change decisions. At the time of my reply the Resource.getPreferredVariant() method was already public in SVN, I should have made it clearer I guess.
Concerning Variant, maybe the name confuses you but there is a concrete need for separating it from Representation. The creation of a Representation instance (able to provide the content via streams/channels in addition to metadata like languages, encodings, media type, etc.) can be a costly operation, resulting for example in some parsing (see DomRepresentation class). However, when you select the preferred variant for a given request, you only need to know about the metadata to make a selection. Therefore, the Resource.variants property requires only the metadata part of representations to be provided and with Resource.getRepresentation(variant) you can get the full representation (with content) for the selected variant. Sometimes, the creation of a Representation can be very cheap (for example a StringRepresentation). In this case, the fact that Representation derives from Variant allows you to directly add the StringRepresentation instance to Resource.variants instead of having to duplicate things. This is why in getRepresentation(Variant) method tries to detect, as the default implementation, if the variant is already a representation and downcast it. This is just an optimization, you can always override this behavior if you prefer to always keep both your Variant instances and Representation instances separated. Best regards, Jerome > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Vincent > Envoyé : jeudi 18 janvier 2007 19:39 > À : discuss@restlet.tigris.org > Objet : Re: Getting confused > > > > > Hi Jerome, > > Thanks again for your insights and sorry for fanning the > flames over the > RC3 changes ;) > I really like the idea of adding more behavior to the > Resource class, thus > making the Finder transparent: one less class to extend, all the > developer has to care about is the resources. I still have a > problem with > the Variant/Representation hierarchy. See below. > > > > Even for a PUT this is useful. Indeed, when the handlePut() > is invoked after > > construction, it will do some preprocessing then call your > > "put(Representation entity)" method. In this method you > will easily know if > > your domain object was found at construction time and can > guess if you need > > to CREATE a new one or simply UPDATE the existing one. > > Fair enough. > > > > > but you can always get the preferred variant of a resource > by calling > > the Resource.getPreferredVariant() method > > Well, no: Resource.getPreferredVariant is private. Maybe I > should have started > by asking why it isn't just protected, i.e. why it is > assumed that I will > never need to know the client's preferred variant in post() or put(). > I ended duplicating the method in my MyResource class, but I > didn't know > if it was an oversight on your sight or if I was missing something. > Judging by your suggestion, it sounds like you expected the method to > be accessible by derived classes. > > > This is debatable. I view it this way: a VARIANT "is an" OBJECT that > > contains some metadata property (type, languages, etc.) and > a REPRESENTATION > > "is a" VARIANT that provides some actual content. > > Isn't that the equivalent to saying that Person 'is a' Gender? > The Variant is sometimes seen as a just the media > type/language; for instance, > when you call getVariants().add(new Variant(MediaType.TEXT_PLAIN)); > in your constructor, your are actually saying: 'I support > this media type'. > And sometimes, it's the actual representation of the > resource. In other > words, it alternates between being a request-related property > (this is the > format I want) and a response-related property (this is what you get). > > If The Resource class had a 'getPreferredMedia' and a > 'getPreferredLanguage' > methods, Couldn't you merge Variant and Representation? > > Another way of looking at it is to ask the question: what > other subclass > could Variant possibly have? It seems to me that -by design- > there will > never be another subclass. Therefore inheritance is not the best > relationship between those 2 classes. > > > At some point in the past I had a RepresentationMetadata > class similar to > > Variant and a Representation.metadata property but it was a > bit cumbersome > > to have to do > request.getEntity().getMetadata().getMediaType() to just get > > the media type of a request entity. Now you can just do > > request.getEntity().getMediaType() with looks better IMO. > > I agree this looks better, but at the expense of the design (the > down-cast in Resource.getRepresentation). > > -Vincent.
