Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Qt/Qml uses model/view architecture Model/View Programming Model/View Tutorial but their examples are too simple. I want to know how it should look with more complex problem. Assume that we have Application. According to Qt's model/view architecture the best solution is to create ApplicationModel, ApplicationView and ApplicationDelegate. Now lets our Application to have a Console and other components. Console should be separated to ConsoleModel, ConsoleView and ConsoleDelegate. But Console has its own Input and Output, that should be separated to ConsoleOutputModel, ConsoleOutputView, ConsoleOutputDelegate and ConsoleInputModel, ConsoleInputView, ConsoleInputDelegate.
But how does it all should be combine? Should ApplicationModel contains ConsoleModel that contains ConsoleOutputModel and ConsoleInputModel? It makes sense, but what about views and delegates? Similarly or ApplicationDelegate should control ConsoleView and ConsoleDelegate? How then ConsoleOutputModel should be accesed by ConsoleOutputView?
I would be very grateful for every hint or example solution.
What you imply is mostly incorrect. There's no reason to nest models, unless you wish to logically combine their data - and if so, you'd need to write a custom proxy model to do so. Existing proxy models provided by Qt have only one source model. This is just what's there, doing a multi-source proxy is certainly possible.
In Qt's model-view model, a delegate has a specific meaning: it is the visual "skin" used to interact with the item. It specifically derives from the the QAbstractItemDelegate class. The delegate concept applies to the viewed items from the model, not to the view as a whole. You may need many delegates, not just one, or no delegates at all. It's not the same as the delegate concept from model-view-controller.
Another issue I see is with demanding that the entire application is an ApplicationView. Qt doesn't provide views that would construct a widget-based user interface of the entire application using the QAbstractItemModel as a data source. The closest you get is QUiLoader which can load an .ui XML file and instantiate the UI objects - but that does not use the model-view framework, and is a one-time action: any changes to the underlying XML model are not propagated automatically.
The way models and views are typically used in Qt is to couple a model to one or more view widgets. Those widgets then show some subset of the model (perhaps the full model) in a particular way. You can even couple a model to any widget's property using the QModelWidgetMapper.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Firstly, the scenario in my question:
I want to deliver a form in bitesize stages, with the valid completion of one stage leading to the next until all stages are complete.
On completion, I'd like to use data once, and then forget it completely so I'm not holding on to any user data at all.
My options as I see it are:
Multiple views each with a unique form all bound to a single model. The final submit button in the chain triggers data in the model to be accessed, used and then that particular row removed.
Multiple views each with unbound forms, each adding data to a cookie, which is then read on the final submit, data used and the cookie deleted (either using sessions or plain old js hard coded into each template).
A single view and template containing a single unbound form, which progressively un-hides divs containing each stage until all stages are completed and final 'submit' posts data from the form, allows a view to process it and forgets it.
I can actualise all three of the above, but which is the most 'Djangonic' method, or is there a better method still?
There is a library made from the Django guys for this case: https://django-formtools.readthedocs.io/en/latest/wizard.html
It's not dynamic though, so when you click "proceed", it will render a new page. But you can probably write a javascript module, that can handle this. But I wouldn't go that far, it's a lot of work for little benefit. Just just django-form-tools and use the wizard you want and do whatever you need in the done stage of your view.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I have an Ember template .hbs file with its controller and route. I do not have a component.js file for it. What is an Ember not-quite-component called?
When you type a URL into your browser, the Ember Router has a route, or routes, that handle that particular URL.
The Route can render a template, assign a model, handle actions, redirect to a new route, etc.
A route's associated Controller can be customized if needed, to handle actions or custom properties, for instance.
If the route renders a Template, a component might then be called in the template, or it might not.
A Component typically encapsulates HTML mark-up and functionality that is intended for reusability in some fashion, or to isolate a subset of concerns. If no JavaScript is needed, a component template can be used individually. If JavaScript is required for additional functionality, a component subclass for the component template would also be necessary.
You could say a controller is "not quite a component", given that it behaves in much the same way as a component. However, the template a controller is associated with, is rendered by its route.
You just named it. "Controller", "Route" and "Template". The template belongs to the controller and the controller belongs to the route. A default controller is magically provided for you if you do not define one, and an empty template is also provided by default. If you are speaking to someone and need to convey what you have, the route can somewhat be assumed since it is the only thing absolutely required to reach a page, thus you can simply say "my controller".
Is the document/view architecture in MFC really a Model/View/Controller pattern without the controller part?
I'm studying MFC and I simply love it to bits. I know is somewhat outdated and somewhat bit more difficult to use, but I discovered that it gives me so much more power and performance gain when compared to QT.
Am I correct to think of the MFC doc/view model as simply MVC without the Controller part?
The Model/View/Controler has the following components:
Model
View: responsible to show the model to the user
Controller: responsible to get user input and translate it in operations on the model
MFC's Document/View has only 2 components:
The document, which is in fact our model
The View, which has the responsibility to show the Document AND interpret the user's commands. So it is the view+controller (refer to section Variants in this MSDN article)
Let's look at it:
The view contains UI code, both for rendering the data and for taking input from the user.
The document contains the serialization code.
From that perspective, there's just a separation between UI and a backend. However, there's more, because you can have multiple different views on the same document. You could also use the document to just provide data storage and put any actual program logic into the view. In particular when you only effectively use a single view per document, it is easy to blur the separation in practice.
In summary, I wouldn't say the MVC controller part is missing but that it's merged with the MVC view parts into the MFC view.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I was wondering what kind of MVC pattern the illustration below is. We are developing a web application according to this pattern using ColdFusion and it goes pretty well so far. But is it even some kind of MVC at all?
A frontend page usually consists of:
- including the corresponding gateways (each model component has its own gateway with dedicated functionality)
- using the provided GATEWAY struct (contains components, arrays, structs etc. representing the desired data) to render output
- simple flow control (if/else/loops) to iterate through the provided data or distinguish view states
- if required: build forms (POST to same page) and name their field names according to GATEWAY specifications
The GATEWAY file (always separated from frontend page) validates the request (usually POST data) and takes care of the data retrieval (i.e. selects/inserts/updates on database). Usually the GATEWAY requests data regardless of actions (evaluation of runetime data like SESSION). All operations are fail-safe, so either there is data in the resulting struct or the data is empty. Either way, two arrays (success, errors) in the struct provide a log of all performed actions during the processing to react accordingly on the frontend page. Most data is provided as components (objects), but all in all it is not a fully object-orientied approach. The only thing they have in common is: they all describe input parameters (GET, POST, Session, Cookie) and outgoing parameters, like a (RESTful) web service.
I came up with a lot of ideas about the used pattern, but I wasn't able to match it in all regards yet.
To my mind the most important thing MVC provides is the separation between your view and your model. By doing this you can completely replace the view or the model without having to make changes to the other. In fact the main purpose of the controller is to act as the man in the middle between the two. Need to switch database servers, you shouldn't have to change out your view, or even your controller really. Need to create a new view, or replace the view you have, again you shouldn't have to mess with your model or controller really.
Ask yourself those questions about this proposed framework your going to create and the answers should come easy.
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/