This question is conceptual, hopefully it doesn't cause a fuss.
I'm fairly new to Backbone, especially when it comes to deciding what should be a model and what shouldn't. I'm trying to do something similar to Trello's behavior, where a single card may or may not have a set of UI features like checklist, due date, members and so on. My question is:
Can anyone offer ideas on how to structure the "card" to "parts" relationship that would allow me to add/remove individual components from a larger parent. I currently picture a UI piece (i.e. checklist) as it's own model but am unsure how I would connect it to a parent card, which would presumably be a model as well.
I understand models, view, and collections, but due to inexperience have trouble delegating what app component should be what, and how to structure relationships. I'm not looking for "the right" answer as approaches will vary, but more so insight in how people structure their set ups and what common practice may be.
It's difficult to give a good answer that's more definitive than 'it depends'. On the UI side, you're probably going to have a parent card view and then views that extend the card view, like listCard, checkCard or textCard. This allows you to DRY with components of the card view that remain useful across the different types of cards (drag/drop, delete, etc.) but also implement custom behavior for each type of view in the view's subclass (like templates or interface functionality).
On the model side, you will, I presume have a pretty different data structure underlying each card, so for that reason, I'd probably be tempted to create a different model for each card type. But it will ultimately depend on how you want to structure your database, and how different your data behind the card types will be.
In case anyone stumbles into this and has a similar question, the concept I was missing and needed to make my set up work is a Controller, which makes sense since those are missing from BB by default.
I needed something to hold a reference to widgets which may or may not be added to a "card" arbitrarily. A Collection didnt seem quite right in this case but a self created Controller class does the trick.
Related
I would like to know how you are Design your Qooxdoo Code.
I don't get the right Architecture which I am satisfied with.
It is hard to encapsulate the View with logic like services.
I hope someone can give me a hint to a Pattern or something to find a good solution.
One of Qooxdoo's greatest features is a strong OO class system, so really the pattern that you use is up to you - MVC, MVVC, etc are all possible because Qooxdoo's OO system provides you the tools to implement your preferred pattern(s).
One pattern that I find very useful, especially in creating larger apps, is to define custom widgets for editing models; for example, if you have models (aka "Business Objects" etc) for Customer, Invoice, InvoiceLine, and Address having a widget for CustomerEditor, InvoiceEditor, InvoiceLineEditor, etc is really useful firstly because it encapsulates the code, but also because it supports binding.
Binding is a very powerful feature of Qooxdoo - to see why, let's assume for a moment that each one of your Editor widgets has a property called value which is the thing being edited.
In simple binding, your editor can bind properties of the model to the widgets which display and edit those properties, eg CustomerEditor bind value.firstName and value.lastName to a couple of qx.ui.form.TextField and automatically changes to the customer's firstName or lastName will be updated in the two TextField's. Binding can work the other way around too, so that changes to the TextField are copied back into the model.
There is a controller class called qx.data.controller.Form that can simplify making this happen, and optionally incorporate validation of user values and user feedback too.
If you have separate Editor widgets, you can also bind to them - for example, Customer could bind value.address to an instance of AddressEditor, and InvoiceEditor could bind the currently selected InvoiceLine to InvoiceLineEditor etc
I just need a simple clarification:
I have an example application with a Model of a ball, and two views (lets say one shows the ball and lets you resize if with the mouse, change it's colour with a click, the second has a control with two child controls (size textbox and colour picker)).
Does MVVM say I must have two VM here, one for each specific View, or am I allowed to reuse the VM without breaking the pattern?
As a follow up question, if I am required to have two VM's is it legitimate, according to the pattern to have one as a derived type of the other, or both as derived types of a base class, or composite classes based on common parts? Basically fulfilling the need for two types but improving reuse?
My example is contrived, I've tried to make the point that both Views affect the same two properties of the model. Max size, available colours, etc are the same between both views.
Thanks
Use the same coding practices in MVVM that you use anywhere else. In particular, stay DRY. So if you can use the same view model, then do so. I would say reuse of a view model is extremely rare though. If you later have to refactor into two separate view models but can derive from a common base class to reuse common parts, etc. then do so.
Yes, VM is very specific to a view and likelihood of re-using is very slim.
In fact I would go further, if you can re-use a VM then I would say it is most probably duplication of the view.
The only exception I can think of is the child view in a nested hierarchical object model structure.
It is entirely appropriate to share ViewModels in this situation. A ViewModel is the glue that allows a View to create a representation of a Model. If you have two Views that represent the same aspects of the Model, it is logical to use the same ViewModel.
If you find over time that the Views are different representations of the Model, then you need to revisit the design.
Although not directly answering your question, check out this insightful post from Josh Smith regarding the re-use of ViewModels and the "friction" caused from sharing: http://groups.google.com/group/wpf-disciples/msg/c29b3935ec9d3c4e
He is basically proposing an improvement to MVVM (calling it MMVVVM; phew!) - the extra MV is for ModelView. As the others have mentioned, the ViewModel is specific to a View and re-using that is not very likely. But rather, create a wrapper around the Model (the ModelView), which can be re-used with any ViewModel.
We had a case some time ago where we needed a view duplicated in several places, but the underlying types of the views and viewmodels were different. In that case, we created a generic viewmodel and passed in the underlying types as parameters when constructing the viewmodels and were able to avoid code duplication that way. As the others say, this situation is rare so most times you'll be creating new viewmodels (although all viewmodels will probably inherit from a common base class for e.g. property notification.)
We also tend to create POCOs from our database entities so that our database context isn't changed until we really want to apply changes (i.e. the MMVVVM(!) pattern that Chris described)
Well , In MVVM pattern it is good practice that two models should not know or talk with each other. That means you should not create a object of one model in other and then register for event or performing similar things.
But why, what is wrong if two models know each other. I am writing the code and what will happen if both my models know each other.
If you are going to circumvent MVVM in any way you want to have a good reason (otherwise you might as well just write it as traditional code-behind and save some typing) :)
There are several benefits of using MVVM, which are mainly to do with very loose coupling, unit testing and reuse.
The basic principal of loose coupling goes something like this:
A View knows how to display data of a certain shape, but has no idea where the data comes from.
A ViewModel provides a certain shape of data and settings, that views can use, but has no idea who is displaying it.
A Model knows how to hold generic data, but no idea who is consuming it
A Controller (missing from most MVVM explanations) decides what data to fetch, what data to display and where to display it. This is where the decision making belongs.
If you require your ViewModels to know about each other, then you are most likely missing a Controller object that manages your 2 ViewModels and associated Models/Views.
If you can provide more information about why your models are currently linked, I may be able to suggest an alternative.
It's often perfectly appropriate for view models to interoperate with each other. Parent/child relationships in the view involve the parent view model holding a collection of child view models, after all. There are any number of circumstances in which, for instance, the availability of commands in the parent view depend on the state of its children. It's sometimes appropriate to delegate this to a separate controller class, but it's also often not worth the effort to do this.
It really depends on the overall complexity of your application. Sometimes that kind of effort is essential; sometimes it's just gold-plating.
I often hear a Model must be wrapped by a ViewModel that the View is not coupled to the Model/not aware of it.
With MVC it is common to bind the View to the Model... nobody complains so what ?
I am frightened of creating all that wrappers and doing nearly only duplicating property stuff.
In some cases you don't need to, just as you don't need properties in many cases but can get away with public fields.
But your model should mirror the domain structure and logic, while a view model mirrors the UI structure and logic. At least, as far as I understood it. Those two are not necessarily the same and each one can change independently from the other.
You should always apply a pattern to your individual problem, and modify it in areas where it does not apply. Just because the pattern implies the usage of a view-model, doesn't mean you necessarily need a view-model in every scenario. In the case that your model exposes all of the needed properties and no further abstraction is needed, maybe a view-model is unnecessary.
However, in many cases the view-model will eventually be of great use and far easier to maintain than adding extra properties to the model. Consider this carefully before binding directly to the model.
The ViewModel is used to only pass the data that you really need to a view.
When you use the model, instead of the viewmodel it is possible that you use data that came directly from the database.
When using the model the wrong way, it is possible to edit data in the database that you don't want to edit.
It is safer to use a ViewModel.
One point which didn't seem to come up (directly) yet is that ViewModel can easily support data that should never even be in the model such as the text typed in the search text box or selected list items in case these values are needed in commands or further data bindings and passing them as parameters every time seems like too much trouble.
But as stated already, if you are confident that all the data you need is already available in the Model, go ahead and do away with the ViewModel.
One common scenario where ViewModels come in very handy is when Enum values should be displayed. In my eyes, a ViewModel is the perfect place to convert Enum values to user-friendly representations. You could even introduce a localization step in your ViewModel.
Furthermore, ViewModels can simplify some other scenarios. However, as you said, they can also duplicate a lot of code. That said, you could create a ViewModel with a Model property which allows to bind directly to the properties of the Model class. Now if you later realize that you need some conversion step, you can still add that property to the ViewModel and bind to that property.
But I think in most cases it makes sense to use a ViewModel from the beginning because it might be hard to introduce it in a later development stage.
There is no problem binding directly to a Model from your View where possible.
What you will find though is very quickly you run into a situation where you need to model things your view needs that aren't in your Model.
Given you never want to corrupt your Model with View concerns, you are left with no choice but to create a ViewModel.
It depends on may indicators: e.g. if your model is provided by EF there's no point in exposing it to your View - why the heck the View would need all model's method/properties and tons of stuff (not mentioning data security) But if your model is really simple and you feel, that you're not going to expand/change it much by and VM, there's nothing on the way to use it just like that :)
You might as well ask, "What's wrong with putting all the functionality of my program into one giant class?" On the one hand, there's nothing wrong; it can be made to work. On the other hand, everything is wrong: if your program is one big ball of wire, you have to straighten all of it out in order to change any of it.
Look at a Windows Forms programmer written by a beginner. You'll find all of the business logic in the buttons' Click event handlers. What's wrong with that? Don't you want that logic to be executed when the user clicks the button?
This is essentially what you're proposing doing within the world of WPF. Will it work? Sure. For trivial projects, it may even work well. You're accumulating technical debt, though, and when the time comes, you'll have to pay it off by refactoring your code into something manageable.
In CakePHP I have a layout created and named default.ctp. In that layout I have a sidebar with some blocks and there're some statistics taken from the database.
My solution: I just created model called Sidebar.php and there're some functions, then I set up data in controller to display it in layout. Is this the best solution? As far I know, I will have to re-set every data in every controller, so need suggestions how to solve that.
Bear in mind that this is coming from a 10,000' level - I know nothing of your particular circumstances, but IMO it's not the best solution. I say that because you've created a model that represents a presentation component. If it were me, I'd probably look at using an element for display. Displaying dynamic components gets a little dodgy, but can be done without violating the MVC "covenant".
Your models should represent your domain entities (you've mentioned nothing about what your stats represent, so I won't offer any specific examples), not how they're presented.