I'm working on an eclipse RCP application, using a third-party domain model based on EMF, and a GEF editor for editing.
GEF uses the MVC pattern, which would be fair enough if I didn't have to use a specific layout for drawing the model graph on the editor view. The domain model I am using includes no visual information whatsoever (which in itself is a good idea), but I'd like to be able to assign coordinates to Figures in their EditParts. This would make it much easier for me to calculate the position of the figure in the layout.
Now I have stumbled upon the Presentation Model Pattern by Martin Fowler, which seems just about the thing I was looking for. I have also found a - old-ish - tutorial on RCP UI testing (German only), which uses this pattern in an eclipse RCP context.
Now I'm wondering: is it generally possible to use PM in a GEF context, seeing that GEF explicitly uses MVC? Is MVVM an alternative?
Please note that I am prevented from using GMF for a number of reasons.
Many thanks!
Yes, it's definitely possible, and you have two choice.
First - is implement you own graphical notation model. I would suggest you using appreach like:
modelElement : ModelElement 1..1
x : int 1..1
y : int 1..1
Then load two models in EditingDomain (EMF will resolve cross-document references for you), create all missing Graphical Notation Elements e.t.c...
The other option is to use GMF or Graphiti. They have the model you're looking for out of the box, which will greatly simplify you life. At the cost of learning yet-another-monster-framework (in case of GMF). Graphiti, is easy (relative to GEF/GMF), but IMO is's less flexible. GMF, btw, will give you a 'free' TransactionalEditingDomain, which will handle all the commands, undos and redos for you. So, as in comments to you previous question, I would suggest you using GMF.
Oh, sorry, I didn't noticed what you wrote about GMF.
Then, the second option is to have Graphical Model inherit from Domain Model, and then code you GEF editor against this model.
Related
We have been using ExtJs for a long time, and now, with the advent of MVC pattern in it we are facing a critical question of whether to use it or not in the times ahead given the approach we had been following so far.
In our application, we have similar screens, like 40 similar screens for generating the reports and so on. These report screens would be having a form with buttons - PDF, CSV, EXCEL. All the buttons would be having same functionality at every screen, that is, submit the form to a url and generate the specific report.
The approach which we had been following was to create a custom class, say reportscreen class, which extends the window class of ExtJs.
This custom report screen class would already have buttons with their handlers defined (given the fact that the functionality is similar for them for all the screens) and will also have a form present with a function setFormItems(). Any instance of this class would provide the items for the form using setFormItems() and the url for generating the report.
This approach not only helps us in reducing the development effort to a great extent, but also allows even a new member of the team to use the class & create a new screen.
Now comes in MVC, the most advised pattern, and the approach shared above is definitely not as per MVC pattern. But then, do we need to really move to MVC pattern here?
Using the above approach, we are not only able to save the effort, but also have a greater control over things.
The purpose of asking this questions is to know about the exact advantages we shall get if we implement the above scenario using MVC pattern and move away from our current approach.
Thus, what extra things would MVC bring to the table in the context above? And also, what would be the best way to implement such a thing in MVC pattern?
Thanks for any help in advance.
Do you need to use MVC? No. Assuming you've already got a structure that works well for you, if it's not broke, don't fix it. If you were starting a new project I'd recommend using MVC, but I wouldn't refactor a whole bunch of code for the sake of it. If you did use MVC, you would follow a similar approach. You'd have a base view class where you dynamically push on the items in the subclass. You'd have a base controller to handle all the custom events, then subclass controllers to implement custom functionality on a "per module" basis.
It's hard to explain the advantages of using MVC to someone who had no experience with it. As someone who developed with both ExtJs 3 and 4 (with MVC), I think one of the greatest advantages of MVC is that it forces you to think right - whether you want it or not, using MVC is likely to result in code base that is more reusable and better encapsulated. But if you boys and girls are good programmers/designers, this will be the case anyway.
If you do choose to move to MVC, I believe that the main change will be in that now instead of handling user interaction within your custom class, you will have a single controller to do the same job - leaving your custom class to realize the view only. Controllers in ExtJs4 are global - meaning that the same controller may control 40 similar views. So no duplication of controllers here.
It's important to mention that even within an MVC design you will find non-MVC code. For example, I have a custom record editor which is a form - the component knows how to handle user actions and update the records accordingly (the form is not submitted as it's mostly dealing with associations). This component takes the equivalent role of both the controller and the view within an MVC design. It seems to me more than reasonable to encapsulate things this way, rather than split this to a view and a controller. But the (non-reusable) user screens are implemented using MVC. So maybe just another reason not to rush to MVC.
While I agree with Evan that if it aint broken don't fix it, had I been your development leader and given time and money is not an issue, I would actually request the gradual migration to MVC - overall I think that 3 years down the line you won't regret this decision. I would at least attempt it.
When ExtJs 4 came out I scraped 2 months of work to rewrite from scratch a system using MVC - I don't regret this for a second now (I did at the beginning, but not for MVC - rather for the amount of bugs in the early versions of 4).
I am writing a Desktop GUI application in Clojure using Java Swing. Normally when working with Java I will design the application according to a MVC design pattern using the Observer pattern as well. This way the view is decoupled from the model and changes in either do not affect each other, making changes easier further along.
I was wondering if Clojure has a better approach to this problem than normal MVC and Observer design pattern? I'm new to functional programming so i'm not sure how I can make the model separate from the view. I require this as the application will be developed iteratively and there may be challenging requirements that come along further down the line.
Would appreciate any help.
Thanks,
Adam
A lot of the design patterns from the java MVC world get a bit silly when you have first order functions, macroes (code-as-data), and concurrent persistent data structures. for instance the "observer pattern" is basically just an agent with some watches set. It goes from being a pattern to a function call.
if you store the state (model) in a ref or agent and make your view a function (in the functional programming sense of the word) that displays that state; while making your controller a function (again in the FP sense of the word) that produces a new state given the old state and some new input then the MVC model falls out very nicely.
it s bit dated, but Stuart Sierra's grid bag layout post really helped me get started in this area.
In Clojure you can certainly do MVC, but I'd suggest implementing it using watches on Clojure references.
Code would be something like:
; define the model as an immutable structure stored in a ref
(def model (ref (create-my-model)))
; function to update the UI when the model changes
(def update-function [old-model new-model]
(do-whatevever-updates old-model new-model))
; add a watch to the model to call update-function when a change happens
(add-watch model :on-update
(fn [key reference old-state new-state]
(if (not= old-state new-state)
(update-function old-state new-state))))
Also if you are building a GUI in Clojure, it may well be worth taking a look at some of the existing Swing library wrappers, e.g.:
Clarity - has a nice DSL for defining UI elements
Seesaw - possibly the most mature wrapper for Swing
clj-swing
i'm wondering if there is a pattern how to separate the domain logic of a class from the ui responsibilities of the objects in the domain layer.
Example:
// Domain classes
interface MachinePart
{
CalculateX(in, out)
// Where do we put these:
// Draw(Screen) ??
// ShowProperties(View) ??
// ...
}
class Assembly : MachinePart
{
CalculateX(in, out)
subParts
}
class Pipe : MachinePart
{
CalculateX(in, out)
length, diamater...
}
There is an application that calculates the value X for machines assembled from many machine parts. The assembly is loaded from a file representation and is designed as a composite. Each concrete part class stores some data to implement the CalculateX(in,out) method to simulate behaviour of the whole assembly. The application runs well but without GUI. To increase the usability a GUi should be developed on top of the existing implementation (changes to the existing code are allowed). The GUI should show a schematic graphical representation of the assembly and provide part specific dialogs to edit several parameters.
To achieve these goals the application needs new functionality for each machine part to draw a schematic representation on the screen, show a property dialog and other things not related to the domain of machine simulation. I can think of some different solutions to implement a Draw(Screen) functionality for each part but i am not happy with each of them.
First i could add a Draw(Screen) method to the MachinePart interface but this would mix-up domain code with ui code and i had to add a lot of functionality to each machine part class what makes my domain model hard to read and hard to understand.
Another "simple" solution is to make all parts visitable and implement ui code in visitors but Visitor does not belong to my favorite patterns.
I could derive UI variants from each machine part class to add the UI implementation there but i had to check if each part class is suited for inheritance and had to be careful on changes to the base classes.
My currently favorite design is to create a parallel composite hierarchy where each component stores data to define a machine part, has implementation for UI methods and a factory method which creates instances of the corresponding domain classes, so that i can "convert" a UI assembly to a domain assembly. But there are problems to go back from the created domain hierarchy to the UI hierarchy for showing calculation results in the drawing for example (imagine some parts store some values during the calculation i want to show in the schematic representation after the simluation).
Maybe there are some proven patterns for such problems?
Agree with #Marjin, and to generalise his answer. What you need is Model-View-Controller of which MVP and MVVM are variants. From your comments I think you understand that, but need to understand how to implement the pattern. Without knowing your language & target architecture it's hard to give absolute specifics. Notwithstanding, I'd start with the Observer pattern (link has sample code).
The problem you're dealing with is how to provide observable access from the domain to the UI - without encumbering the domain with UI-specific code. Observer provides a means to do that. It does require domain changes, in particular to enable registration of observers and notification of changes. However there's nothing GUI-specific in that so it stays well encapsulated.
hth.
PS: If your app is a typical thin-client web app you'll need to modify the approach. And beware: lots of web app frameworks are advertised as "MVC", but the implementation is architecturally quite different to the Observer pattern.
You can take a look at the model-view-presenter (mvp) and model-view-viewmodel (mvvm) patterns.
Fowler's presentation model includes two sample applications; it also might be of interest to you.
I think that investigating these patterns will give you some ideas on how to continue. Mvvm looks a lot like your current solution; so i'd start there if I were you.
Maybe a View Helper can help. It's not a C++, but a Java EE pattern, but in your case it will definitely separate your domain objects from their presentation details...
I am writing a GUI based application where I read a string of values from serial port every few seconds and I need to display most of the values in some type graphical indicator(I was thinking of QprogressBar maybe) that displays the range and the value. Some of the other data that I am parsing from the string are the date and fault codes. Also, the data is hierarchical.
I wanted to use the model/view architecture of Qt because I have been interested in MVC stuff for a while but have never quite wrapped my brain around how to implement it very well.
As of now, I have subclassed QAbstractItemModel and in the model I read the serial port and wrap the items parsed from the string in a Tree data structure. I can view all of the data in a QtreeView with no issues.
I have also began to subclass QAbstractItemView to build my custom view with all of the Graphical Indicators and such. This is where I am getting stuck. It seems to me that in order for me to design a view that knows how to display my custom model the view needs to know exactly how all of the data in the model is organized. Doesn't that defeat the purpose of Model/View? The QTreeView I tested the model with is basically just displaying the model as it is setup in the Tree structure but I don't want to do that because the data is not all of the same type. Is the type of data or the way you would like to present it to the user a determining factor in whether or not you should use this architecture? I always assumed it was just always better to design in an MVC style.
It seems to me like it might have been better to just subclass QWidget and then read in from the serial port and update all of subwidgets(graphical indicators, labels, etc...) from the subclass. Essentially, do everything in one class.
Does anybody understand this issue that can explain to me either what I am missing or why I shouldn't be doing it this way. As of now I am a little confused.
Thanks so much for any help!
** ** - Is this a situation where Qt Model/View architecture is not useful?
I"m going to say not necessarily - end edit
I'm not sure I fully understand your question, but let me try.
First, let's talk about MVC display pattern. This pattern is all about breaking the program into separate (and hopefully testable) sections that have their own areas of concerns.
The model is data structures that describe your data. I'm sure that there is some statistical data is also present. It is important that the model not know anything about how the data is going to be displayed to the user.
The View is how information is presented to user. It is not suppose to care about how the data is presented for displaying. It is important for this layer to be unaware of how the model gets the data for display.
The control logic is the "glue" to connects the first two items together. This is the layer that holds all the "messy" stuff to make to good user experience. EDIT - Most of what QT calls a "view item" I would probably put in the controller layer.
But if you do this, then the model and controller layers become very testable.
With that being said, many of your points are not really related to MVC pattern. You seem to be discussing what is the optimum way to display the data. This is always a problem. And without seeing your app, I'm not really going to try to tell you what is going to look good.
But by following good MVC pattern design, you can make pretty significant revision to the display without effecting the underling code.
This being said, I'm dealing with this exact issue right now and this pattern is working well form me. If you go to codeplex.com and search for mvvm (model-view-viewmodel, term used in WPF), you will see a number of projects that use it that you can use to get more information.
If this is not enough, let me know and I may be able to give you a better answer.
I'm tring to grok Prism (Composite Application Guidelines).
What is the best way to understand the role of the ShellPresenter? Is it a presenter as in Model-View-Presenter?
Is so, what is its relationship to the Shell? I understand that the ShellPresenter takes the Shell object as a parameter of its constructor and is responsible for making sure all the Modules place their views in the proper regions. But then there is also the RegionManager which does this.
Any clarification from those who have been working with this terminology for while would be appreciated.
Yes, ShellPresenter is a Presenter in the MVP pattern.
The regionManager really acts as a registry of known Regions - its technically an Adaptor to the said Presenter.
So whilst on the surface the ShellPresenter could technically handle its own Children management, by using the Adaptor Pattern one can de-couple this logic and promote re-usuage throughout since it's likely to be constantly used? (ie think multiple inheritance work-around).
Does that help?
Scott Barnes - Rich Platforms Product Manager - Microsoft.