DateTime not bound to Model

Jun 27, 2013 at 11:04 PM

I was hoping that I could use the @Html.DateTime("randomItem"....) to create a Date Time input that was not bound to a model. I was then going to get the date out of it and pass it through an Ajax call.

However it looks like the name in the DateTime input must be a property on the model. Is this correct? If so how can I generate dynamic controls that don't have relating model properties?


Jun 28, 2013 at 7:10 AM
Every control must be bound to some model...according to the MVC pattern. I am not able to figure out WHY you need something that is not bound to a model. The only explanation that comes to my mind is that you need it for some javascript manipulations...Also for javascript manipulations the Mvc Controls Toolkit uses a Model/View pattern based on knockout js, where you define client side viemodels and bind controls to them by using Client Blocks. In this case you may use the same simple controls like DateTime or TypedTextBox, that are bound to al client side ViewModel.

If you don't want to use Client Blocks that require too much learning time you may simply use jQuery UI date-picker(that is used to implement the DateTimeInput). See here. In general if you dont need something bound to a may use simply a javascript widget....there are tonnes of free javascript widget in internet...the difficult part is to connect them to a data source :)
Jun 30, 2013 at 8:03 PM
Yes you are right that we should bind to a Model - this is just a particular case where it would be easier not to do it. I was thinking along the lines of the MVC core controls that are already present, like TextBox. There is a @Html.TextBoxFor(m=>m.Description) which binds to the model but they have also available a @Html.TextBox("someId") which is not bound to the Model and just generates the control with an ID of "someId".

When I saw that you had a @Html.DateTimeFor and a @Html.DateTime I thought that you were following the same standards as the core controls. I didn't really see the necessity for the @Html.DateTime("ModelDate") since you can do a @Html.DateTimeFor(m=>m.ModelDate) which is much more reliable.


Jul 1, 2013 at 1:41 PM
The problem you encountered is specific of the DateTime-DateTimeFor. It ALWAYS MUST be inserted in a ViewModel, since it "looks" for constraints involving other DateTiMeFor belonging to the same ViewModel. If you use any other Mvc Controls Toolkit control susch as the TypedTextBox you will be able to use it as a normal TextBoxFor.

The peculiarity of the DataTimeFor is due to its capability of buidling networks of constrainst (< <= >= etc.) with other DateTimeFor .

Now, You are right you should never use DateTime instead of DateTimeFor....but the same is true for TextBox...actually also TextBox don't let you choose the esact name of the control, since it adds a "prefix" to all names. The prefix is set in the ViewDataDictionary. If you call the TextBox from the Main View the prefix is "" so you may decide the full bame...but if you call it from within a PartialView in general the prefix is not empty, so if you specify a name: "myname" in the TextBox helper your input will have the name: "prefix.myname"

TextBox type helpers were introduced BEFORE TextBoxFor helpers...that are more evolute, but if you DONT use the Mvc Controls Toolkit they are still usefull when the you want the TextBox to be bound to a model that is different from the main View VieModel. This happens, for instance, when the ViewModel that receives the post of your form submit is different from the ViewModel used to create the View.

If you do use the Mvc Controls Toolkit you may use howw many viewmodels you want in your View. In fact you may create other Html helper based on other ViewModels. This can be done with the CrossHelper:

@{var newHelper=@Html.CrossHelper(new MyModel{MyDate=DateTime.Now}}
@newHelper.DateTimeFor(m => m.MyDate..........).Date()

So in your case you may create the ViewmModel to use for your Ajax call and you may use the helper created with CrossHelper to render all controls involved in the call. The advantage of this Model/based approach is that you may specify validation rules for your ViewModel.

However, if you want that each call to ajax gives different names to all controls you cant use this simple approach and you must use client blocks that takes care of creating new names dynamically.