Re: Date input field enhancement by tavugyvitel.hu - worth to use it

[John Locke <..hidden..>]

Hi,


On 08/10/2013 10:58 PM, Chris Travers wrote:

On Sat, Aug 10, 2013 at 2:54 PM, John Locke <..hidden..> wrote:

Hi,

In 1.4 trunk, there is a Dojo date widget currently hooked up to the Journal Entry screen. I've been planning to move this into UI/lib/elements.html, basically create a "date" element that can then be more easily hooked up, and then there's a single place where the date format preferences can be handled for everywhere in the application... and a nifty drop-down date widget included. 

The autocomplete dropdowns were added to elements.html for the reason that they have a different HTML structure.  I am wondering how hard it would be to just getElementsByClass() and attach the scripts to these so that they could be more easily themed?

Yes, we can do this, and adding a class name is probably good for themers. It's actually more work to hook up on the JS side than just outputting a data-dojo-type attribute on the HTML tag (as I'm already doing). Dojo supports this really simple declarative syntax -- we can override the base Dojo objects to easily set other defaults, and then just leverage the parser to hook everything up.

Dojo widgets actually encapsulate a template for the HTML it generates, and there's a lot of theming capability built into those templates (and 4 or 5 different themes shipping with the core). So whether or not we explicitly add a class to these elements, there's a lot of room for theming.

What I haven't yet figured out is how to get the user's date format and locale preference injected into the template system. If somebody can more easily inject that into the environment so it can be accessed by a variable, this will be a very easy thing to solve.

maybe we should have a namespace USER (I am trying to keep reserved words all upper case) which would store this info?  Easy enough to add.

That sounds great! If this can be turned into a JS object on the page, this should work fine. Simplest approach is probably to inline this into a script loaded on the page -- the Dojo parser will run after the DOM is ready, so this object should be available by then. Or we can load it as a callback, and require that data in elements that need it -- I would expect this would be a lot of them, though, so this probably isn't good from a performance standpoint, doing an extra Ajax callback on every page...

The next question then becomes, do we localize in the JS only, or also on the server?

Here are some examples for how you can set date formats in the date widget: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html , and then Dojo could automatically convert those to a single format that is actually submitted on the form -- this to me seems like the easier approach. Then the form post handler can expect a consistent format from anywhere.

For now I don't think it is likely to be feasible to stop doing localization on the server.  We do autodetect yyyy-mm-dd dates so any localization should use that format.    However as we move all code over, I can see the benefits of moving this onto the client for data entry.  I think for display we will still need it on the server though so I am not sure it is possible to do all of this.

Oh, right. Yes, wasn't thinking of output. The dojo stuff can handle converting all input to yyyy-mm-dd format, but we'll still have to localize output on reports. To make the client side easier, we should, however, use yyyy-mm-dd format to provide the initial value of date inputs... Dojo can then convert to the appropriate locale format.
 
Cheers,
John Locke
http://www.freelock.com