incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanne Waldman <jeanne.wald...@oracle.com>
Subject Re: [Question] trinidad-skins.xml in a jar
Date Mon, 13 Nov 2006 23:38:00 GMT
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.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
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>


Mime
View raw message