Thanks Adam.
see inline

Adam Winer wrote:

On 11/8/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:

I have two questions about jar'ing up the skins.

Let's say someone has jar'd up their skin and the trinidad-skins.xml file.

I have a jar with this directory structure:
META-INF
  trinidad-skins.xml
  skin
      customSkin.css
      images
          dateButtonPurple.gif

In trinidad-skins.xml, I needed to put META-INF in front of the path for
the style-sheet-name
        <style-sheet-name>
        <!-- this doesn't work
            skin/customSkin.css
          -->
            META-INF/skin/customSkin.css
        </style-sheet-name>

Is this correct?


Hrm, well if you're evaluating "skin/customSkin.css" relative to the
java.net.URL
used to load the trinidad-skins.xml file, it wouldn't be necessary.

I'm not. Basically what I do is I parse all the trinidad-skins.xml files and get a list of 'skins', which I sort and then register. styleSheetName is a String. When we load the skin that is set in trinidad-config.xml (and its ancestor skin files), we simply look for a file with that String. We end up using ClassLoaderUtils.getResource() to get the META-INF css files.

If you think the 'right' way is to have skin/customSkin.css work instead of META-INF/skin/customSkin.css, then I could do this:
when I get each trinidad-skins.xml in a jar, I get a path like this:
/C:/TestJarTwo/forthebirds.jar!META-INF/trinidad-skins.xml
I could strip out the part before the ! and the /trindad-skins.xml part and whatever is left I prepend to whatever is in
<style-sheet-names>, and use that String as the styleSheetName.

Unless there is some easy call that exists that I am missing.

- Jeanne


Also, I don't know how the browser is supposed to find the images out of
this jar, where
af|inputDate::launch-icon
{
  content:url(images/dateButtonPurple.gif);
  width:19px;
  height:24px
}
The url is:

src="/trinidad-demo-context-root/skin/images/dateButtonPurple.gif"

0on't think that's gonna work:  we'd need to have a ResourceLoader
that could reach into JARs.  We haven't built such a thing.  Would be
handy, but I don't think that's an immediate requirement.  For now,
I think of just saying that we only support image URLs that start
with a slash (and therefore relative to the context root) in this
scenario.

-- Adam


I tried putting META-INF and 'adf/' in the path, but that didn't work.

- Jeanne






Jeanne Waldman wrote:

> By the way, I'm going to break this into two issues:
> 1. enable trinidad-skins.xml to be in META-INF directory and therefore
> it can be read out of jars.
>    a. first find all trinidad-skins.xml files in
> META-INF/trinidad-skins.xml
>    b. then look for it in WEB-INF/trinidad-skins.xml. The one that is
> in WEB-INF 'wins'.
>    c. with regards to 'wins'. If I have a skin definition that is the
> SAME skin id, but with different parameters,
>        then the one in WEB-INF wins. If I find two in a jar, then
> which one should win? The last one I load?
>        I will do something like that and log a warning.
>        Another thing I can do is try to merge the information, but I
> think this can get confusing.
>
> 2. custom component registering skin additions in trinidad-skins.xml
>
> - Jeanne
>
> Jeanne Waldman wrote:
>
>> I was thinking about whether we should use the same file, and the pro
>> of using the same file --
>> fewer files is really good. The cons, they are aimed at different users.
>> A custom component developer will want to add to existing skins, not
>> create new skins.
>> I'll go with the fewer files is really good outweighing the different
>> users argument. :)
>>
>> Simon, the reason I didn't opt for skin-extension is that we have a
>> SkinExtension class - it's creating
>> a new skin that extends an existing skin.
>> What I want is to use the same skin, and add new component skin
>> definitions to it.
>> I'm not sure what a good name for it is.
>>
>> Right now I look for trinidad-skins.xml in
>> web-inf, and I +1 to looking for in in META-INF as well. And yes,
>> if there can be multiple trinidad-skins.xml files laying around, I'll
>> need to worry
>> about order. And... I'll have to make sure that all the skins are
>> there before I register
>> the skin additions. I'll need to parse these files and buffer up the
>> information, then
>> order them, then register things.
>>
>> Thanks for the feedback.
>>
>> - Jeanne
>>
>>
>> Adam Winer wrote:
>>
>>> I don't think it should be a separate file;  it should be a new
>>> element in trinidad-skins.xml.  And +1 to Simon's request
>>> for /META-INF support.
>>>
>>> This way, you could use a /META-INF/trinidad-skins.xml
>>> file to provide drop-in JARs that provide:
>>>  - skin extensions
>>>  - new skins
>>>
>>> One big bit of fun:  you could have one /META-INF/trinidad-skins.xml
>>> that defines a new "my-amazing-skin", and a second JAR
>>> that defines a new "even-better-skin" that extends "my-amazing-skin",
>>> and a third JAR that defines extensions to "even-better-skin".
>>> And you'd have to support the jars getting doled out third, second,
>>> first by the class loader.  So, the parsing code would need to
>>> do some juggling to make sure this all works.
>>>
>>> -- Adam
>>>
>>>
>>> On 11/6/06, Simon Lessard <[EMAIL PROTECTED]> wrote:
>>>
>>>> +1
>>>>
>>>> As for the name, maybe skin-extension? skin-addition is as good
>>>> however.
>>>>
>>>> About the structure, I would like to see those placed in
>>>> trinidad-skins.xmlalong with the skins. I think we should also extends
>>>> our lookup to include
>>>> .jar files' /META-INF folder if we don't already do it since it'll
>>>> be needed
>>>> for developper wanting to deploy simple skin compliant libraries.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> ~ Simon
>>>>
>>>> On 11/6/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>>>> >
>>>> > Hi there,
>>>> >
>>>> > Let's say a custom component developer created some new
>>>> components. He
>>>> > wants those components  to "fit in" with the
>>>> > 'simple' skin. He also wants them to "fit in" with the 'minimal'
>>>> skin
>>>> > or any other public skin out there.  He doesn't have access to
>>>> the files
>>>> > where we
>>>> > have this information -- our base-desktop.xss, simple-desktop.xss,
>>>> > simple-pda.xss, etc.
>>>> >
>>>> > With Trinidad's Skin API, he can call the
>>>> > skin.registerStyleSheet
>>>> > ("META-INF/styles/myCustomComponentsSimpleDesktop.css")
>>>> > method on the skin instance. Aside: I'm not sure *when/where* the
>>>> custom
>>>> > component developer would do this, because it would need to be
>>>> after we've
>>>> > registered our base skins and any skin extensions, so presumably it
>>>> > would need to be after the TrinidadFilter.
>>>> >
>>>> > It would be much nicer for the custom component developer if all
>>>> he has
>>>> > to do is create an .xml file and stick it in the META-INF
>>>> > of his jar file. Then we'll parse the xml file and register the
>>>> > stylesheets with the skins for him.
>>>> >
>>>> > *Does anyone object to a new .xml file for custom component skin
>>>> > additions?*
>>>> >
>>>> > Also, we'll need to discuss the 'api' -- the name and format of
>>>> the file.
>>>> >
>>>> > This is what I have right now . The purpose of the file is for
>>>> > custom component developers to add skinning information for their
>>>> custom
>>>> > components to a
>>>> > specific, existing skin. Any name suggestions are welcome!
>>>> >
>>>> > *trinidad-skin-additions.xml*
>>>> > <?xml version="1.0"?>
>>>> > <skin-additions xmlns="http://myfaces.apache.org/trinidad/skin";>
>>>> >    <skin-addition>
>>>> >        <skin-id>
>>>> >           simple.desktop
>>>> >        </skin-id>
>>>> >        <style-sheet-name>
>>>> >
>>>> >
>>>> META-INF/myStyles/skin/customSkin/myCustomComponentsSimpleDesktop.css
>>>> >        </style-sheet-name>
>>>> >    </skin-addition>
>>>> >    <skin-addition>
>>>> >        <skin-id>
>>>> >           minimal.desktop
>>>> >        </skin-id>
>>>> >        <style-sheet-name>
>>>> >
>>>> >
>>>> META-INF/myStyles/skin/customSkin/myCustomComponentsMinimalDesktop.css
>>>> >        </style-sheet-name>
>>>> >    </skin-addition>
>>>> > </skin-additions>
>>>> >
>>>> > For comparison, here's the trinidad-skins.xml file:
>>>> > <skins xmlns="http://myfaces.apache.org/trinidad/skin";>
>>>> >    <skin>
>>>> >        <id>
>>>> >            purple.desktop
>>>> >        </id>
>>>> >        <family>
>>>> >            purple
>>>> >        </family>
>>>> >        <render-kit-id>
>>>> >            org.apache.myfaces.trinidad.desktop
>>>> >        </render-kit-id>
>>>> >        <style-sheet-name>
>>>> >            skins/purple/purpleSkin.css
>>>> >        </style-sheet-name>
>>>> >        <bundle-name>
>>>> >            org.apache.myfaces.trinidaddemo.resource.SkinBundle
>>>> >        </bundle-name>
>>>> >    </skin>
>>>> > </skins>
>>>> >
>>>> > Thanks a lot,
>>>> > Jeanne
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>>
>
>




Reply via email to