Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <46A62F50.3030909@oracle.com>
Date: Tue, 24 Jul 2007 09:56:48 -0700
From: Jeanne Waldman <jeanne.waldman@oracle.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: MyFaces Development <dev@myfaces.apache.org>
Subject: Re: [Trinidad] [API] New Skin APIs
References: <254acf980707190549j1fb9fc21g9d2c633a1bbc024d@mail.gmail.com>
	 <6dac79b90707190839u4ce41b77o8dba4fc6dc337dd1@mail.gmail.com>
	 <469FA517.1060609@oracle.com>
 <469FAA26.4030606@oracle.com>	 <f8eab54d0707191123t4a83aa9btcc96f5c6ba55f316@mail.gmail.com>
	 <6dac79b90707191437v6eb67b1fl5bfe27f039f55367@mail.gmail.com>
	 <46A62798.1090204@oracle.com>
 <254acf980707240931j4876ca74m3f60ab5cdfbba71c@mail.gmail.com>
In-Reply-To: <254acf980707240931j4876ca74m3f60ab5cdfbba71c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Simon,
That is a very good question, because it made me remember that we do 
sort the skin additions before we register them.

A custom component
developer creates a trinidad-skins.xml file with his skin-addition 
defined that specifies his
css file and resource bundle for the custom components he has built.
Then Trinidad code reads in all the jar files on the classpath
that contain trinidad-skins.xml file.

There is code that exists that orders the skin-addition stylesheets 
alphabetically so that
our Skin's styleSheetDocument's hashcode can be the same as another 
system that has
the same jars with custom component information.

Here's the code from SkinUtils.java:

  // register the META-INF skin additions.
  // It should not matter what order we process skin-additions since 
they should not
  // depend upon one another.
  // We sort them by style-sheet-name so the StyleSheetDocumentId will 
be the same regardless
  // of order. Portals are using the styleSheetDocumentId to determine 
if the producer's skin
  // matches the consumer's skin, and the order of the skin-additions 
should not change this.
  private static void _registerMetaInfSkinAdditions(
    FacesContext    fContext,
    SkinFactory     skinFactory,
    List<SkinsNode> metaInfSkinsNodeList)
  {
    List<SkinAdditionNode> skinAdditionNodeList = new 
ArrayList<SkinAdditionNode>();

    for (SkinsNode skinsNode : metaInfSkinsNodeList)
    {
      skinAdditionNodeList.addAll(skinsNode.getSkinAdditionNodes());
    }

    Collections.sort(skinAdditionNodeList);
    _registerSkinAdditions(fContext, skinFactory, skinAdditionNodeList, 
true);
  }

Simon Lessard wrote:
> I'd say List only if ordering is important, Collection otherwise.
>
> Regards,
>
> ~ Simon
>
> On 7/24/07, *Jeanne Waldman* < jeanne.waldman@oracle.com 
> <mailto:jeanne.waldman@oracle.com>> wrote:
>
>     Thanks everyone. I'm almost done with the implementation.
>     What should getSkinAdditions return? A Collection or a List?
>     Also, SkinAddition is a public API, since it is needed by Skin.java,
>     which is public.
>
>     Here are the signatures/doc:
>
>       /**
>        * Adds a SkinAddition on this Skin. You can call this method as
>     many
>     times
>        * as you like for the Skin, and it will add the SkinAddition to the
>     list of
>        * SkinAdditions.
>        * However, it does not make sense to call this method more than
>     once
>        * with the same SkinAddition object.
>        * This is meant for the skin-addition use-cases, where a custom
>     component
>        * developer has a style sheet and/or resource bundle for their
>     custom
>        * components, and they want the style sheet and/or resource bundle
>        * to work for this Skin and the children Skins.
>        * The stylesheets specified in the SkinAdditions will be merged
>     with the
>        * Skin's own styles.
>        * The resource bundles specified in the SkinAdditions will be
>     looked
>     into
>        * if the translated key is not found in the Skin's own resource
>     bundle
>        * during the call to getTranslatedString or getTranslatedValue.
>        *
>        * @param skinAddition The SkinAddition object to add to the Skin.
>        * @throws NullPointerException if SkinAddition is null.
>        */
>       abstract public void addSkinAddition (
>         SkinAddition skinAddition
>         );
>
>       /**
>        * Gets a Collection of SkinAdditions that have been added on
>     this Skin.
>        * @return Collection a Collection of SkinAdditions.
>        */
>       abstract public Collection<SkinAddition> getSkinAdditions ();
>
>
>     -- Jeanne
>
>     Adam Winer wrote:
>     > Looks good.
>     >
>     > -- Adam
>     >
>     >
>     > On 7/19/07, Matt Cooper <matt.faces@gmail.com
>     <mailto:matt.faces@gmail.com>> wrote:
>     >> Hi Jeanne,
>     >>
>     >> I also like these changes.
>     >>
>     >> Thank you,
>     >> Matt
>     >>
>     >>
>     >> On 7/19/07, Blake Sullivan <blake.sullivan@oracle.com
>     <mailto:blake.sullivan@oracle.com> > wrote:
>     >> > Considering that I reviewed them, it isn't surprising that I
>     like
>     >> all of
>     >> > these changes.
>     >> >
>     >> > -- Blake Sullivan
>     >> >
>     >> > Jeanne Waldman wrote:
>     >> > > Hi there,
>     >> > >
>     >> > > 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 getSkinAdditions
>     >> > >
>     >> > > [Summary for new SkinAddition object:]
>     >> > >
>     >> > > Constructor takes styleSheetName and resourceBundleName
>     >> > > add getStyleSheetName
>     >> > > add getResourceBundleName
>     >> > >
>     >> > > [Changes to SkinImpl object]
>     >> > >
>     >> > > 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
>     >> > >
>     >> > >
>     >> > > Thanks for your feedback!
>     >> > >
>     >> > > - Jeanne
>     >> > >
>     >> > >
>     >> > >
>     >> > >
>     >> > >
>     >> > >
>     >> > >
>     >> >
>     >> >
>     >>
>     >>
>     >
>
>