dropdowndatepicker read value using saveFormat

[guest]

We use a dropdowndatepicker to let our users select a date. We use the format dd/MM/yyyy, when the form gets submitted it gets received like this because we added saveFormat attribute. If our backend decides the user has to change some data in the form, the form gets repopulated and displayed again. So our value of the input field is populated using the format dd/MM/yyyy , the datedropdownpicker only supports reading rfc dates from the value attribute. I checked the trunk version and there is no fix yet, so I wrote a small one myself.

If you apply this patch, the datedropdownpicker will be able to read the value using the saveFormat field the developer has supplied.

--- dojo/src/widget/DropdownDatePicker.js    (revision 552)
+++ dojo/src/widget/DropdownDatePicker.js    (working copy)
@@ -111,12 +111,16 @@
            this.iconAlt = messages.selectDate;

            //FIXME: should this be if/else/else?
+
            if(typeof(this.value)=='string'&&this.value.toLowerCase()=='today'){
                this.value = new Date();
            }
            if(this.value && isNaN(this.value)){
                var orig = this.value;
-                this.value = dojo.date.fromRfc3339(this.value);
+                if(this.saveFormat)
+                    this.value= dojo.date.parse(this.value,{formatLength:this.formatLength, datePattern:this.saveFormat, selector:'dateOnly', locale:this.lang});
+                else
+                    this.value = dojo.date.fromRfc3339(this.value);
                if(!this.value){this.value = new Date(orig); dojo.deprecated("dojo.widget.DropdownDatePicker", "date attributes must be passed in Rfc3339 format", "0.5");}
            }
            if(this.value && !isNaN(this.value)){ 

[tk]

Whats your input this patch Bill/Peller??

[Adam Peller]

It's a reasonable request for symmetry, given the number of options we put in the widget. However, I think we've learned, in general, to restrict these options as it makes both the API and the code unmanageable! Plus, this encourages the use of locale-specific notation in the markup. How would it work? Would we then do the same for startDate/endDate attributes? In the new dijit equivalent of this class, I think we're going to get rid of "saveFormat" and just assume rfc3339. I don't know exactly where dddp will end up in all of this, but I think we should be heading for the same design. So I'd be inclined to say don't bother with this right now.

[guest]

Hey sorry for still bothering, I see your standpoint but if you assume rfc3339 you impose all your users to handle all their dates in rfc3339. I wouldn't do this, in all my applications we don't use rfc33399 as it isn't our countries standard notation! If I want to use the dddp I have to rewrite all my backend code that it will expect rfc3339. So dojo is forcing me to use that. I don't agree with that idea. At the moment I use dojo and it doesn't have any impact on my backend code.

I hope you will reconsider as it has no impact on your current working of the widget.

I don't exactly follow with the new dijit? and the startdate/enddate stuff? dddp is just one day? no start or end.

[Adam Peller]

dddp has many options -- perhaps too many. There are currently other args on dddp that specify dates, such as start/end date which define a range of valid dates. In dijit, which is essentially a rewrite of the most popular widgets, we're looking at simplifying things, both to keep the code smaller and cleaner but also more usable, while sticking to principles of keeping all of our code globalized. It's hard to have it both ways -- remain locale agnostic, but allow for any arbitrary locale format. Things get complicated. I wonder if what you want can be accomplished with some sort of generic client-side shim, using dojo "advice"?

It's probably less of an imposition if the server deals with dates as objects, in which case the rfc3339 format really is not a dificult requirement and, in fact, encourages globalization throughout your app. I guess the problem is when you're dealing with plain text in a database that happens to be in an American format. (Probably not an uncommon use case)

[Adam Peller]

So the new dijit widgets will use the rfc-style format for transmission to the backend. It ought to be possible to customize the widgets by subclassing and overriding the behavior, if you wish (see the serialize method)