On 05.11.2004 11:19, Leszek Gawron wrote:
Terence Parr sugests that test like "$bloodPressure<120" in the view should be performed in the model and tested in the view like "!$bloodPressureOk". He even says that:
Even simple tests that make negative values red should be computed in the model; the right level of abstraction is usually something higher level such as âdepartment x is losing money.â
Still this is very inconvenient if the model is built for you i.e. object graph built by hibernate. I would have to make controller dependant on view view wants to show. Right now I just pass one entity to view and do not care if view asks for entity fields, entity parent fields, child fields, anything. If I have hibernate properly set up the data will be retrieved only when needed.
But the view is not reusable.
I have project that model have 5-6 depts in parent-child relationship like:
contractor -> surveydefinition -> questioncategory -> questiondefinition -> alertcategory -> alertdefinition.
While displaying list of entities on any level I can choose to add additional column with link to parent on any level and the only thing I have to change is the template. Model remains the same.
If the model changes the view has also to change. You all seem to have only just one view in mind. What about having different views for different browsers or devices? While it might be easy for browsers by using XSLT and change here and there a bit, it's nearly impossible for different devices. Who takes control whether to show 5 widgets or 50? Using templates it's only possible by using different templates. And so if the model changes the different templates have also to change. And the templates are still not reusable!
If I had to prepare data for view in such detailed manner as Terence proposes I would have to:
- break whole entity tree
- forget about lazy-loading
- fetch data on each level separately
- prepare some kind of DTOs that would apply "view needs" to data stored in database
- build another object graph only for the sake of one view
and above all:
- change my model every time I change view template
Of course that's neither a way. The model *must* be independent of the view. But isn't this what the renderers/converters are about?
and still: I do not see any gain if I did that. The code is boasted, harder to maintain as more dependencies are introduced and much more buggy.
Shouldn't SoC help making the app clearer and more flexible instead of making it harder?
Of course. You separate into model, view and inbetween renderers. That's what Terrence Parr suggests.
If I would be able to choose convertors I might decide IN VIEW ITSELF that that specific model value should be coloured/pretty printed/rendered according to some specific logic. As long as this logic has read-only access to model and performs steps to produce some rendering I do not find it SoC break.
Shall the view decide it? Even with renderers/converters this makes it being not reusable. As Terrence Parr wrote: The view should be reusable with a completely different model. The configuration must happen externally, i.e. neither in model nor in view.
Joerg
