In order to adopt the JSF 2.0 standard for Trinidad, we have to introduce the ProjectStage API and should use it, where it actually makes sense.

list of all Trinidad configuration parameters

System Properties ( => System.getProperty(....))

documentation is here:

does make sense to port to ProjectStage API

The trinidad-config.xml file

See here for infos about it:

I think that ONLY this element could make sense:

Settings in the WEB.XML (aka Context Parameters)

Some info is here as well:

The web.xml has different types of settings (some fit to ProjectStage, some not)

Here is a grouped list, where I think they do not make sense with project_stage at all:

These parameters do make sense:

This parameter may make sense (caution: it is an internal and temporary param):

List of valid candidates for ProjectStage API and their values

Overriding single settings

Perhaps we want to be able to still override settings, regardless for the current STAGE. Means: If the application runs in ProjectStage.Production, we do CSS ompression. BUT... if the web.xml says org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION => TRUE, we should honor that... This would give users a more fine grained control over these configuration settings. Once a user actually overrides stuff, we log a WARNING

Current implementation in Trinidad 2.x

Not all options of the above valid candidate list have been implemented. For instance the ENABLE_PPR_OPTIMIZATION should not be changed by application developers. Similar with the CHECK_STATE_SERIALIZATION parameter: it should be only effected via System Property

However, in PRODUCTION we generate an additional warning if they have been set (via XML) to some undesired value.

Currently we also generate warning if the org.apache.myfaces.trinidad.CLIENT_ID_CACHING System Property has been disabled in PRODUCTION

Trinidad_goes_ProjectStage (last edited 2010-09-29 17:39:52 by MatthiasWessendorf)