myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeanne Waldman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (TRINIDAD-105) enable registerResourceBundle to any skin
Date Wed, 25 Jul 2007 18:17:33 GMT

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

Jeanne Waldman commented on TRINIDAD-105:
-----------------------------------------

I sent out an email with these api proposals that are different than above and everyone was
ok with them. I'm close to checking this in.

I have some new Skin API proposals I would like to run by everyone. This involves public API
changes and some private IMPL changes, and comes up while I (with code reviews by Blake Sullivan)
am trying to fix JIRA issue https://issues.apache.org/jira/browse/TRINIDAD-105 "enable registerResourceBundle
to any skin". (currently we get severe errors when running custom components against the simple
skin because the resource bundle keys do not exist in the simple skin).

Our Skin API already has the method registerStyleSheetName, so I was going to add a registerResourceBundleName
method.
But I have to admit that these apis really confuse me because we also have a getStyleSheetName
API. But that doesn't get the skin-addition stylesheets, that gets the Skin's original stylesheet.
I think we need to differentiate these two things better.

The registerStyleSheetName API is meant for skin-additions (In trinidad-skins.xml, custom
component developers use skin-additions to add a stylesheet -- and with this JIRA fixed also
a resource bundle -- to any skin, most likely the simple skin).

I think that registerStyleSheetName should be something like addSkinAdditionStyleSheetName.
And the registerResourceBundleName method I wanted to add would be addSkinAdditionResourceBundle.
This would be a big improvement.

But now that we will have two skin-addition properties on the Skin (stylesheetname and resourcebundlename),
it seems clearer to add a new SkinAddition object to a Skin instead of having these two skin
addition methods. A SkinAddition object can take styleSheetName/resourceBundleName in its
constructor.

[Summary for Skin.java]

replace registerStyleSheetName with addSkinAddition
add List getSkinAdditions

[Summary for new SkinAddition object:]

Constructor takes styleSheetName and resourceBundleName
add getStyleSheetName
add getResourceBundleName

[Changes to SkinImpl object] (meant SkinExtension)

remove setStyleSheetName (move to constructor)
remove setBundleName (move to constructor)
Add the above properties to the constructor. This will clean up the API and prevent someone
from changing the stylesheet and bundle on a Skin
Change getBundleName to getResourceBundleName  

> enable registerResourceBundle to any skin
> -----------------------------------------
>
>                 Key: TRINIDAD-105
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-105
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Skinning
>    Affects Versions: 1.2.1-core
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>
> We are developing 'custom' components on top of Trinidad, as are a lot of people. We
want them to be able to run the custom components in the simple skin. However, when running
these custom components we get severe errors, like this:
> SEVERE: Could not get resource key af_statusIndicator.CONNECTING from skin 
>  rich.desktop 
> The reason is that we do not have the needed api on the Skin class to register resource
bundles for custom component developers.  We recently added a registerStyleSheet api so that
custom component developers can register their components' skin's stylesheet to any skin they
want. We need a similar api to add resource bundles.
> Once this new API/code is in place, when a renderer calls Skin's getTranslatedValue,
the Skin code will have to look in each resource bundle that is registered until it finds
the key/value. I plan to lazily cache the information so that we don't have to look in each
resource bundle each time.
> For SkinExtensions it would be nice to know what resource bundle is that the person that
created the skin registered, so that it would have precedence over the custom components resource
bundle.
> I propose on the Skin API:
>     /**
>      * Registers an additional resource bundle on this Skin.  This is meant for skin-addition
>      * use-cases, where a custom component developer has a resource bundle for their
custom
>      * components, and they want the bundle to work for this Skin and the children Skins.
>      * The resource bundle specified by this resource bundle name
>      * will be looked into for the translated value if it is not found in the Skin's
>      * own resource bundle.
>      * It is recommended that you register your resource bundles on the most base skin,
so
>      * that all children skins will pick it up.
>      * @param resourceBundleName The name of the resource bundle
>      * @throws NullPointerException if resource bundle name is null.
>      */
>     abstract public void registerResourceBundle(
>       String resourceBundleName
>       );
> I propose we keep the following api on SkinExtension:
>   /**
>    * Returns the name of the bundle for the SkinExtension. It will return whatever was

>    * set in setBundleName
>    * @see #setBundleName(String)
>    */
>   @Override
>   public String getBundleName()
>   {
>     return _bundleName;
>   }
>   /**
>    * Returns the name of the bundle for this SkinExtension. Use registerResourceBundle
>    * to add skin-additions resource bundles. The SkinExtension bundle's resources will
take precedence
>    * over the skin-additions resource bundles.
>    * @see Skin#registerResourceBundle(String)
>    */
>   public void setBundleName(String bundleName)
>   {
>     _bundleName = bundleName;
>   }
> The api to register resource bundles for custom component developers in trinidad-skins.xml's
<skin-addition> could be 
> <bundle-name>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message