In DurandalJS I've got a View with a form. I would like to fill this form by binding it to a Kendo DataSource.
DataSource is used to bind collection of objects, not a complex object. Better have a look at the MVVM demo.
Related
Hi I am new to MVVM as well as to iOS programming. I am trying to convert my sample app into MVVM pattern.
Here is my simple use case-
I have one view controller class which holds information screen - InfoViewController. I has 4 informative labels with some text. Currently it is implementated in MVC pattern. viewDidLoad method binds iboutlets with text which is static. How can I convert this into MVVM? Here is my understanding
InfoViewController will have InfoViewModel which will be initiliase in viewDidLoad
Struct InfoViewModel will have
a.firstLabelText b. secondLabelText and so on..
In viewDidLoad method I will bind iboutlets with viewModel properties which will return text
Currently this text is static but it may come from web service in future so should I create model class here?
Is this correct way for this use case?
The best way to bind your view and view model is to include a framework that supports you.
E.g:
https://github.com/ReactiveX/RxSwift
https://github.com/ReactiveKit/ReactiveKit
I use RxSwift to bind my view model to the view. A nice introduction to mvvvm with rx can be found at https://academy.realm.io/posts/slug-max-alexander-mvvm-rxswift
As the title describes, I've got a tableview inside each of my collection view cells. For me, it makes sense that the superview's controller should control the view, but since in this case each tableview contains different data, I have made each superview (collection view cell) the controller for its tableview. I hope that makes sense. I know making a view to also be a controller violates the MVC paradigm, but I'm not sure what the proper way is achieve MVC compliance in this case. I also need to send messages to the table view based on what happens in the CollectionViewController. Do I need to subclass UITableViewController and make a reference to it in my collectionviewcell.h file?
Sorry if that was confusing. Thanks for the help.
I think your instinct is correct that having a view object serve as a data source is a violation of MVC. I would suggest having the owning view controller either serve as the data source for all the table views, or set up a separate model object for each table view that serves up the cells for that table view.
If you use a single data source you'll have to have a switch statement that figures out which table view is asking and fills the cells with the appropriate data.
My gut would be to create a thin table view data source class who's only job is to serve up the cells for the table view inside a collection cell (and respond to the other collection view data source protocol methods). Use a custom subclass of UICollectionViewCell that has a strong property that points to the data source object. You could make your custom cell class create an empty data source object at init time and hook up it's outlet to the table view.
Then in your cellForItemAtIndexPath method, pass the appropriate data to the cell's data source object. If you reuse a cell, it would already have a data source object, so you'd just replace the data with new data and trigger the reloadData method.
Your controller object would mediate between the model and the view, like it should. It would set up the model data for each cell, and then the data source object for each cell would act as the model for that cells table view.
If you later come up with several different types of collection cells that display different data, using separate data source objects for each cell would keep the code simple. You'd just subclass your data source object based on the cell type.
I'm very new to sitecore and just started learning sitecore over at a dev-course held here in town.
The course is WebForms-focused, and since that's not my "patter of choice" I thought I would see how far I can get using MVC in Sitecore.
However, I have a slight problem. I have noticed how there are Controller Renderers, but and how they are bound to a Controller and such. but how about using a Controller for a Layout?
Lets say I have a layout, that for instance might statically render a menu on the top of the site. Then in this case I would like to avoid having a huge amount of code in my view for rendering the menu-items. Instead I would like to have build and populate a custom view model with the menu items and then simply pass down the model to the view and iterate through my menu items within my model.
But I just cant find a way of how to create a controller for a Layout. Any ideas?
Actually, this is possible, you can create a model deriving out of RenderingModel class or implement IRenderingModel interface and assign it to any MVC rendering or layout in Sitecore. Model object will be instantiated by the Sitecore's GetModel pipeline defined in Sitecore.Mvc.Config file.
See Here
Another way to handle this scenario is to create a Menu view rendering and then insert into a placeholder defined within the layout possibly a header placeholder. This can be statically assigned via standard values.
Kevin is right, thats not possible. Actually, Sitecore uses the layout to recognize a view extension and handle the request with MVC (TransferMvcLayout processor in the httpRequestBegin pipeline).
You should consider an approach where you add a placeholder in your layout:
#Html.Sitecore().Placeholder("menu-placeholder")
Then add a Menu Controller Rendering to that placeholder. That way you can utilize the rendering cache as well.
I don't think this is possible. But you can create a Razor view as layout, which works same as a View Rendering. Just just need to specify the path to the Razor view in the Path field and insert a model. In the model you could have simple property, which loads your menu items from whereever you want:
public class MyViewModel
{
public IEnumerable<MenuItem> MenuItems
{
return MyMenuUtil.LoadMenuItems();
}
}
This avoids lot of code in the Razor view and also in the model.
I'm creating an MVC5 web application and was curious if what I'm doing is considered bad practice or not.
I've already made a table with paging. This is created by a partial view that loops through the models id, code and name properties and displays them. Since I want to make a generic table I've decided to derive all models from a model base class (BusinessObjectModel) and give that to the partial view. I've modified the partial view to use reflection to get the values of every property this way the table can display every property of the model. This works great and the only thing left to do is to create a custom attribute tag to control which property is displayed in the list.
Is putting such logic into the view considered as bad practice? Should I create a helper that would assemble this view in the controller instead?
I have a layout view for a specific section (group of views) in my MVC4 application, and this layout should contain a dynamic treeview with navigation options for views that use this layout view. E.g. My layout view says each dependent view will have a treeview at the left. Now the only way I can think of properly loading this treeview in the layout for each dependent view is have it as a mandatory section in each dependent view, and use a common base viewmodel for each dependent view that carries a viewmodel for the treeview. This seems very awkward. How else can I do this?
I'm not sure that I have understood your question properly, but I think the concept you are looking for is known as "Child Actions" - see RenderAction on MSDN.
This lets you do something conceptually similar to RenderPartial in your view, but rather than having to pass it a model, RenderAction lets you create an action to retrieve the model.
This frees you from your view needing the models for each partial view.