myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anand V Nath (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Comment Edited] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
Date Wed, 09 Oct 2013 06:58:45 GMT

    [ 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: anand.v.nath@oracle.com):
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)

Mime
View raw message