This question is locked. New answers and comments are not allowed.
Justin Stuparitz
Top achievements
Rank 1
Rank 1
Justin Stuparitz
asked on 28 Apr 2010, 04:47 PM
is this needed? I thought one of the benefits of MVC in general is to have control over our html. this seems to violate that principal
5 Answers, 1 is accepted
0
Hi Justin Stuparitz,
The "-input" html element is added to the end of the NumericTextBox wrapper in order to ensure jQuery validation support.
Regards,
Georgi Krustev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
The "-input" html element is added to the end of the NumericTextBox wrapper in order to ensure jQuery validation support.
Regards,
Georgi Krustev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Justin Stuparitz
Top achievements
Rank 1
Rank 1
answered on 29 Apr 2010, 08:51 PM
You also add it to the id of the input of the DatePicker. Either way, you then wrap these inputs in a div and give that div the id of the control which doesn't make sense. It would seem that if you need identify these inputs for validation then you can use the id of the div, name it whatever you want and be all good. Renaming someones input is not cool in my opinion.
0
UPDATE:
Unfortunately, we will break our convention if we apply the aforementioned changes. After further investigation and consideration, we decide to NOT change current implementation. In other words, the input elements will have "-input" to its id.
As I said earlier, we do not observe any disadvantages using current approach regarding validation and so on.
Nevertheless if you need to have input HTML element with id attribute equal to name attribute, you can use InputHtmlAttributes of the component to achieve your goal.
Hello Justin,
In general client validation scripts relays on the name attribute of the input component. Hence the client validation still will work, even the id of the input is different than the its name property. Nevertheless we agree that the additional "-input" to the input id is not expected.
I confirm that we will fix this in the next official release of the Telerik Component for ASP.NET MVC (in the middle of July).
Nevertheless, it is interesting to share with us, which input's value - the value of the original (hidden input) or the fake one. If you can elaborate on your scenario, it will be great.
Best wishes,
Georgi Krustev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Unfortunately, we will break our convention if we apply the aforementioned changes. After further investigation and consideration, we decide to NOT change current implementation. In other words, the input elements will have "-input" to its id.
As I said earlier, we do not observe any disadvantages using current approach regarding validation and so on.
Nevertheless if you need to have input HTML element with id attribute equal to name attribute, you can use InputHtmlAttributes of the component to achieve your goal.
Hello Justin,
In general client validation scripts relays on the name attribute of the input component. Hence the client validation still will work, even the id of the input is different than the its name property. Nevertheless we agree that the additional "-input" to the input id is not expected.
I confirm that we will fix this in the next official release of the Telerik Component for ASP.NET MVC (in the middle of July).
Nevertheless, it is interesting to share with us, which input's value - the value of the original (hidden input) or the fake one. If you can elaborate on your scenario, it will be great.
Best wishes,
Georgi Krustev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
Justin Stuparitz
Top achievements
Rank 1
Rank 1
answered on 05 May 2010, 01:44 PM
Hi Georgi,
Thanks for the responses. I came across this as an issue, because we added the Datepicker to our existing pages and it broke a lot of our javascript. For new development, this probably wouldn't be such a big issue but for any projects that wanted to integrate telerik MVC into existing projects this could be time consuming and problematic. Simply because it goes against the MVC conventions. I realize you might have your own conventions, but this particular one is in conflict with the MVC framework convention. Most developers would expect that whatever name they give a control then that is the name that they will get. So for those developers who have a lot of legacy code that want to enhance their sites by using telerik, it's not as easy as it really should be.
I still feel that there should be a solution by using divs or whatever because in the end we're only talking about jquery selectors here, but I respect your decision and appreciate all the hardwork your team has done for the community.
thanks,
Justin
Thanks for the responses. I came across this as an issue, because we added the Datepicker to our existing pages and it broke a lot of our javascript. For new development, this probably wouldn't be such a big issue but for any projects that wanted to integrate telerik MVC into existing projects this could be time consuming and problematic. Simply because it goes against the MVC conventions. I realize you might have your own conventions, but this particular one is in conflict with the MVC framework convention. Most developers would expect that whatever name they give a control then that is the name that they will get. So for those developers who have a lot of legacy code that want to enhance their sites by using telerik, it's not as easy as it really should be.
I still feel that there should be a solution by using divs or whatever because in the end we're only talking about jquery selectors here, but I respect your decision and appreciate all the hardwork your team has done for the community.
thanks,
Justin
0
Hi Justin Stuparitz,
I want to shed more light over this decision of ours.
I totally agree that all built-in HTML extension methods use the "name" argument for the value of the "id" HTML attribute by default. The user can customize it further by using an overload accepting html attributes.
However ASP.NET MVC seems to only care about the "name" attribute - post values are retrieved by name not by id, validation works in similar way too. Telerik extensions do output the right and unmodified Name value as the name HTML attribute so they should be compatible with both validation and post value reading.
It would have been nice if we used the Name for the "id" attribute as well from the very beginning. You are right that it all boils down to jquery selectors. While this is true such a change would have broken lots of existing code. For example `this` in the client events would change from the outer wrapper (div) to the input. After a careful evaluation we decided that introducing this breaking change does not pay off provided the current implementation works.
If you want full control you can still achieve it. As Georgi pointed out you can use a few settings to control what gets output as HTML attributes:
<%= Html.Telerik().NumericTextBox()
.Name("NumericMinValue")
.HtmlAttributes(new {id="NumericMinValue-wrapper"})
.InputHtmlAttributes(new {id="NumericMinValue"})
.MinValue(-100000)
.MaxValue(100000)
.Value(Model.NumericMinValue.Value)
%>
Regards,
Atanas Korchev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
I want to shed more light over this decision of ours.
I totally agree that all built-in HTML extension methods use the "name" argument for the value of the "id" HTML attribute by default. The user can customize it further by using an overload accepting html attributes.
However ASP.NET MVC seems to only care about the "name" attribute - post values are retrieved by name not by id, validation works in similar way too. Telerik extensions do output the right and unmodified Name value as the name HTML attribute so they should be compatible with both validation and post value reading.
It would have been nice if we used the Name for the "id" attribute as well from the very beginning. You are right that it all boils down to jquery selectors. While this is true such a change would have broken lots of existing code. For example `this` in the client events would change from the outer wrapper (div) to the input. After a careful evaluation we decided that introducing this breaking change does not pay off provided the current implementation works.
If you want full control you can still achieve it. As Georgi pointed out you can use a few settings to control what gets output as HTML attributes:
<%= Html.Telerik().NumericTextBox()
.Name("NumericMinValue")
.HtmlAttributes(new {id="NumericMinValue-wrapper"})
.InputHtmlAttributes(new {id="NumericMinValue"})
.MinValue(-100000)
.MaxValue(100000)
.Value(Model.NumericMinValue.Value)
%>
Regards,
Atanas Korchev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.