I'm currently working on a project based on Qt4/QtCreator. I'd like to ask You for advice on how to organize my application.
There are 3 seperate tools, each has it's own view. All views are integrated in main window as non-closable tabs. I've prepare 3 views: Tool1View, Tool2View, Tool3View
Each tool is suppose to perform some task triggered by user actions. But these are not database related operations (list/add/modify...) - at least the user is not going add/modify/list records in gui elements.
I am thinking to implement each tool in 2 classes:
First class ToolXView implementing the widget and all tasks related to gui changes.
Second class ToolX implementing application logic. Member functions of this class are triggered by View class. Whenever this class has to update GUI elements it cals specialised functions in View class. So no direct calls to widgets are made from here.
View class and logic class will be linked with each other to allow 2 way communication.
Now I'm wondering if this is a good way to go. Please advice me based on Your experience.
I'm planning to encapsulate pointer to logic class as a property of a view class and pointer to view class as a property of logic class. This way I plan to integrade them.
Should I use signals/slots to provide comuncation or just call member functions ?
I'll have to store some data in QtSql database. Should I provide a seperate class for database access. Or just implement sepereate member function inside Logic class ?
How do You name Your classes. Is this scheme good or should I change it ?
Thanks for help. I appreciate your comments.
Using the mvc architecture is great.
1 & 2 - In the link above you will see the UML diagram of a mvc architecture. Regarding it, I would connect view signals to controller methods and then call a view method from controller.
3 - Regarding Database access I would add a Data Access part in your architecture which is specialized to the data access. You can have an interface to define the data access object signature and then implement it in a specialized class for database (So you will be able to change data location without modifying the whole application).
4 - You class naming seems good. But I would go further and call classes:
For view : ClassNameView
For Controller : ClassNameController
For DataAccessObject : ClassNameDAO
Model : ClassName (and IClassName for interface)
Hope that helps
Related
i'm need your help again.
I have an document viewer application what can read two different kinds of documents:
Special one (based on PDF, with custom header)
Standart one ("raw" PDF).
With raw PDF viewer should acts like any other one.
With custom - execute some additional actions during it's opening, which are not available to raw PDF.
These actions should be available later in the application's menu only. And only for custom document.
Project OOP architecture (designed by other man) looks like this:
class GenericDocument
class PdfLibDocument
class CustomDocumentHighLevel
class CustomDocumentLowLevel
I.e. each higher-level class contains the lower-level one as member:
class GenericDocument
{
SmartPointer< PdfLibDocument > m_document;
...
};
and so on.
Custom document has much specific functionaly:
class CustomDocumentLowLevel
{
public:
void DoSomeBlackMagic();
...
// Another black magic
};
The problem occurs then i need to "pull" some low-level method from CustomDocumentLowLevel to GenericDocument (to show in app menu) - because i need to add this method to ALL FOUR classes!
And probably in the future i need to "pull" more methods from custom document.
Looks like this software architecture is bad choice in such case, isn't it?
So i need find a way to refactor this code. Should i replace aggregating with inheritance? Introduce interfaces?
Usually composition is preferred over inheritance, but it doesn't seem applicable to your case. Why not to inherit Viewers from one another? Make a base viewer with a simple functionality, available all over and then inherit specialised one from it adding new functionality.
As for menu and actions, connected with it, they should be represented as a separate objects. Check Command pattern for that.
UI can request available command list from your Viewers. Each viewer can fill its internal command list on initialization or construction or whatever you choose.
I'm having a problem figuring out what is the idiomatic Ember.js way of representing the following task: the application should display a list of master entries (let's call them classes) each one having one or more child entries (let's call them students), the latter having in turn teacher-marks, as sub-child entries.
I want the page to display the list of classes along with the list of students for each one as the standard view, while the teacher-marks should be initially hidden, but made visible on demand, when they should be editable in place (new and remove operations).
The way I've implemented this display-wise is this:
Each class is displayed as an Ember view, as I need a lot of interaction with the controller. The teacher-marks are implemented as Ember components, as well as the students. Neither the view, nor the components perform any communication with the server, they basically just send actions to the controller / route.
Displaying and hiding the teacher-marks are done via properties in the components.
I only have one route for all this (and as far as Ember.js tutorials and examples go, I feel I may be doing it wrong) and one controller. The route is named 'classes' and has an ArrayController displaying the array of classes. I have item controllers for each class.
The route object is the one that fetches data from the server. The manipulated child elements (e.g. new/removed teacher-marks) are pushed to the server via dedicated model functions (using Ajax calls) called from the main route events. I am not using Ember data.
As far as I read, I should be having nested resources for this implementation, but am otherwise at a loss as to how to implement it that way and keep displaying the classes and students at all times.
I would greatly appreciate all amendments and suggestions to the way I currently implemented this. It would also help me a great deal if you could add why will something work better one way or the other.
I haven't included any code as I feel it would be better expressed this way as a problem. My code is obviously more complicated than above, and not involving the class - students case. If needed, I can sketch-up a model.
Background
We use the Model-View-Presenter design pattern along with the abstract factory pattern and the "signal/slot" pattern in our application, to fullfill 2 main requirements
Enhance testability (very lightweight GUI, every action can be simulated in unit tests)
Make the "view" totally independant from the rest, so we can change the actual view implementation, without changing anything else
In order to do so our code is divided in 4 layers :
Core : which holds the model
Presenter : which manages interactions between the view interfaces (see bellow) and the core
View Interfaces : they define the signals and slots for a View, but not the implementation
Views : the actual implementation of the views
When the presenter creates or deals with views, it uses an abstract factory and only knows about the view interfaces.
It does the signal/slot binding between views interfaces. It doesn't care about the actual implementation. In the "views" layer, we have a concrete factory which deals with implementations.
The signal/slot mechanism is implemented using a custom framework built upon boost::function.
Really, what we have is something like that : http://martinfowler.com/eaaDev/PassiveScreen.html
Everything works fine.
The problem
However, there's a problem I don't know how to solve.
Let's take for example a very simple drag and drop example.
I have two ContainersViews (ContainerView1, ContainerView2). ContainerView1 has an ItemView1. I drag the ItemView1 from ContainerView1 to ContainerView2.
ContainerView2 must create an ItemView2, of a different type, but which "points" to the same model object as ItemView1.
So the ContainerView2 gets a callback called for the drop action with ItemView1 as a parameter. It calls ContainerPresenterB passing it ItemViewB
In this case we are only dealing with views. In MVP-PV, views aren't supposed to know anything about the presenter nor the model, right ?
How can I create the ItemView2 from the ItemView1, not knowing which model object is ItemView1 representing ?
I thought about adding an "itemId" to every view, this id being the id of the core object the view represents.
So in pseudo code, ContainerPresenter2 would do something like
itemView2=abstractWidgetFactory.createItemView2();
this.add(itemView2,itemView1.getCoreObjectId())
I don't get too much into details. That just work. The problem I have here is that those itemIds are just like pointers. And pointers can be dangling. Imagine that by mistake, I delete itemView1, and this deletes coreObject1. The itemView2 will have a coreObjectId which represents an invalid coreObject.
Isn't there a more elegant and "bulletproof" solution ?
Even though I never did ObjectiveC or macOSX programming, I couldn't help but notice that our framework is very similar to Cocoa framework. How do they deal with this kind of problem ? Couldn't find more in-depth information about that on google. If someone could shed some light on this.
I hope this question isn't too confusing ...
Ok the technique I found is actually coming from Cocoa, so it's objective-C but you can definitely do the same in C++.
The solution is simply to use a PasteBoard (developer.apple.com documentation).
In the hope it helps someone ...
i was recently suggested to use MVC pattern to organize my Qt4 application.
I'm a little puzzled :).
How do I implement:
1. model
2. view
3. controller
In HTTP based apps its quite straigtforward. But here I'm not sure what is a view and what is a controller ?
Lets asume that I'm not using Interview right now.
Thanks for help
you can look at this like this:
Controller is the window/form that You created. Member functions in this class should handle all user input and call apropriate member functions in your model.
Model is your class that handles data and implements other logic.
Views are qt widgets used to design your forms/windows
(You could also treat *.ui files as views and Classes that are bound with ui files as controllers)
Hope this helps.
I'm building a desktop app in QT (although that may be irrelevant) and I'm having a hard time working through the class structure and layout. The data model is fairly simple with a root container with a number of containers of items. Consider the following representation:
Root
+ Parent
+ Child
The UI is fairly simple and follows that data model with a main window with a scrollable area (root), widgets that contain layouts (parents) of custom widgets (children) with some labels and buttons.
My trouble is with handling events that need to go up the chain and then back down like moving a child from one parent to another, moving elements, or updating child meta-data that impacts several to many other widgets.
I'm currently splitting UI widgets and model objects but having each widget and corresponding model object pointing to and from each other feels cumbersome and I think it is leading to too much maintenance.
I'd suggest following a standard MVC pattern and ensure there are no dependencies from the model to the view; in your case this would mean that while there is a widget for every model item, the model items do not reference their corresponding widgets.
While the MVC pattern has many flavours, one way to accomplish this would be to have a view class that monitors the model for any changes and updates the view accordingly (this can be accomplished by connecting a slot in the view class to a signal emitted from the model class). Any changes the user initiates through the view can then be:
1) handled directly by the model
through a simple signal/slot
connection
2) handled
by a controller class which can
direct the model to update accordingly
Either of these would then cause the model to emit an update signal which would cause your view to update. The benefit of this is the ability to change your view (or add additional views) without having to update your model.
I'd recommend reading Qt's Model/View Programming Guide to better understand how MVC works in Qt and to see if there's an existing class or interface (e.g. QAbstractItemModel) that you could use instead of baking your own.
Consider using factory pattern and command pattern. There are plenty of samples. I am just giving a hint here.
http://en.wikipedia.org/wiki/Factory_method_pattern
http://en.wikipedia.org/wiki/Command_pattern
Forgot mention about qt book: cartan-cas-dot-suffolk-dot-edu/oopdocbook/html/