I want to know if #Html.Editfor use databind. In http://msdn.microsoft.com/en-us/library/system.web.mvc.html.editorextensions.editorfor(v=vs.118).aspx
They say that it use a for each method, but one of my colleague makes me doubt by saying that this is databind.
They have mentioned on their page
Returns an HTML input element for each property in the object that is
represented by the .....
Here they are saying that #Html.EditFor is available for each property of the model. Its not same as its using foreach. This is indeed data binding.
Related
In MVC if you want to create an editor for a property or a display for you property you do something like that:
#Html.EditorFor(m=> m.MyModelsProperty);
#Html.DisplayFor(m=> m.MyModlesProperty);
Why do we have to pass a delegate why can't we just pass the model's property directlly? e.g.:
#html.EditorFor(Model.MyModlesProperty);
The reason for this is because of Metadata. You know, all the attributes you could put on your model, like [Required], [DisplayName], [DisplayFormat], ... All those attributes are extracted from the lambda expression. If you just passed a value then the helper wouldn't have been able to extract any metadata from it. It's just a dummy value.
The lambda expression allows to analyze the property on your model and read the metadata from it. Then the helper gets intelligent and based on the properties you have specified will act differently.
So by using a lambda expression the helper is able to do a lot more things than just displaying some value. It is able to format this value, it is able to validate this value, ...
I'd like to add, that besides the Metadata and making the Html helper strongly typed to the Model type, there's another reason:
Expressions allow you to know the name of the property without you hard coding strings into your project. If you check the HTML that's produced by MVC, you'll see that your input fields are named "ModelType_PropertyName", which then allows the Model Binder to create complex types that are passed to your Controller Actions like such:
public ActionResult Foo(MyModel model) { ... }
Another reason would be Linq to SQL. Expression Trees are the magic necessary to convert your Lambdas to SQL queries. So if you were to do something like:
Html.DisplayFor(p => p.Addresses.Where(j => j.Country == "USA"))
and your DbContext is still open, it would execute the query.
UPDATE
Stroked out a mistake. You learn something new every day.
The first example provides a strongly-typed parameter. It forces you to choose a property from the model. Where the second is more loosely-typed, you could put anything in it, even something that isn't valid property of the model.
Edit:
Surprisingly, I couldn't find a good example/definition of strong vs loose typing, so I'll just give a short example regarding this.
If the signature was #html.EditorFor(string propertyName); then I could make a typo when typing in the name and it would not be caught until run-time. Even worse, if the properties on the model changed, it would NOT throw a compiler error and would again not be detected until run-time. Which may waste a lot of time debugging the issue.
On the other hand with a lambada, if the model's properties changed you would get a compiler error and you would have to fix it if you wanted to compile your program. Compile-time checking is always preferred over run-time checking. This removes the chance of human error or oversight.
Is is possible to see if just one property is valid in the knockout-validation plugin?
I could not see any reference to it in the documentation, only the ability to see if the whole model is valid.
For example I wish a computed observable to have a different value depending upon if another observable is valid.
I was being led down the wrong direction, as I was using async validators and over complicated my problem, I think it is as simple as:
propertyName.isValid();
e.g.
self.email.isValid();
I just created a custom template for all elements with an FunctionPickerAttribute (custom attribute that I wrote myself). Now, what the FunctionPickerAttribute does is simply to store the name of a method that returns a IEnumerable<KeyValuePair<String, String>>.
The template I created finds that attribute, finds the method (using reflection) and is then supposed to call that method upon the object. However, the problem is that FunctionPickerAttribute is assigned onto a property of type string, so that when I enter the FunctionPicker-template I have no idea of how to get a reference to my object.
I can find the type of the Container (using ViewData.ModelMetadata.ContainerType), but I need to get a reference to the Container in some way. Is this possible? And if it is, how do I go about making it?
Not the way your doing it.
The only way to get the container is pass the entire model to your template.
If you post more of your code I could help better. I do this type of thing often.
I'm using a GSP for sending out emails based on the MailService plug-in. The sendMail closure passes (amongst others) body(view:..., model:myModel)
I know that I can access every item of the myModel Map just using ${itemName} in the GSP. However as I sometimes want to build the item name dynamically like 'item'+i, I need to have some surrounding method to access the variable.
I already tried ${model.get('item'+i), and ${params.get('item'+i), but model is null and params is an empty Map. I also tried pageScope, but though I can access an item via ${pageScope.itemName, I can not use ${pageScope.get('item'+i)} because pageScope is not a Map.
Probably there are multiple solutions to solve this; I'd be glad about an easy one ;-). One solution I see is to pass myModel as the only parameter and then always use myModel.get(...), however this would mean that I had to change all my existing GSPs to always refer to myModel instead of accessing items (with fixed names) directly; so if there's a way where I don't have to change the model passed to the GSP, this would be my favorite.
If someone could also say a few words about the difference of model and params in this context, this would be additionally helpful!
I've managed it now using ${pageScope.getProperty(...)}.
There's no 'model' scope or variable. Instead objects in the model map are set as Request attributes to make them available to the GSP. This is a Spring feature which makes it easy to access variables in JSPs using JSTL and since the GSP syntax is very similar to JSTL it works the same way in Grails.
So you can use this:
${request.getAttribute('item'+i)}
to access model variables using dynamic names.
You can use ${fieldValue(bean: book, field: 'title')}
See: http://grails.github.io/grails-doc/latest/ref/Tags/fieldValue.html
In my understanding, the ViewModel pattern was designed to pass all the relevant data to View because 1) the view shouldn't perform any data retrieval or application logic and 2) it enables type-safety, compile-time checking, and editor intellisense within view templates.
Since dynamic expressions are defined at runtime, does this mean we don't get any of the 2)'s goodies?
You do not lose any of the existing functionality. You can still have a strongly-typed view such that when you access the Model property it will be of your specified type. The only thing that is added is a shorter way of accessing items in the ViewData dictionary.
Instead of the following
ViewData["MyData"]
you can have
View.MyData
Notice that you do not lose any type-safety because you never really had any. In the former case the key is a string (no certainty that it exists in the dictionary) and the value is an object so unless you cast it you can't do that much with it. In the latter you also get no intellisense and the returned value must be cast to something useful.
In fact the implementation of View.MyData simply takes the property name ("MyData") and returns the value coming from the ViewData dictionary.
Arguably the one thing you lose is the ability to have spaces or other characters that are not legal C# identifiers in your key names.