Marc Hadley wrote:
> On Mar 14, 2008, at 7:09 AM, Stephan Koops wrote:
>> If we build a GUI application, we partition the responsibilities to
>> MVC. We all know this model. Nobody who wants to build a well
>> designed application allows the model to change the controller or the
>> GUI. This is known in computer sience since since round about 25
>> years. A good designer calls a GUI framework, that promote to break
>> the MVC model, a bad designed framework. Right?
>>
>> Also here: It is not good to allow the MessageBODYwriter (the model
>> of the MVC comparisaon) to alter the HTTP headers (could be compared
>> with the controller of MVC).
>>
>> For the MessageBodyWriter I can imagine use cases where it is useful
>> to allow this, but at the expenses of the design.
> The analogy is far from perfect
Ok, every analogy has a point where it stops.
> but I see the resource class as the controller and the entity
> providers as the view. I really don't see any design-issue with the
> writer adding metadata prior to serialization. What breaks when the
> writer adds or changes metadata ?
The idea of MessageBodyReaders and writers are very good, because we
have a high level API for separation of creating the response headers
and read the response from the database on the one hand and the response
entity serialization on the other hand.
In my understanding the MessageBody[Reader|Writer]s reading/writing
exact what Roy Fielding named the "representation" of a resource. And
the representation data are only the HTTP message body, as I rhetorical
asked yesterday, if it is a MessageBODYwriter or a MessageWriter. But
don't rename, them, I think they are good.
BTW: Is there any use case where it is needed to add the headers in the
MessageBodyWriter and not in the reader?
>> But where is it needed in the StreamingOutput? All what I can do in
>> the StreamingOutput.write(..), what is done before starting the
>> writing on the output, could be done ahead in the resource method, by
>> moving it from the beginning of the write method ahead the creation
>> of it.
> For StreamingOutput you have no choice, that's a limitation of using
> that type.
> If you want full access then you can easily write a message body
> writer instead.
The point is, that I never want it ...
best regards
Stephan