I don't think it should be a separate file; it should be a new
element in trinidad-skins.xml. And +1 to Simon's request
for /META-INF support.
This way, you could use a /META-INF/trinidad-skins.xml
file to provide drop-in JARs that provide:
- skin extensions
- new skins
One big bit of fun: you could have one /META-INF/trinidad-skins.xml
that defines a new "my-amazing-skin", and a second JAR
that defines a new "even-better-skin" that extends "my-amazing-skin",
and a third JAR that defines extensions to "even-better-skin".
And you'd have to support the jars getting doled out third, second,
first by the class loader. So, the parsing code would need to
do some juggling to make sure this all works.
-- Adam
On 11/6/06, Simon Lessard <[EMAIL PROTECTED]> wrote:
+1
As for the name, maybe skin-extension? skin-addition is as good however.
About the structure, I would like to see those placed in
trinidad-skins.xmlalong with the skins. I think we should also extends
our lookup to include
.jar files' /META-INF folder if we don't already do it since it'll be needed
for developper wanting to deploy simple skin compliant libraries.
Regards,
~ Simon
On 11/6/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>
> Hi there,
>
> Let's say a custom component developer created some new components. He
> wants those components to "fit in" with the
> 'simple' skin. He also wants them to "fit in" with the 'minimal' skin
> or any other public skin out there. He doesn't have access to the files
> where we
> have this information -- our base-desktop.xss, simple-desktop.xss,
> simple-pda.xss, etc.
>
> With Trinidad's Skin API, he can call the
> skin.registerStyleSheet
> ("META-INF/styles/myCustomComponentsSimpleDesktop.css")
> method on the skin instance. Aside: I'm not sure *when/where* the custom
> component developer would do this, because it would need to be after we've
> registered our base skins and any skin extensions, so presumably it
> would need to be after the TrinidadFilter.
>
> It would be much nicer for the custom component developer if all he has
> to do is create an .xml file and stick it in the META-INF
> of his jar file. Then we'll parse the xml file and register the
> stylesheets with the skins for him.
>
> *Does anyone object to a new .xml file for custom component skin
> additions?*
>
> Also, we'll need to discuss the 'api' -- the name and format of the file.
>
> This is what I have right now . The purpose of the file is for
> custom component developers to add skinning information for their custom
> components to a
> specific, existing skin. Any name suggestions are welcome!
>
> *trinidad-skin-additions.xml*
> <?xml version="1.0"?>
> <skin-additions xmlns="http://myfaces.apache.org/trinidad/skin";>
> <skin-addition>
> <skin-id>
> simple.desktop
> </skin-id>
> <style-sheet-name>
>
> META-INF/myStyles/skin/customSkin/myCustomComponentsSimpleDesktop.css
> </style-sheet-name>
> </skin-addition>
> <skin-addition>
> <skin-id>
> minimal.desktop
> </skin-id>
> <style-sheet-name>
>
> META-INF/myStyles/skin/customSkin/myCustomComponentsMinimalDesktop.css
> </style-sheet-name>
> </skin-addition>
> </skin-additions>
>
> For comparison, here's the trinidad-skins.xml file:
> <skins xmlns="http://myfaces.apache.org/trinidad/skin";>
> <skin>
> <id>
> purple.desktop
> </id>
> <family>
> purple
> </family>
> <render-kit-id>
> org.apache.myfaces.trinidad.desktop
> </render-kit-id>
> <style-sheet-name>
> skins/purple/purpleSkin.css
> </style-sheet-name>
> <bundle-name>
> org.apache.myfaces.trinidaddemo.resource.SkinBundle
> </bundle-name>
> </skin>
> </skins>
>
> Thanks a lot,
> Jeanne
>
>
