This is a rather interesting issue that was quite hard to spot...and I cannot resolve it. In a nutshell, I have the following in a view trying to render a date field (ignore archiac syntax - it's an old project);
<%: Html.TextBoxFor(model => model.DateOfRenewal,
new {
type = "date",
placeholder = "DD/MM/YYYY",
Value = (Model.DateOfRenewal != null) ? Model.DateOfRenewal.Value.ToString("yyyy-MM-dd") : ""
})%>
Now on the model, the date format attribute is set to "dd/MM/yyyy" appropriately. We're rendering to "yyyy-MM-dd" when generating the HTML in order for a jquery library (webshim polyfiller) to pick up the date correctly when it starts running against the field. I don't have control over this library so I'm stuck with it and I have control only over the MVC side of things.
What's happening is that the field above looks ok when you inspect it but viewing the source shows the following;
<input Value="2008-05-12" data-val="true" data-val-date="The field Renewal Date must be a date."
id="Ratings_DateOfRenewal"
name="Ratings.DateOfRenewal" placeholder="DD/MM/YYYY"
type="date"
value="12/05/2008 00:00:00" />
Notice that Value
and value
are both present. The lower case version is what goes in there as part of TextBoxFor
and the uppercase Value
is what appears in my custom attribute when specifying in the view.
However, changing the custom attribute in the view from an uppercase to a lower case is runs fine but it does not have the custom date format. As a result, I get a blank field as webshim cannot interpret it.
Is there anyway to get a custom date format without;
- Changing the model attribute (required for server side validation)
- Changing/modifying the jquery library
In a nutshell, is there a way to get the custom formatted date as a single, lowercase value
html attribute when rendered?
EDIT
The marked answer below changes the lowercase value
to the specified format. To fulfill the original request, the MVC markup has to change to a lowercase value
as well. This fixes the issue.
EDIT2 The duplicate mark is invalid. While the situation is very close, none of the answers in the linked post work in this situation - inherently marking it as different.