[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI

["Anand V Nath (JIRA)" <de...@myfaces.apache.org>]

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

Anand V Nath commented on TRINIDAD-2406:
----------------------------------------

Today we load the skins as part of the configurator initialization (GlobalConfiguratorImpl). The skins are loaded upfront and populate into SkinFactory. We cache the skins in SkinFactory and reload it, based on the skin state (DIRTY, READY, RELOADING) set on the SkinFactory.

With SkinProvider we support skin repositories external to the skin framework. For each skin repository externally maintained, the user can register SkinProvider SPI. The registered SPI has the responsibility to manage the skins. SkinProvider API is designed based on the API SkinFactory currently exposes.

Every time the SkinProvider is queried for a Skin, it can either reload the skin or return the cached skin. This is completely under the control of the SkinProvider implementation. SkinProvider also exposes a quick way to gather information of the Skins that it publishes, by means of SkinMetadata. SkinProvider should be able to provide this information without loading the Skins, thus supporting the idea of lazy loading.
SkinProvider lazy loading concept.

Currently all the queries to get a Skin lands up in SkinFactory. SkinFactory then returns the cached skin to the caller, or returns the reloaded skin (when required / dirtied).

With SkinProvider, SkinProviderRegisry will be single point of entry to query any Skins defined in the system, either internal or external to skinning framework. SkinProviderRegistry keeps track of all the registered SkinProvider SPIs and supplies the skin requested by invoking each SkinProvider to find a matching Skin.

For example: if SkinProviderRegistry receives request to load "SkinA" which is part of SkinProviderA and has the following heirarchy:

SkinA -> skyros -> simple-desktop

SkinProviderRegistry will go over the registered SPIs first and thus query SkinProviderA for "SkinA". SkinProviderA will query SkinProviderRegistry for "skyros" skin since "SkinA" uses "skyros" as its base and this fact is known to "SkinProviderA" which manages "SkinA". Thus a request for "skyros" will land on SkinProviderRegistry. SkinProviderRegistry again goes on its way of invoking the registered SPIs and Trinidad internal SPIs. Since "skyros" is internal skin the request lands up with the internal SkinProvider. Internal SkinProvider finds that "skyros" needs "simple-desktop" to be available, so the internal SkinProvider queries SkinProviderRegistry for "simple-desktop". Since "simple-desktop" is the top most skin and does not have any parent skin, that gets loaded by internal SkinProvider. Once "simple-desktop" skin is loaded, "skyros" is loaded using that and so an so forth.

If there is a request following this for another skin, say "SkinB" which has the following hierarchy:

SkinB -> skyros -> simple-desktop

then we do the same thing, but the difference is that internal base skins will be cached after it is loaded first time (while loading "SkinA", in this case) by the internal SkinProvider implementation, and reloaded only if dirtied.

With these changes SkinFactory becomes obsolete and will be deprecated. SkinProviderRegistry will ask SkinFactory if non of the SkinProvider implementations were able to return the required skin, and thus provide backward compatibility with those third party who is registering their skins using SkinFactory.

Also SkinFactory will delegate the getSkin requests to SkinProviderRegistry as existing usecases are expecting trinidad skins and other base skins to be returned from SkinFactory.

We assume that there are no practical chances of collision in this approach and that no two SkinProvider will respond for the same Skin. This situation will be solved separately if and when it arises.

> externalize skin repositories by using SkinProvider SPI
> -------------------------------------------------------
>
>                 Key: TRINIDAD-2406
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>    Affects Versions: 2.1.0-core
>            Reporter: Anand V Nath
>
> Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework.
> Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match.
> Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml).
> Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available.
> Make SkinExtension part of public API so that users can use this class to create the Skin objects which they expose through their SkinProvider SPIs



--
This message was sent by Atlassian JIRA
(v6.1#6144)