> 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.
