Hi Vincent,
> I guess what's confusing me is the getRepresentation(Variant
> variant) method.
> I interpret id as 'get a representation from this variant'.
> But its actual
> meaning should be 'fill the representation part of this
> variant, if you haven't
> done it already in the resource's constructor'.
My definition would be 'get a representation matching this variant'.
> To me, the semantic of this operation is more a 'set' than a
> 'get' (What I want is to set the data part of the variant):
>
> Variant.setRepresentation(Resource resource)
> (I believe the original design was more along those lines).
There is not just one possible design for this problem. However, if you
consider a variant for an XML document, the actual representation returned
can be of an instance of several classes: StringRepresentation,
FreeMarkerRepresentation, DomRepresentation, SaxRepresentation, etc. YOu
don't necessarily know (or what to know) in advance (at construction time)
which implementation class will be used when actually returning the
representation.
With the current approach, specifying the metadata of a representation via
the Variant class doesn't impose any implementation class for the full
representation.
[...]
> So, the idea is that -if the representations are too
> expensive to build- the
> constructor can build empty shells (variants) as placeholders.
> Perfect, lazy initialization is a good thing.
> Now, when it's time to return the actual representation, instead of
> filling the shell, we have to create a new one:
>
> Representation getRepresentation(Variant variant){
> if (MEDIA_TYPE.TEXT_PLAIN.equals(variant.getMediaType)){
> return new StringRepresentation(...);
> } else {
> '''
> }
> }
>
> Why would I have to create a new object to store a
> representation of my
> resource if I already created one in the constructor? Well,
> it's because
> I can't extend an object's class at runtime (From Variant to
> StringRepresentation), so now, what I thought was an empty
> representation
> of my resource is actually used as a type. Hence the confusion.
>
> I can now wrap my mind around this concept (although I'm
> still not sold
> on it), but it's far from obvious when you start working with
> the framework
> (you really have to read the code and spot the downcast to see how the
> pieces fit together).
Agreed, I will try to clarify the Javadocs of Resource.
Best regards,
Jerome
