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/06 21:38:06 UTC
[Proposal] new skin config file for adding stylesheet with a skin
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: [Proposal] new skin config file for adding stylesheet with a skin
Posted by Simon Lessard <si...@gmail.com>.
+1 for me
On 11/13/06, Jeanne Waldman <je...@oracle.com> wrote:
>
> Hi,
> Currently I have this structure in trinidad-skins.xml:
> <skins>
> <skin>
> ...
> </skin>
> </skins>
>
> I'm planning to add skin-additions within the <skins> element.
> <skins>
> <skin>
> ...
> </skin>
> <skin-addition>
> </skin-addition>
> </skins>
>
> Comments? I want to make it backwards compatible, or I'd propose other
> structures.
>
> - Jeanne
>
> Simon Lessard 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: [Proposal] new skin config file for adding stylesheet with a
skin
Posted by Jeanne Waldman <je...@oracle.com>.
Hi,
Currently I have this structure in trinidad-skins.xml:
<skins>
<skin>
...
</skin>
</skins>
I'm planning to add skin-additions within the <skins> element.
<skins>
<skin>
...
</skin>
<skin-addition>
</skin-addition>
</skins>
Comments? I want to make it backwards compatible, or I'd propose other
structures.
- Jeanne
Simon Lessard 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
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
>
[Question] trinidad-skins.xml in a jar
Posted by Jeanne Waldman <je...@oracle.com>.
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: [Proposal] new skin config file for adding stylesheet with a
skin
Posted by Jeanne Waldman <je...@oracle.com>.
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: [Proposal] new skin config file for adding stylesheet with a
skin
Posted by Jeanne Waldman <je...@oracle.com>.
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: Re: [Proposal] new skin config file for adding stylesheet with a skin
Posted by Adam Winer <aw...@gmail.com>.
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: [Proposal] new skin config file for adding stylesheet with a skin
Posted by Simon Lessard <si...@gmail.com>.
+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
>
>