On Thu, Sep 15, 2011 at 11:52 AM, Steve McMahon <[email protected]> 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 JavaScript (cannot be JSON, it contains regexes, and I'm not sure how 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: http://code.google.com/p/datejs/source/browse/#svn%2Ftrunk%2Fsrc%2Fglobalization ** 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. Sean _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
