Hi,
On 08/10/2013 10:58 PM, Chris Travers wrote:
On Sat, Aug 10, 2013 at 2:54 PM, John Locke <m...@freelock.com
<mailto:m...@freelock.com>> 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
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel