[CLOSED] DateField should not have a default format on the server-side

[r_honey]

This is not actually a logic bug, but more of a design bug in my understanding. ExtJs DateField default format is n/j/y.

Ext.Net uses "d" on the server-side which somehow translates to "n/j/y" on client side (I am not sure how this translation happens). This makes it very difficult to enforce global default date format according to application needs.

We have a very large CRM deployed across boundaries and we need to enforce our default date formats according to complex rules.

I created a plugin for DateField and deployed it across client-side. So anytime "format" is not specified in DateField's config, the plugin kicks in and specifies the desired date format according to rules.
You should notice that if "format" is specified in "DateField" config, the plugin needs to honor it otherwise use the rules to specify its own.

This terribly fails because any <ext:DateField> renders with format: 'n/j/y' to the client.

So, I switched to server-side using Ext.Net.Utilities.FindControls<DateField>.

This also failed because DateField.Format defaulted to "d" on server-side. I again cannot override server-side because the developer might have actually placed "d" or "n/j/y" as the Format because for that field, this was the fixed format that should not be overwritten (imagine a DateField for Credit Card expiry dates, its format is "n/y" which should not be overwritten).

What would have been a regular task with an ExtJs plugin has turned into an almost impossible situation because <ext:ateField> enforces a Format server-side and client-side.

So, I would recommend removing default formats for <ext:DateField> on server-side, and do NOt render with "format" in config if "Format" was not specified explicitly on the server-side.

[Vladimir]

Hi,

If you set date format on the client side (without specifing it on the server side) then how we can parse submitted date string without knowing correct format?

[r_honey]

Hi vlad, I assume you mean parsing when DateField is submitted to server (via a PostBack). Now I believe you serialize the DateField value to a Hidden field on the page.
You can use a known fixed format (e.g. the Universal Serializable format, "s" in .Net) for serializing dates to the hidden field and use the same to parse the value on the server-side. The "format" option on DateField is practically for display purposes and should not make a differnece on how Ext.Net serializes the value to a hidden field and parses it on the server.

[Vladimir]

Hi,

We don't serialize a date to a hidden field.
DateField is input html element already and can be submitted via form

On the server we have the same text (text from date input field) as on client side. If we don't know correct format then we cannot parse it

[r_honey]

DateField is input html element already and can be submitted via form

That is correct, but:

We don't serialize a date to a hidden field.

This is surprising. I think sometime earlier (maybe more than 1.5 years, because it has been more than 20-22 months since I have eliminated all post-backs from my pages) when I analyzed Post back data, I had an extra Id_Hidden field for each DateField value submitted to the server.

In any case, you can always use an extra Hidden field for the same and serialize the value of a DateField to the hidden field and use it on the server to parse it.

[Vladimir]

Hi,

Ok, I will discuss your request with Geoffrey today and let you know about the result

[geoffrey.mcgill]

Hi,

I'll give some background information regarding the DateField, and then I have a few questions.

Information

To the best of my knowledge, the DateField has never had an additional hidden field submitted. There's always been just the main input field which submits the date string, which is then parsed server-side as per the .Format.

The <ext:DatePicker> does have a single separate field which stores the date selected as a string, formatted and ready to be parsed server-side.

The value of the DateField .Format property defaults to 'd', which is the .NET DateTimeFormat.ShortDatePattern. The ShortDatePattern can be (is) different for each culture. In Ext.NET, the .ShortDatePattern is fetched from the .CurrentUICulture value of the CurrentThread.

System.Threading.Thread.CurrentThread.CurrentUICulture

The value of .Format (default='d') is then transformed from a .NET DateTime format specifier syntax (default='M/d/yyyy') to a PHP format specifier syntax ('n/j/Y').

If only using ExtJS (no Ext.NET), the format of the DateField, if not explicitly set, is set by the /locale/ file loaded. By default the .format is 'n/j/Y'. If the ext-lang-en-GB.js file is loaded, the default .format is set to "d/m/Y".

Questions

I created a plugin for DateField and deployed it across client-side. So anytime "format" is not specified in DateField's config, the plugin kicks in and specifies the desired date format according to rules.

Can these rules be determined server-side?

...according to complex rules.

Can you elaborate? Are you talking client-side or server-side rules? why try to override client-side?

What would have been a regular task with an ExtJs plugin has turned into an almost impossible situation because <ext:ateField> enforces a Format server-side and client-side.

Ext.NET does not enforce a .Format. It's a property and can be changed to whatever value you wish.

Here's a few ideas that came to mind, that might be options for you to work-around the issue.

1. Sub-class the DateField and create you own <rahul:DateField> component. Override the .Format property.
2. Use a .skin file to globally override the .Format property of all DateField components.
3. The .Locale can be set in several different places:
   
   1. ResourceManager [applied at the Page level]
   2. Session object [applies Session wide]
   3. Application object [applies Application wide]
   4. Web.config file [applies Application wide]
4. Set the Page/Application wide CurrentUICulture. Various ways to do this.
5. Further develop your client-side DateField override to do the following.
   
   1. Rename the DateFields input field .name attribute to something new.
   2. Create a new HiddenField with the original .name attribute of the main input field from 'a' above.
   3. Handle all the relavent DateField events to sync the two fields. Input field 'A' will be set with the format you require. Input field 'B' (the hidden field) will be set to the format the server-side requires for parsing.
6. Server-side, determine what .Format you require and set the .Format property of each DateField as required.
7. The .Locale can also be determined from the client browser. Just set .Local="client" and the UserLanguage from the client (requesting) browser will used, or at least attempted since it's not always 100% guaranteed this information will be available in the Request headers.

I guess part of the problem is I just don't 100% understand your position and I'm not sure why/how the current DateField .Format functionality is considered a defect. More information is required.

[r_honey]

I guess part of the problem is I just don't 100% understand your position and I'm not sure why/how the current DateField .Format functionality is considered a defect. More information is required.

Just to clarify, I never said it was a logical defect. I said I considered it a design issue and all people can have their own approach to the design aspect of a particular situation :)

To the best of my knowledge, the DateField has never had an additional hidden field submitted.

Thanks for the details. It might be that I am short on memory but I still recall I saw a Hidden field associated to DateField. Now I might be wrong here and Ext.Net (oops Coolite was what it was at that time) team might be correct.

Can these rules be determined server-side? why try to override client-side?

Yes they can be determined server-side (and indeed they are). The reason I chose client-side implementation is because as is obvious, its far easier to override ExtJs components in javascript then trying to do so server-side.
Secondly, we have a very large UI (a basic screenshot attached, more fields are hidden than are visible) not all of which is server-side. We have a mix of client-side (raw ExtJs) UI and server-side Ext.Net UI and therefore overriding client-side DateField was more logical and flexible.



I have already found my solution and implemented it. I have kept my client-side initComponent override on DateField intact but I have also implemented a HttpModule server-side which hooks into all Page handlers and overrides the Format rules as required.
Some duplication of logic but it works perfectly now both server and client-side and Ext.Net is happy too.

[geoffrey.mcgill]

ok, Thanks for the update. I understand your scenario better know and I can see your point. I'll give it some thought and see if we can come up with some workable solution.

Maybe setting the date .Format into a HiddenField which gets submitted along with the DateField value. This would allow overriding the "format" client-side, which would then be used by the server-side to parse the date value.

I think something like this could work.

[r_honey]

Maybe setting the date .Format into a HiddenField which gets submitted along with the DateField value. This would allow overriding the "format" client-side, which would then be used by the server-side to parse the date value.

I would rather recommend serializing the Date Value in a known format to the Hidden field (like universal sortable) and then parse it on the server rather than passing along the Format itself. Just my thoughts!!