What is the use of AdditionalMetadata Attribute in MVC 3 . What is Use of that? Please provide me clear example how to specify and use it to render in browser.
Thanks!!!
It could be used to specify some custom properties that are not part of the standard metadata properties. Here's an article which illustrates an example.
Another option (and in my opinion a little bit cleaner, but it depends) is to use them through custom model metadata providers.
Here is one example of it.
Basically they are used for providing custom values from the model to the views, without requiring views to include logic to make these values up for themselves. Which results in a little bit cleaner and more generic views.
Related
I've got a situation where I want to show an object that isn't attached to a model, but I'd like to specify metadata for it so that the templating system displays it as if it were a model property with specified metadata. Something like:
#Html.DisplayObject(obj, metadata) <--pseudocode
That is, I have a free object obj and I know how I want it to be displayed (usual metadata stuff like DisplayName, FormatString, UIHint, etc.), but this object isn't attached to a model.
How can I hook into MVC's default templating logic in this situation?
(The reason the object isn't attached to a model, by the way, is that it's loaded dynamically at runtime, so there's no compile time place to add the property and decorate it with the metadata attributes. So I may really be asking about the right way to handle this situation.)
One possible option here is to implement your custom metadata provider. I never did it myself but this article on the topic looked useful and detailed.
Not a brilliant answer by any means, but in the end I just manually implemented the UI that I needed, factored into useful partial views and helper methods, and it really wasn't that hard. I also have complete control, which is nice.
I was going to implement a custom DisplayAttribute in order to allow dynamic display values based on model values, but I can't because DisplayAttribute is sealed.
Before I go off and write my own customer attribute that emulates the behavior of DisplayAttribute, can anybody think of why this is sealed? I'm assuming there is a reason behind it, and if so, that may be the same reason I shouldn't try to "hack" around this limitation by rolling my own.
I'm not asking anyone to read Microsoft's mind, I'm just hoping someone already knows the by-design reason it's sealed, so that I can take that into account when rolling (or avoiding) my own implementation.
In general it is considered best practice to seal attributes. FxCop has a rule about it, defined here. From that page:
The .NET Framework class library provides methods for retrieving custom attributes. By default, these methods search the attribute inheritance hierarchy; for example Attribute.GetCustomAttribute searches for the specified attribute type, or any attribute type that extends the specified attribute type. Sealing the attribute eliminates the search through the inheritance hierarchy, and can improve performance.
Many of the MVC attributes (ActionFilter, etc) are unsealed because they are specifically designed to be extended, but elements in the DataAnnotations namespace are not.
Not exactly what you asked, but following your intent...
You can still allow for dynamic display values, you just wont extend the DisplayAttribute.
Instead, you can implement your own IModelMetadataProvider which could contain any logic needed to create dynamic display values.
Brad Wilson, from the ASP.NET MVC team, has a good article and sample of this on his blog: http://bradwilson.typepad.com/blog/2010/01/why-you-dont-need-modelmetadataattributes.html
I know I will probably get a mixed opinion on this, but I was wondering if there were and "Best Practices" for model naming conventions.
I have a rather large application and I have adopted the following model naming convention:
Models
Add
CategoryAddModel
ProductAddModel
Edit
CategoryEditModel
ProductEditModel
View
CategoryViewModel
ProductViewModel
I was thinking of the following as well:
Models
Add
AddCategoryModel
AddProductModel
Edit
EditCategoryModel
EditProductModel
View
ViewCategoryModel
ViewProductModel
Which do you prefer, and why?
Do you think it really matters?
I prefer like {ViewName}{Controller}ViewModel. I also remove Models folder, instead I put view models in ViewModels folder. That makes more sense to me.
eg. AddCategoryViewModel
It doesn't matter. You should name things in a consistent, logical, and straightforward way. Basically, just pick something that makes sense and makes you most productive. Consider how your naming convention would work with IntelliSense.
You might also want to consider how easy your code will be to maintain a year from now.
To pull out Hightmaston's comment into a formal answer for clarity.
A logical template to follow would be:
{Controller}{ViewName}ViewModel
This encourages better file organization at scale, and reduces the number of Intellisense "hits".
A simple example might be as follows:
CategoryIndexViewModel
For brevity you may also consider:
CategoryIndexModel
In theory CategoryViewModel, CategoryAddModel and CategoryEditModel will contain the same properties, so there is little point tripling the number of view models you have in your UI. Just CategoryModel should suffice. It's the type of HTTP requests being received by your controller which defines whether it's a GET or POST operation. The model used to populate a view for a GET, or capture form data for a POST will be the same type either way.
Some users of our application will have read-only access to many of our pages, in our current web forms app this means they see the form, but all of the fields are disabled. We're looking at MVC 3 and searching for the cleanest, most idiomatic way of implementing this functionality.
Some ideas so far:
Some combination of a global action filter and edit templates.
A custom Html helper, something like Html.SecureTextBox etc...
I'm leaning towards number 1, but I'm wondering if any of you guys/gals with more MVC experience have solved this problem in a better way.
I agree with using a base view model, or perhaps just an interface with a "CanEdit" type of property. If you go the interface route, you could set the property in an ActionFilter in the OnActionExecuted method.
To tie it to the view, creating a new HtmlHelper would be pretty easy. I'd use TextBoxFor as the base class, since it has access to the view's model. You can then inspect the property and create the necessary HTML attribute. However, with going this route you will need to create a new helper for each type of input control you need (textbox, select list, etc).
Without knowing all the details of what you are doing, a much simpler idea would be to not provide a Save button for read-only users. The Save button would be driven by one property in the view model (or ViewData, if you like).
Several other people mentioned that a server-side restriction is still needed to prevent people from bypassing the client-restrictions. You will need an action filter for this. This link has a good idea about that.
My preference would be to set a variable in a common base view model (or ViewData), using a global action filter, and then use a bit of jquery to dynamically disable the input fields, delete buttons etc.
$(':input').attr('readonly', true);
We need to generate forms for Create/Display/Edit on our website. The requirement is that these need to be metadata driven. We will have properties on our Model attributed with the type of control to generate for that property.
[RenderAs("DatePicker", Order = 1)]
public DateTime DateOfBirth{get; set;}
The idea is to have templates for each of these like Date-Picker.ascx, etc in the SharedFolder
We need to generate around 25 such forms and are looking for a reuseable way of accomplishing this. What would be the best way to handle validations with this (basic validations like required, less than, greater than, etc)? What do you suggest for dependent field validations (less than field, greater than field)? Does this sound sensible?
Thanks
It sounds like you're looking for MVC 2 templates.
Use DisplayForModel for read only views and EditorForModel for create/edit forms built from the metadata in your view model. Use Data Annotations attributes to decorate the view model with validation rules and other rendering information (label, custom template to use, etc.).
Here's a quick intro video to MVC 2 templates.
Check out ASP.Net Dynamic Data. It is pretty much what you are looking for. (And if you can use .Net 4.0 then you should be able to use MVC, webforms, and DynamicData all in one project.)
You are mixing Model and View concept. Why do you need MVC THEN?
On practice, you will face situations when Admin need some minor changes compared to regular user, and it will be hard to support in cases when form is generated using attributes.
I am not saying this is best, but we decided to stick with form concept and every form able to decide WHAT to show and HOW to show.
And we defined number of helper methods like RenderDatePicker which do all dirty work.