You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Jeanne Waldman <je...@oracle.com> on 2006/11/08 20:12:51 UTC
[Question] trinidad-skins.xml in a jar
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?
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"
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 <si...@gmail.com> 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 <je...@oracle.com> 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
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>>
>
>
Re: [Question] trinidad-skins.xml in a jar
Posted by Jeanne Waldman <je...@oracle.com>.
Arjuna, All,
I like this alternative --"the other alternative is to declare the css
file name to be globally unique
like a java class name. " We need skinning doc, so I have some place to
'declare' this.
I'll make skin/customSkin.css work instead of META-INF/skin/customSkin.css.
If trinidad-skins.xml is in the META-INF directory, then I'll prepend
"META-INF"
if there is no initial '/'.
This is what I'll do for now.
Note: URLS, like
http://122.1.1.0:8080/trinidad-demo-context-root/faces/skins/purple/purpleSkins.css
does not work in <style-sheet-name> currently. That can be a separate
issue if anyone cares.
Thanks,
- Jeanne
Arjuna Wijeyekoon wrote:
> the other alternative is to declare the css file name to be globally
> unique
> like a java class name.
>
> On 11/13/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
>>
>> also use URL(URL base, String cssFileName) to construct the path rather
>> than parsing the string yourself.
>>
>> On 11/13/06, Arjuna Wijeyekoon < arjuna@gmail.com> 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 <je...@oracle.com> wrote:
>> > >
>> > > Thanks Adam.
>> > > see inline
>> > >
>> > > Adam Winer wrote:
>> > >
>> > > > On 11/8/06, Jeanne Waldman <jeanne.waldman@oracle.com > 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 < simon.lessard.3@gmail.com> 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 < jeanne.waldman@oracle.com>
>> 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
>> > > >> >>>> >
>> > > >> >>>> >
>> > > >> >>>>
>> > > >> >>>>
>> > > >> >>>
>> > > >> >>
>> > > >> >>
>> > > >> >
>> > > >> >
>> > > >>
>> > > >>
>> > > >
>> > >
>> > >
>> >
>>
>
Re: [Question] trinidad-skins.xml in a jar
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
the other alternative is to declare the css file name to be globally unique
like a java class name.
On 11/13/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> also use URL(URL base, String cssFileName) to construct the path rather
> than parsing the string yourself.
>
> On 11/13/06, Arjuna Wijeyekoon < arjuna@gmail.com> 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 <je...@oracle.com> wrote:
> > >
> > > Thanks Adam.
> > > see inline
> > >
> > > Adam Winer wrote:
> > >
> > > > On 11/8/06, Jeanne Waldman <jeanne.waldman@oracle.com > 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 < simon.lessard.3@gmail.com> 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 < jeanne.waldman@oracle.com> 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
> > > >> >>>> >
> > > >> >>>> >
> > > >> >>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>
Re: [Question] trinidad-skins.xml in a jar
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
also use URL(URL base, String cssFileName) to construct the path rather
than parsing the string yourself.
On 11/13/06, Arjuna Wijeyekoon <ar...@gmail.com> 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 <je...@oracle.com> wrote:
> >
> > Thanks Adam.
> > see inline
> >
> > Adam Winer wrote:
> >
> > > On 11/8/06, Jeanne Waldman <je...@oracle.com> 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 < simon.lessard.3@gmail.com> 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 < jeanne.waldman@oracle.com> 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
> > >> >>>> >
> > >> >>>> >
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
Re: [Question] trinidad-skins.xml in a jar
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
>> 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 <je...@oracle.com> wrote:
>
> Thanks Adam.
> see inline
>
> Adam Winer wrote:
>
> > On 11/8/06, Jeanne Waldman <je...@oracle.com> 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 <si...@gmail.com> 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 <je...@oracle.com> 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
> >> >>>> >
> >> >>>> >
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
>
>
Re: [Question] trinidad-skins.xml in a jar
Posted by Jeanne Waldman <je...@oracle.com>.
Thanks Adam.
see inline
Adam Winer wrote:
> On 11/8/06, Jeanne Waldman <je...@oracle.com> 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 <si...@gmail.com> 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 <je...@oracle.com> 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
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
Re: [Question] trinidad-skins.xml in a jar
Posted by Adam Winer <aw...@gmail.com>.
On 11/8/06, Jeanne Waldman <je...@oracle.com> 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.
> 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 <si...@gmail.com> 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 <je...@oracle.com> 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
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
>