Geoffrey Wiseman wrote:
This approach allows the library to do the automatic content negotiation
and call getRepresentation(Variant v) with the appropriate Variant. If
you short circuit this and add in your Representation during
construction, basically you miss out on the ability to "switch" on the
Variant coming into the getRepresentation method.
I'm assuming this statement is mostly true if the representations are
expensive to construct? If I create three representations in the
constructor, from what I can see, the Resource class will still conduct
content negotiation.
Right, good point.
The content negotiation is essentially being done just prior to the
library calling getRepresentation() on your Resource class. Obviously,
that's how it chooses the right Variant as a parameter for the method.
So, regardless if you create multiple representations in the constructor
or if you create one in the getRepresentation() method, the content
negotiation part is still being performed.
Just as an aside, I can't see any reason to create multiple
Representations in the constructor, even if they were able to be created
fast. Since the server can only respond with one representation, it
doesn't seem to make sense (to me at least) to create multiple
representations in your constructor ultimately to return only one.
That's why I like overriding getRepresentation() and creating the
Representation there.
Maybe you have a good reason to create all your representations in the
constructor of the Resource?
Adam
