[
https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790094#comment-13790094
]
Anand V Nath edited comment on TRINIDAD-2406 at 10/9/13 6:58 AM:
-----------------------------------------------------------------
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.
was (Author: [email protected]):
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)
