I'm trying to move to a Model/ViewModel/View architecture and got stuck when trying to push selection dialogs to this pattern. I'd like to separate retrieving a list of choices (business/presentation logic) and the actual displaying/choosing mechanism (view) to re-use the former with different views (e.g. ComboBox vs. modal dialog).
How would a ViewModel for such a selection task look like? Or am I trying to hard, and I should implement this in the View only?
Do you mean that you would like to use the implementation to retrieve list?? If so, I think you can create a service class in the application layer and reuse the functionality..
Related
Let's say I have a bunch of kittens. Perhaps I have a KittenViewModel. I want to show it as a kitten card in a card view, but also as broken down into columns in a list view. Does MvvmCross support binding the KittenViewModel to multiple views? Should I have multiple ViewModels that refer back to a single model?
Disclaimer: I know that I am replying to an old question which you may well have forgotten; this is for posterity. Also, I have limited understanding of the MVVM design pattern. I remember reading somewhere that Views and ViewModels are typically in 1-to-1 correspondence, so the conventional answer is probably "You shouldn't do that. Reconsider your design."
With that being said, I recently struggled with this for a while before coming up with a very simple solution that operates under the following assumptions: (1) you wish to use the exact same instance of a ViewModel in two separate Views; (2) for whatever reason, you cannot use a DataTemplateSelector to determine which View to use; and (3) you do not mind creating multiple Views for the same ViewModel.
The solution is to define separate data templates for the KittenViewModel as resources for whatever controls you are going to use to display the data. For example, if you have created a KittenCardView user control and intend to display it in a ContentControl, you can set the DataTemplate in a ContentControl resource, something like:
<ContentControl>
<Control.Resources>
<DataTemplate DataType="{x:Type viewmodel:KittenViewModel}">
<view:KittenCardView/>
</DataTemplate>
</Control.Resources>
</ContentControl>
The KittenColumnView (or whatever you call it) would be handled similarly. You may find it helpful to define one of the Views as a Window or App resource if typically use one and only need the other in special circumstances.
Continuing to work on my port of a CakePHP 1.3 app to 3.0, and have run into another issue. I have a number of areas where functionality varies based on certain settings, and I have previously used a modular component approach. For example, Leagues can have round-robin, ladder or tournament scheduling. This impacts on the scheduling algorithm itself, such that there are different settings required to configure each type, but also dictates the way standings are rendered, ties are broken, etc. (This is just one of 10 areas where I have something similar, though not all of these suffer from the problem below.)
My solution to this in the past was to create a LeagueComponent with a base implementation, and then extend that class as LeagueRoundRobinComponent, LeagueLadderComponent and LeagueTournamentComponent. When controllers need to do anything algorithm-specific, they check the schedule_type field in the leagues table, create the appropriate component, and call functions in it. This still works just fine.
I mentioned that this also affects views. The old solution for this was to pass the league component object from the controller to the view via $this->set. The view can then query it for various functionality. This is admittedly a bit kludgy, but the obvious alternative seems to be extracting all the info the view might require and setting it all individually, which doesn't seem to me to be a lot better. If there's a better option, I'm open to it, but I'm not overly concerned about this at the moment.
The problem I've encountered is when tables need to get some of that component info. The issue at hand is when I am saving my add/edit form and need to deal with the custom settings. In order to be as flexible as possible for the future, I don't have all of these possible setting fields represented in the database, but rather serialize them into a single "custom" column. (Reading this all works quite nicely with a custom constructor and getters.) I had previously done this by loading the component from the beforeSave function in the League model, calling the function that returns the list of schedule-specific settings, extracting those values and serializing them. But with the changes to component access in 3.0, it seems I can no longer create the component in my new beforeMarshal function.
I suppose the controller could "pass" the component to the table by setting it as a property, but that feels like a major kludge, and there must be a better way. It doesn't seem like extending the table class is a good solution, because that would horribly complicate associations. I don't think that custom types are the solution, as I don't see how they'd access a component either. I'm leaning towards passing just the list of fields from the controller to the model, that's more of a "configuration" method. Speaking of configuration, I suppose it could all just go into the central Configure data store, but that's always felt to me like somewhere that you only put "small" data. I'm wondering if there's a better design pattern I could follow that would let the table continue to take care of these implementation details on its own without the controller needing to get involved; if at some point I decide to change from the serialized method to adding all of the possible columns, it would be nice to have those changes restricted to the table class.
Oh, and keep in mind that this list of custom settings is needed in both a view and the table, so whatever solution is proposed will ideally provide a way for both of them to access it, rather than requiring duplication of code.
I'm working on a XAML-based Windows Phone 8.1 project. My MainPage has a Pivot control, the first item of which is designed to be a "dashboard" of some sort, combining multiple kinds of data such as events and to-dos.
For this particular purpose I have an Event and a To-do model classes (not the actual name, but you get the idea), as I am using MVVMLight to run the show.
I have currently set up a ListView in a pivot item in MainPage.xaml. I was wondering how can I make it work such that all items with objects Event and To-do are at one single pivot item.
I've looked around and found CompositeCollection, but it's only on WPF, not on WinRT yet. I tried dealing with Midgard.CompositeCollection but the data doesn't show up, and I don't understand how can I style these independent kinds of data differently.
Are there any techniques on combining two datasets together on one set of lists but will be styled separately? Is ListView the correct control for dealing with multiple kinds of data, or is there something else?
I'm still quite new to this field; apologies if this is a basic concept I can't quite grasp yet.
Thank you!
There is a way and it is quite simple. Make both Event and To-do inherit from the same base class (could be empty) and create an ObservableCollection of this base type (can also be object if you do not want to create a separate class). Add both Event and To-doobject to this ObservableCollection.
Bind the ListView to this ObservableCollection. Now comes the tricky part. You need to create a DataTemplateSelector. For a compete guide, see http://blog.kulman.sk/using-different-data-templates-with-gridview-in-windows-8-apps/ (this articles is for GridView but it works the same for ListView).
Is it legal In MVC, so that a "model" make use of "services" to load some data ( from web) so that the data after loading can be passed into a list box of a "view" ?
My focus is on "Can Model make use of Services directly for such purposes?"
V.
I agree with Anshu's answer but I'm personally flexible about this kind of thing on my own projects if I plan them to be very small scale, that is it doesn't seem to always be worth the time to create the clear MVC separation. There's also MVVM based on MVC, some decent info on that on wikipedia and you can find it elsewhere http://en.wikipedia.org/wiki/Model_View_ViewModel
There's no set in stone rules when it comes to design pattern usage, but if you set your own rules and work within them (particularly adhering to MVC in one or more layers of abstraction) can be helpful particularly on large projects or where a team is involved.
So the answer to your question about a model making use of services is yes this is possible, is it conforming to a strict MVC pattern, no.
The model should simply be the structure that holds the data in whatever way the data relates to other data, that's what the model is made up of. The controller handles the dirty work of making the calls to the service and updating the model. The view simply is bound to or updated when changes to the model occur and makes use of the controller (usually in as3 by using event handlers on ui components) to make the right updates to the model (or calls to then update the model).
You'll likely have extra helper classes that may sort of fit somewhere in between or outside of the parts that make up the model the view or the controller, this is okay but you should be conscious of what purpose these serve and document them well and make sure it wouldn't make sense for them to somehow be handled more elegantly within the whole setup.
I would say, its rather the responsibility of the Controller to make use of services and populate the model with the data obtained from services.
This link should provide more clarity about the responsibilities of Model, View and controller in Actionscript-3
looking for best practices in web development, when you are writing a web application in a traditional non-framework environment (core PHP or Perl / CGI), what is the cleanest way to organize or map calls from the client to server processes?
The answer is rather trivial when working in a single-scope page where, for example, you have a form to complete and a submit button. You could set the action of the form to "save.php" and have a one-to-one relation between the page and the function it is bound to. So save.php could execute the save action and write to the client the form.
Now, the only non out-of-the-box php enhancement i'm using is a template engine (tinybutstrong). Whenever i have a complex page with multiple forms (for example, for sorting a grid, saving something, requesting something else, an ajax component and a search box), what is your way to lay down the various functions (search, sort, insert, retrieve) to a single display page (index)?
Do you use something like index.php?action=search / index.php?action=insert or something like setting each action to a page that acts like a function (search.php, sort.php, insert.php) each delegating the presentational function to a single script (index.php)? What if the "search" function can be used by varius "views"?
I'm using general terms like search or insert as an example, and the referece to PHP is also only for example, as I think my question is rather general on best practices.
Thanks.
By creating something where there's an action which refers you to a view, you're essentially creating a controller for views, and you're two thirds of the way to MVC. (not that there's anything wrong with that, just that's where you're headed)
Q1. what is the cleanest way to organize or map calls from the client to server processes?
A1. Using the filesystem, but structured semantically based on the structure of your data (if possible) doing something like /search/mysearch is your semantically correct option. Requires a little Apache Mojo
Q1. Do you use something like index.php...
A1. Yes, I wouldn't shy away from this approach. It's ideal to use a little Apache rewrite magic to create nice paths, but aside from that, there isn't any other magic way to create an controller.