I have a conditional business logic that determines whether a property from a model should be displayed in a view. according to best practices where would be the place to implement it?
Implementing this logic in the view level does not seem right to me.
Thanks
IMO, it is belonged to the Model. I would put that business logic in IsRequiredYourProperyName property in the model.
Really? I would have thought that would be fine in the view provided you're passing the boolean indicating whether or not it should be displayed as part of the ViewModel. The view shouldn't be querying an outside resource to see if it should render certain UI elements, but if everything it needs to determine what to render is in the ViewModel, what's wrong with a simple if{} statement? Alternatively if a conditional display property is common you could create a custom DisplayTemplate or EditorTemplate and for it and implement the logic there.
So your ViewModel should wrap everything you want to send to the view. in your case it sounds like it should wrap your DomainModel and some sort of dictionary or KeyValuePair collection detailing if each property should be displayed or not as booleans. That's what I would do anyway.
Related
I have created a base viewmodel that all of my view models inherit from. That part is easy.
All views are bound to a viewmodel (all are inherited from the base view model)
Within the OnActionExecuted method I insert a true/false value onto a property within the baseviewmodel depending on some conditions.
From the view side of things. I have a single layout page that some how I want to be able to read the property's value and render a different partial view based on the value.
Is this possible? I dont want to have to add the code to each of the views but I don't think I should be binding the layout to my baseviewmodel either.
If I can stay away from inserting the value into the valuebag that would be great as I need to be able to access these values anywhere in the application via strongly typed names.
what you want probably isnt possible because as you call a view from the controller then first the code inside that view is executed and then the layouts code is executed
to achieve what you are doing you can do 2 things
1. make the logic inside the controller itself and then render the correct view
2.call the layout from the controller giving it the name of the partial view in some property of the model or in the viewbag
Not sure I quite follow the use case, but rather than trying to render out a partial view, have you thought about nesting your layout pages.
I think you should be able to override the layout in the onactionexecuted, so you can set the layout dependant on the bool and that layout will render only the correct option.
Look here for an example:
Nested layout pages with Razor
HTH
Si
I have an MVC3 project I'm working on that has a View with an associated strongly typed view model. I've been tasked with adding an optional section to this view that would contain the data for a second model, about half of which is shared with the first model.
My question is, what is the best way to implement this? Should I just add the object that the optional model represents to the view model and try to map values from there?
If I do it this way, how can I associate the editors with both models?
Adding the optional model to the view model is the best choice, because, unlike ViewBag, it's type safe and you can still leverage the html helpers. Just remember to check the second model for null reference before you render it (since it's optional).
For sharing properties, your view model can have special getters/setters that would mantain both models synchronized internally.
I think I understand what your asking and this is how I have accomplished it in the past.
Add the optional model as a parameter in the view model and then create a partial view that is typed to that optional model. If the criteria is met that allows that partial view to display then you pass the viewmodel.optionalmodel to that partial view.
You just have to be a bit careful about the overlap of parameters causing any headaches (as in null references)
In MVVM Light toolkit for Windows Phone, whenever I am to add a new MvvmLightView (WP) item, I end up with the template creating a PhoneApplicationPage for me.
What about cases, when I want to create a nested view, for example in case of a ListBox ItemTemplate view.
Before MVVM Light, every time I needed a view to separate markup to, I would have created a standard UserControl and that worked fine.
Should I only use MvvmLightView whenever creating a navigable pages?
The item template is a guidance, that produces some code for you. It is not, nor does it intend to be, the single way of creating views or sub views.
In the case you are mentioning, it is usual to create a user control hat is backed on its own view model. This sub-view view model is then included as a property in your main view model. To pass it to your sub-view (e.g. a user control) you bind this property to the user control's DataContext.
<ext:MyUserControl DataContext="{Binding MySubViewProperty}"/>
However, you do not need a separate view model, in some cases it is more appropriate to share the main view model. In this case you do not need to do the above binding, as it is do one implicitly. Also, when you are using the user control within an DataTemplate the templates DataContext is passed to the user control implicitly and you do not need the binding. In general you only need to set the data context when you want to bind to a property of the current context, or to another context.
MVVM is about freedom and MVVM Light about supporting the developer in using this freedom. All guidance are best practises and provide usually the easiest an/or most consistant way, but nothing stops you going down another route for a good reason. Especially the templates are just shortcuts that provide for one problem, but not for the general (meaning every) case.
Being a relative newcomer to MVC I'm musing over a little problem. I'm developing a page which relies on a collection of my viewmodel objects. All good. But, as the page has relatively complex functionality I need to get at other objects or collections of the main domain model to display in the UI. Admitedly rather more light weight objects. What's the best way to achieve this?
What I do is create a custom class to encapsulate ANY data I need to display in any certain view / action. So for my Admin areas User controller, I have a AdminUserIndexViewModel class that holds my list of user business objects. I also put any other data I need to display into this class.
For my AdminUserEditViewModel (that corresponds to my Admin Area, User Controller, Edit Action) I might have a single User class, which itself has its Roles attached to modify if need be. If you need to put other information like user settings, or preferences, etc...
If they are not part of the viewmodel you are currently working with then you can use Html.Action to call into another controller method to render another inline view through a controllers method.
I have 2 Cotrollers.
First one sets the ViewData property like this
ViewData["Error"] = "something";
I am able display this message on the page.
Second Controller loads the grid.
When i try to set the ViewData property from that Cotroller, It does not show up on the page.
Do you why? Am I doing anything wrong here?
Please let me know.
Thanks!!!!
Using two controllers for a single view is a bit of a no-no.
Look into ViewModels to pass all of the required data to your view. You can then create a PartialView for your grid, and pass the necessary model to the Partial View as well. Consider ViewData / ViewBag a last resort when a ViewModel doesn't work.
Are you trying to use two separate controllers to render the same view? If so you should probably consider, breaking the view logic of your "grid" into a partial view that you in turn render within your primary view.
As you mentioned "ViewData" twice, another item for consideration is the implementation of the ViewModel Pattern. The Viewdata dictionary approach is fast and fairly easy to implement. however, it is not type-safe and errors due to typo's will not be caught at compile time.