views:

98

answers:

4

I have a bunch of model objects.

These objects end up being rendered as views (say forms) in a rich client app.

I started to annotate the fields in the model objects (Java annotations) with things that let me render them as forms on the fly (e.g displayname, group, page, validvalues).

I now realise that the view has crept into the model.

How should I seperate the view logic out of the model objects?

TECH: Java, Java Annotations, Eclipse RCP

EDIT:My question is theoretic, but I would also like some concrete (implementation) advice.

A: 

You could look at the MVC pattern and introduce a controller into the mix to provide the communication between the model and the view.

This prevents the view creeping into the model as the view never talks to the model it only talks to the controller which is responsible for all interaction between the model and the view

Steve Weet
Thanks, I am using some form of MVC already, but I sort of wanted to know how this is actually implemented, like with an XML that links to the fields in the model, or a controller that provides the map between model field and display field...
geejay
+1  A: 

At the risk of stating the obvious, what you need to do is store the display-related information somewhere else. Don't put the page in the model code - create an object for the interface, have it contain page objects, and make each page know what values it displays. This may require a certain amount of refactoring.

Having said that, not everything you mention is 'view'. Valid values for a field is part of the logic of the field; it should be considered part of the model, not the view. Likewise if 'group' is a logical grouping, rather than about placement in the interface, it might be considered part of the model.

DJClayworth
A: 

If I get you right - you use the model classes as a (static) model to create (part of) the view? Why not - in your case, the model classes (with annotations) are one model, the objects another one.

As long as the annotations just give hints (like @Textfield) I don't see a problem. If the model already contains references to view objects (like a reference to a Textfield), then there's need for refactoring. Easiest would be to move the model classes in a separate plugin and do not add any *.ui type and view plugins as dependencies. Then fix the errors ;)

... and have a look at jface databinding! Very useful in a MVC/MVP architecture!

Andreas_D
Thanks, I am using JFace databinding already. The comment about model classes and objects is interesting, and I sort of agree there, its just that these classes live in the model component, and it doesnt really look right...
geejay
But if they just include hints for any presentation layer, then it's fine for me. Alternativly you can maintain a separate document that includes those hints, like properties file. But this introduces the risk, that model and properties file run out of sync.
Andreas_D
A hint about UI doesn't strictly break the MVC separation, but you have to ask - why is it there? Why not store the information in the View implementation?
DJClayworth
+1  A: 

You could replace the annotations:

@DisplayName("My Fancy Name") 
@DisplayGroup("My Fancy Group") 
public String myProperty;

by a separate descriptor class:

Descriptor desc = new Descriptor(MyClass.class, "myProperty");
desc.setDisplayName("My Fancy Name");
desc.setDisplayGroup("My Fancy Group");

You have clean separation of concerns, but you loose compile time safety (in Java, because Java does not have property references).

tkr