sdupton at gmail.com
Thu Sep 15 20:53:47 UTC 2011
On Thu, Sep 15, 2011 at 11:52 AM, Steve McMahon <steve at dcn.org> wrote:
> Why not just include locale-specific information in the original HTML view?
> Hide it it if it isn't meant for immediate display, then grab it with js
> when you need it.
The state/data I am trying to pass to the client is natively
the per-locale JS payload gets included in the HTML other than as a
script tag with src attribute).
Examples of the most minimal** thing I could load:
** minimal vs. currently loading all of Date.js compiled
per-locale. The scripts in datejs svn are *only* localization data.
Alternatives I have considered so far:
1. Base JS uses XMLHttpRequest to fetch, eval/load local-specific JS.
Load en-US locale by default in base, then replace asyncronously;
after load of locale-specific configuration, re-hookup widget
placeholder/tooltips and calendar formats for JQuery Tools dateinput.
I've done JS fetching yet more JS in past projects and have mixed
feelings about this. I get the feeling that I cannot make Date.js
work without a default locale, so non-en-US locales will incur the
load of two locales (duplicative of about 6k uncompressed JS).
2. There is always the option of including (injecting?) a
tal-generated script element in the header of all templates (or all
relating to forms), bypassing the JS registry entirely -- I just don't
know how to correctly do this without overriding the main template.
More information about the Product-Developers