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.xmlpart
> > 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.xmlfiles
> > 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.xmlpart
> > 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
> > >> >>>> >
> > >> >>>> >
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
