[jira] [Commented] (TRINIDAD-2235) Skinning: stable names for generated style sheets

["Andy Schwartz (Commented) (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225507#comment-13225507 ] 

Andy Schwartz commented on TRINIDAD-2235:
-----------------------------------------

The patch for TRINIDAD-2234:

https://issues.apache.org/jira/secure/attachment/12517604/trinidad-skin-pregen.patch

Provides the solution for this issue as well.

The javadoc for the new StableNameUtils class describes this solution:

/**
 * This class serves one purpose: it provides a replacement for NameUtils.getContextName()
 * that produces "stable" file names.  This ensures that generated style sheets will be
 * named in a consistent manner that is not dependent on the order in which requests arrives.
 * 
 * With NameUtils.getContextName(), a skin that contains the following locale-specific
 * definition:
 * 
 * @locale ja, cz, ko { ... }
 * 
 * May share a generated .css file across Japanese, Chinese and Korean end users.  The name
 * of this generated style sheet depends on which locale is specified when the style sheet is
 * first generated.  For example, if the style sheet is generated in response from a request
 * for a Korean-locale user, the file name will include the "ko" locale token.  This file
 * will then be shared by Japanese, Chinese and Korean end users.  However, if the server is
 * subsequently bounced and the first post-bounce request is from a Japanese end user, the file
 * will be re-generated with the "ja" token.
 * 
 * As a result of this behavior, file names are not predictable across runs.  The lack of
 * stable file names makes it difficult/impossible to support use cases where we want to
 * share generated style sheets across applications - eg. by pregenerating style sheets
 * and deploying them to some common server (or a CDN).
 * 
 * StableNameUtils.getContextName() solves this problem by producing names for generated
 * style sheet files that are not dependent on request ordering.
 * 
 * The file names produced by StableNameUtils.getContextName() are broken up into three
 * major sections:
 * 
 * 1. The skin identifier.
 * 2. Variant identifiers (eg. agent, locale, etc...)
 * 3. Contextual identifiers (eg. portlet vs. servlet)
 * 
 * These major sections are separated by double dashes ("--").
 * 
 * Within each major section, minor subsections appear in a predictable order, separated
 * by single dashs ("-").
 * 
 * The skin identifier section (section #1) contains the following subsections:
 * 
 *   <id>-<hash>
 *   
 * Where:
 * 
 * - id: the skin id.  Note that the skin id itself may include dash characters
 *     (eg. "simple-desktop").
 * - hash: a hash of the skin contents
 * 
 * The variant identifiers section (section #2) contains the following subsections:
 * 
 *   <platform>-<agent>-<version>-<locale>-<direction>-<accessibility>
 * 
 * Where:
 * 
 * - platform: the platform name (eg. linux, windows, iphone)
 * - agent: the agent name (eg. ie, gecko, safari)
 * - version: the agent version (eg. 7, 1.9.2, 534)
 * - locale: the locale (eg. en, en_US, ja).
 * - direction: the reading direction (ltr|rtl)
 * - accessibility: accessibility profile preferences (hc|lf|hclf for high contrast|
 *     large fonts|high contrast + large fonts).
 *     
 * These fields all support two additional values:
 * 
 * - Default: in the event that no @-rule variant is expicitly matched, only default styles
 *    (ie. styles that apply to all requests) are included in the generated style sheet.
 *   The token "d" is used to identify this case.  For example, if the skin does not
 *   define any @locale rules, the locale portion of the file name will be "d".
 * 
 * - Multiple: In some cases it is not possible to determine a unique value
 *   for a particular variant, because only @-rules that specify multiple values
 *   are matched.  The token "x" is used to identify such cases.  For example, if the
 *   skin defines a single @locale rule matching the ja, cz, and ko locales, the 
 *   locale portion of the file name for generated style sheets corresponding to these
 *   locales will be "x".
 * 
 * The contextual identifiers section (section #3) contains the following subsections:
 * 
 * - container type: identifies whether the application is hosted within a servlet or
 *     portlet (s|p).
 * - request type: identifies whether the style sheet is used for a secure or non-secure
 *     request (s|n).
 * - style class type: identifies whether the style sheet is generated with compressed or
 *     uncompressed style classes (c|u).
 * 
 * In case where skins are pregenerated and shared across applications, it may be necessary
 * to write regular expressions against the above format in order to rewrite style sheet
 * uris to point to some other host.  When doing so, the following recommendations should
 * be observed:
 * 
 * - The identifier section contains a variable number of subsection separators: skin
 *   ids may contain dashes.  As such, when writing regular expressions that target items
 *   in the subsequent major sections, it is best to anchor these regular expressions
 *   to the major section separators (double-dash).
 *   
 * - In the future it is possible that new subsections may need to be added to the
 *   variant or contextual identifier sections.  If the need for additional
 *   information arises, new subsections will be added at the end of the appropriate
 *   major section.  As such, regular expressions should be written in a way that they
 *   can tolerate new subsections later appearing at the end of each major section.
 */


Note that although the primary goal is to ensure that generated style sheet file names remain stable across runs/servers, another important goal is that the resulting names should be easily targeted by regular expressions.  This will allow specific subsets of generated style sheet uris to be rewritten to point to some other server (eg. to a CDN). 

                
> Skinning: stable names for generated style sheets
> -------------------------------------------------
>
>                 Key: TRINIDAD-2235
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2235
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Andy Schwartz
>            Assignee: Andy Schwartz
>            Priority: Minor
>
> For this recently logged Trinidad issue:
> TRINIDAD-2234 Pregeneration of skin style sheets
> We plan to add a skin pregeneration feature in order to support cases where skin style sheets are hosted on a separate host/domain (eg. CDN use cases).
> One issue with this is that the names of the generated style sheet files are not produced in a stable manner.
> For example, a skin that contains the following locale-specific definition:
>   @locale ja, cz, ko { ... }
> May share a generated .css file across Japanese, Chinese and Korean end users.  The name of this generated style sheet depends on which locale is specified when the style sheet is first generated.  If the style sheet is generated in response from a request for a Korean-locale user, the file name will include the "ko" locale token.  This file will then be shared by Japanese, Chinese and Korean end users.  However, if the server is subsequently bounced and the first post-bounce request is from a Japanese end user, the file will be re-generated with the "ja" token.
> As a result of this behavior, file names are not predictable across runs.  This lack of predictability makes it difficult to determine which variants of style sheets should be pregenerated.  In the above example, although ja/cz/ko users could/should share a single generated style sheet, we would need to pregenerate 3 style sheets just to be sure that we can handle all possible request orderings.  However:
> a) This will result in an explosion of generated style sheets.  And...
> b) This does not work well for range-based variants, such as agent versions.
> A better solution would be to enhance the way that Trinidad skinning derives names for generated style sheets.  Trinidad skinning should provide a solution where style sheet names are produced in a predictable, stable, repeatable (after a server bounce) way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira