If you think the 'right' way is to have skin/customSkin.css work instead
+1 for having skin/customSkin.css to work.
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.
This is not going to work. If there was another jar file that also used the
name customSkin.css
then these two would conflict.
I think you need the entire path right upto the !META-INF .
--arjuna
On 11/13/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
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
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
