also use URL(URL base, String cssFileName) to construct the path rather
than parsing the string yourself.
On 11/13/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote:
>> 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
> >> >>>> >
> >> >>>> >
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
>
>
