Re: [Proposal] new skin config file for adding stylesheet with a skin

Mon, 06 Nov 2006 17:34:44 -0800 

By the way, I'm going to break this into two issues:
1. enable trinidad-skins.xml to be in META-INF directory and therefore it can be read out of jars. a. first find all trinidad-skins.xml files in META-INF/trinidad-skins.xml b. then look for it in WEB-INF/trinidad-skins.xml. The one that is in WEB-INF 'wins'. c. with regards to 'wins'. If I have a skin definition that is the SAME skin id, but with different parameters, then the one in WEB-INF wins. If I find two in a jar, then which one should win? The last one I load? 
       I will do something like that and log a warning.
Another thing I can do is try to merge the information, but I think this can get confusing. 

2. custom component registering skin additions in trinidad-skins.xml

- Jeanne

     


Jeanne Waldman wrote:


I was thinking about whether we should use the same file, and the pro 
of using the same file --

fewer files is really good. The cons, they are aimed at different users.

A custom component developer will want to add to existing skins, not 
create new skins.
I'll go with the fewer files is really good outweighing the different 
users argument. :)



Simon, the reason I didn't opt for skin-extension is that we have a 
SkinExtension class - it's creating

a new skin that extends an existing skin.

What I want is to use the same skin, and add new component skin 
definitions to it.

I'm not sure what a good name for it is.

Right now I look for trinidad-skins.xml in
web-inf, and I +1 to looking for in in META-INF as well. And yes,

if there can be multiple trinidad-skins.xml files laying around, I'll 
need to worry
about order. And... I'll have to make sure that all the skins are 
there before I register
the skin additions. I'll need to parse these files and buffer up the 
information, then

order them, then register things.

Thanks for the feedback.

- Jeanne


Adam Winer wrote:


I don't think it should be a separate file;  it should be a new
element in trinidad-skins.xml.  And +1 to Simon's request
for /META-INF support.

This way, you could use a /META-INF/trinidad-skins.xml
file to provide drop-in JARs that provide:
 - skin extensions
 - new skins

One big bit of fun:  you could have one /META-INF/trinidad-skins.xml
that defines a new "my-amazing-skin", and a second JAR
that defines a new "even-better-skin" that extends "my-amazing-skin",
and a third JAR that defines extensions to "even-better-skin".
And you'd have to support the jars getting doled out third, second,
first by the class loader.  So, the parsing code would need to
do some juggling to make sure this all works.

-- Adam


On 11/6/06, Simon Lessard <[EMAIL PROTECTED]> wrote:


+1


As for the name, maybe skin-extension? skin-addition is as good 
however.


About the structure, I would like to see those placed in
trinidad-skins.xmlalong with the skins. I think we should also extends
our lookup to include

.jar files' /META-INF folder if we don't already do it since it'll 
be needed

for developper wanting to deploy simple skin compliant libraries.


Regards,

~ Simon

On 11/6/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>
> Hi there,
>

> Let's say a custom component developer created some new 
components. He

> wants those components  to "fit in" with the
> 'simple' skin. He also wants them to "fit in" with the 'minimal' skin

> or any other public skin out there.  He doesn't have access to the 
files

> where we
> have this information -- our base-desktop.xss, simple-desktop.xss,
> simple-pda.xss, etc.
>
> With Trinidad's Skin API, he can call the
> skin.registerStyleSheet
> ("META-INF/styles/myCustomComponentsSimpleDesktop.css")

> method on the skin instance. Aside: I'm not sure *when/where* the 
custom
> component developer would do this, because it would need to be 
after we've

> registered our base skins and any skin extensions, so presumably it
> would need to be after the TrinidadFilter.
>

> It would be much nicer for the custom component developer if all 
he has

> to do is create an .xml file and stick it in the META-INF
> of his jar file. Then we'll parse the xml file and register the
> stylesheets with the skins for him.
>
> *Does anyone object to a new .xml file for custom component skin
> additions?*
>

> Also, we'll need to discuss the 'api' -- the name and format of 
the file.

>
> This is what I have right now . The purpose of the file is for

> custom component developers to add skinning information for their 
custom

> components to a
> specific, existing skin. Any name suggestions are welcome!
>
> *trinidad-skin-additions.xml*
> <?xml version="1.0"?>
> <skin-additions xmlns="http://myfaces.apache.org/trinidad/skin";>
>    <skin-addition>
>        <skin-id>
>           simple.desktop
>        </skin-id>
>        <style-sheet-name>
>
> META-INF/myStyles/skin/customSkin/myCustomComponentsSimpleDesktop.css
>        </style-sheet-name>
>    </skin-addition>
>    <skin-addition>
>        <skin-id>
>           minimal.desktop
>        </skin-id>
>        <style-sheet-name>
>

> 
META-INF/myStyles/skin/customSkin/myCustomComponentsMinimalDesktop.css

>        </style-sheet-name>
>    </skin-addition>
> </skin-additions>
>
> For comparison, here's the trinidad-skins.xml file:
> <skins xmlns="http://myfaces.apache.org/trinidad/skin";>
>    <skin>
>        <id>
>            purple.desktop
>        </id>
>        <family>
>            purple
>        </family>
>        <render-kit-id>
>            org.apache.myfaces.trinidad.desktop
>        </render-kit-id>
>        <style-sheet-name>
>            skins/purple/purpleSkin.css
>        </style-sheet-name>
>        <bundle-name>
>            org.apache.myfaces.trinidaddemo.resource.SkinBundle
>        </bundle-name>
>    </skin>
> </skins>
>
> Thanks a lot,
> Jeanne
>
>































					Reply via email to