Hi Jerome,
> Concerning Variant, maybe the name confuses you but there is a concrete need
> for separating it from Representation.
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'.
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).
> 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,
Agreed.
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).
-Vincent.
