Resource Loading Strategies - reasonable defaults

[lfryc]

Hi guys,

I would like to open discussion for "reasonable defaults" of Resource-Mapping feature, which enables you to do Compression and Packaging of resources.

This feature contains several benefits for user, as he can:

• enable/disable mapping (which leads to using static resources),
• change the project stages where he prefers to use packaged/compressed resources,
  • effectively enabling LOAD_ALL strategy from RF 3.x
    
  • but still fine-grained to be able develop and debug without pain,
    
• serve resources from another location or even server (either all or selected ones - useful for CDNs),

The configurations options are as follows:

1. org.richfaces.resourceMapping.enabled
   • set if mapping is enabled (and enables serving of packed and compressed resources)
2. org.richfaces.resourceMapping.location
   • the top-level URL where the directory with resources is located
   • default: bundled folder, may contain EL expressions or may point to another server
3. org.richfaces.resourceMapping.mappingFile
   • the top-level URL where the mapping configuration file is located
   • default: mapping file is selected according to state of compression and packaging (see bellow)
4. org.richfaces.resourceMapping.compressedStages
   • to set if compression is enabled
   • default: Production,System-Test
5. org.richfaces.resourceMapping.packedStages
   • to set if packaging is enabled
     • default: (see the default discussion for enabled)

But there will need to be considered two configurations from 4.0

• resources were generated dynamically by default
  • that means they weren't compressed nor packaged
    
• org.richfaces.staticResourceLocation option backward compatibility
  
  • this option allowed to map resources in 4.0 (very similary to org.richfaces.resourceMapping.location

We have discussed three ways with Brian:

1. be aggresive in performance optimizations
   
   • enable mapping to static resources by default
   • enable compression in Production and System-Test
     
   • remove support for org.richfaces.staticResourceLocation
2. keep backward compatibility
   
   • no mapping by default, use dynamically generated resources (as in 4.0)
     
   • enable compression in Production and System-Test (when mapping enabled)
     
   • write compatibility layer for org.richfaces.staticResourceLocation context-param (see above)
3. enable packaging by default
   • either if mapping enabled/disabled by default, packaging has it's consequences
     
     • client needs to load all resources for whole framework
     • but he do so in one request to server per resource type (CSS/JS)
   • thus highly depends on use case

Obviously, we can choose something between those options.

[jbalunas]

Nice writeup, and great details to understand what is happening!

This feature contains several benefits for user, as he can:

• enable/disable mapping (which leads to using static resources),
• change the project stages where he prefers to use packaged/compressed resources,
  • effectively enabling LOAD_ALL strategy from RF 3.x
    
  • but still fine-grained to be able develop and debug without pain,
    
• serve resources from another location or even server (either all or selected ones - useful for CDNs),

This is a great update!  We'll need a blog and docs on this for sure!  Just out of curiosity what other future features would be good here, or have you covered the main ones?

But there will need to be considered two configurations from 4.0

• resources were generated dynamically by default
  • that means they weren't compressed nor packaged
    
• org.richfaces.staticResourceLocation option backward compatibility
  
  • this option allowed to map resources in 4.0 (very similary to org.richfaces.resourceMapping.location

We need to maintain backward compatibility in a point release.  If we change the default to the new features will it break existing apps?  If yes we need to leave dynamic resources as the default.  For the staticResourceLocation, can it be mapped to the new "location" value?  If so we need to support it, if not we need to discuss the differences.

We have discussed three ways with Brian:

1. be aggresive in performance optimizations
   
   • enable mapping to static resources by default
   • enable compression in Production and System-Test
     
   • remove support for org.richfaces.staticResourceLocation
2. keep backward compatibility
   
   • no mapping by default, use dynamically generated resources (as in 4.0)
     
   • enable compression in Production and System-Test (when mapping enabled)
     
   • write compatibility layer for org.richfaces.staticResourceLocation context-param (see above)
3. enable packaging by default
   • either if mapping enabled/disabled by default, packaging has it's consequences
     
     • client needs to load all resources for whole framework
     • but he do so in one request to server per resource type (CSS/JS)
   • thus highly depends on use case

For me it comes down to backwards compatibility, and a lot of education, and information on new approaches.  If we can introduce these updates so they will not break existing apps I'm all for it, but that should be considered first IMO. 

[lfryc]

org.richfaces.staticResourceLocation has following semantics in 4.0:

• .enabled = true
• .location = {org.richfaces.staticResourceLocation}
• .mappingFile = 'META-INF/richfaces/static-resource-mapping.properties'

[lfryc]

Jay Balunas wrote:

This is a great update!  We'll need a blog and docs on this for sure!  Just out of curiosity what other future features would be good here, or have you covered the main ones?

No, these are benefits which overally leads for performance optimizations (LOAD_ALL, CDNs).

I should also mention that for better results, it is good to run maven-resources-plugin on selected application, since you cover more application-specific resources like jsf.js.

Jay Balunas wrote:

We need to maintain backward compatibility in a point release.  If we change the default to the new features will it break existing apps?

I would like to say that it won't break them, but by nature of this feature there might be introduced new issues which are caused by custom resource ordering alghoritm when using packed JS/CSS resources or by compression alghoritm.

That's why testing of all variants of resources is so important.