views:

61

answers:

2

I'm developing this application where you can put text and drawings in a page. My application is in MVC pattern, and I need all the model parts, text and shapes to be of the same notion. They all extend an abstract ReportElement clas, for example.

But the problem is I crate a JPanel for every shape in the page, but to handle text I need to use JTextArea or something. To render the elements the View directly gets the report elements list from the Model and draws one by one. How can I distinguish a text element without hurting the MVC pattern.

I mean, it's impossible, right? I don't know, any ideas?

+1  A: 

I would handle this situation by building a factory method that produces the right type of Swing component for any given ReportElement, like this:

public static JComponent buildViewForReportElement(ReportElement element)

Inside this method, you will need to actually inspect the ReportElement objects to see what type of component to build. This inspection might mean checking a field or a flag on each object, or might even mean using instanceof to distinguish different subclasses of ReportElement from one another.

Note that inspecting ReportElement objects like this violates the philosophy of object-oriented programming. A simple "object-oriented" solution would require all of your ReportElement objects to have a buildView() or getView() method, and so your GUI code could just call getView() on every ReportElement without knowing which implementation of getView() was actually being called.

Unfortunately, the object-oriented solution forces you to mix your view code with your model code, and it's good that you are trying to keep the two separate. That's why I would advocate keeping the GUI-building code out of ReportElement objects and instead using a factory method to build the right view for any given ReportElement.

Joe Carnahan
thanks a lot. now doesn't that make View 'know' about the Model, and violate the seperation between them? or does that factory thing kind of hide it or something?
Halo
Well, the factory itself isn't part of the view, nor is it part of the model. The factory has to know about both the model and the view, but it is not part of either of them.
Joe Carnahan
thanks man, let's hope it will be alright
Halo
+1  A: 

I think you're looking for the "Factory Patter"

You need to have a wrapper method that returns a JComponent based in you own ReportElement conditions

Carlos Tasada
thanks for the link as well man, what do you think about my question below?
Halo
This pattern is not breaking the MVC. In fact, your factory method should be in an auxiliary factory class, which is dealing with all this logic.In this way your View still only knowns about layout, your Model about Data and your Controller is .... well, controlling ;)You can call directly your Factory method from the view, since it's behaving like any other JComponent creator.
Carlos Tasada
hmm. based on your comment, if I say that this factory is a part of the controller mechanism and its class should be in controller package, will I be wrong?
Halo
wait, no it's a View mechanism, because it will provide the jcomponents for the view, and view is going to, well, add them to the panel.. I think.
Halo
no wait, if it was view then it would be no different. It should be in Model. But then isn't it bad, that Model, is creating JComponents?
Halo
no it shouldn't be in model. it's getting jumbled :)
Halo
The Factory class is just another class, as any other JComponent you may have.Where are you creating your ComboBoxes, Entries, ....? In the view, right? then you'll do these calls in the same View, it's just another visual element.You're right that it has some logic, but is embedded, so is not messing with your MVC pattern.That's the main flaw of the MVC pattern, sometimes is confusing. In some way MVP is more clear, but I still think that MVC is better when creating components.
Carlos Tasada
thanks, I will try this one.
Halo