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: Tr :Re: [Proposal] inhibiting css properties in skin definition file
Date Thu, 06 Jul 2006 18:08:23 GMT
I'll give this a try when I get a chance. Thanks.

- Jeanne

Simon_Lessard@DMR.CA wrote:

>Hello,
>
>Maybe I didn't copy the example properly. Here's a working (unworking) 
>example I just tested:
>
>af|menuList::selected
>{
>    background-color: blue;
>}
>
>This won't show any change in the page as .AFLightBackground:alias will 
>define the used background-color.
>
>
>Simon Lessard
>DMR Conseil Inc. (http://www.dmrconseil.ca)
>Téléphone : (418) 653-6881
>
>Sun Certified Programmer for Java 2 Platform 1.4
>
>
>
>
>Jeanne Waldman <jeanne.waldman@oracle.com>
>2006-07-05 18:52
>Please respond to adffaces-dev
> 
>        To:     adffaces-dev@incubator.apache.org
>        cc: 
>        Subject:        Re: Tr :Re: [Proposal] inhibiting css properties 
>in skin definition file
>
>
>Hello again,
>
>I just ran your example of
>    someAlias:alias
>    {
>     color: red;
>    }
>
>    .someSelector
>    {
>     -ora-rule-ref("selector:someAlias:alias");
>     background-color: blue;
>    }
>by putting this in the purple skin (purpleSkin.css file)
>
>And I created a new skin called purpleExtension. In 
>purpleExtensionSkin.css, I add this:
>    .someSelector
>    {
>     color: yellow;
>    }
>
>Then I created a purpleExtension skin that extends the purple skin by 
>adding this in the adf-faces-skins.xml file:
>
>    <skin>
>        <id>
>            purpleExtension.desktop
>        </id>
>        <family>
>            purpleExtension
>        </family>
>        <extends>purple.desktop</extends>
>        <render-kit-id>
>            org.apache.myfaces.adf.desktop
>        </render-kit-id>
>        <style-sheet-name>
>            skins/purple/purpleExtensionSkin.css
>        </style-sheet-name>
>    </skin> 
>
>And I added this to a .jspx demo:
>
>            <af:outputText value="HELLO THERE!" 
>styleClass="someSelector"/>
>
>And when the skin was purpleExtension it was blue background, yellow 
>color.
>And when the skin was purple it was blue background, red color.
>
>So, it works for me.
>
>- Jeanne
>
>Jeanne Waldman wrote:
>
>  
>
>>Hi there,
>>
>>Yes, I have some comments (been busy).
>>
>>First of all, it appears to be a bug that the skin's selector's 
>>property does not take precedence. We should submit an issue for this.
>>
>>As for the other issues:
>>1) Add a new keyword like -super or -inherit that would make the current
>>selector inherit the properties defined by its parent
>>-Jeanne-:
>>   The skinning css file should work like css, in that it cascades the 
>>styles from the parent skins. So I think the -super is implicit, and 
>>we shouldn't have a -super keyword.
>>
>>2) Add a -suppressProperty or -inhibit property to remove some items 
>>added
>>by calling a -super
>>- Jeanne -:
>>   This is the same as my proposal:
>>       .bar {-ora-inhibit: text-align font-size color} // 
>>inhibit/reset/null
>>3) Add also a -suppressImport or -inhibitImport that would remove an
>>-ora-rule-ref from the parent.
>>- Jeanne -:
>>   This is similar to the -ora-inhibit: all feature. We don't 
>>necessarily know what aliases our parent has included. It is much 
>>easier to inhibit all, then add back what you care about.
>>
>>4) Give priority to the more specific over the more general relatively 
>>    
>>
>to
>  
>
>>the imported aliases.
>>   - Jeanne -:
>>   I agree. I didn't think it worked this way, so it must be a bug. 
>>I'll want to do some tests of my own.
>>Eric_Marcoux-QC@DMR.CA wrote:
>>
>>    
>>
>>>Hello,
>>>
>>>We would like to work on this improvement. Is there any comments 
>>>about our suggestion ? If no, then we will proceed as indicated 
>>>below. Otherwise, please let us know.
>>>_______________________________________
>>>
>>>Eric Marcoux...
>>>Fujitsu Consulting 
>>>(http://www.fujitsu.com/ca/en/services/consulting/) 
>>><https://secure.dmr.com/go/www.dmrconseil.ca%29>
>>>Member of the quebec JUG (http://www.javaquebec.org) 
>>><https://secure.dmr.com/go/www.javaquebec.org%29>
>>>
>>>Sun Certified Programmer for Java 2 Platform 1.4
>>>Sun Certified Web Component Developer for J2EE
>>>Sun Certified Business Component Developer for J2EE
>>>
>>>-----Réacheminé par Eric Marcoux-QC/DMR/CA le 05/07/2006 03:21PM -----
>>>
>>>    Pour : adffaces-dev@incubator.apache.org
>>>    De : Simon_Lessard@DMR.CA
>>>    Date : 03/07/2006 08:33AM
>>>    cc: adffaces-dev@incubator.apache.org, mmarinschek@apache.org
>>>    Objet : Re: [Proposal] inhibiting css properties in skin
>>>    definition file
>>>
>>>    Hello,
>>>
>>>    I just finished a project using ADF Faces and I have some insight
>>>    to share
>>>    about the problems we had with the skin.
>>>
>>>    I like the inhitbit idea. However, I think the semantic of
>>>    overriding a
>>>    selector should be modified. More specifically, let examine the
>>>    current
>>>    ADF Faces behavior.
>>>
>>>    In Base skin definition let say we have
>>>
>>>    someAlias:alias
>>>    {
>>>     color: red;
>>>    }
>>>
>>>    .someSelector
>>>    {
>>>     -ora-rule-ref("selector:someAlias:alias");
>>>     background-color: blue;
>>>    }
>>>
>>>    In customSkin.css we got
>>>
>>>
>>>    .someSelector
>>>    {
>>>     color: yellow;
>>>    }
>>>
>>>    Then, the resulting CSS will use
>>>
>>>    .someSelector
>>>    {
>>>     color: red;
>>>     background-color: blue;
>>>    }
>>>
>>>    Which is a very odd behavior for two reason:
>>>    It seems that the -ora-rule-ref get resolved after everything
>>>    else, thus
>>>    overwriting style placed in the overriden selector.
>>>    With inhibit, you could suppress the background-color. However, I
>>>    don't
>>>    know if that's the best solution. Let think in OOP:
>>>    What happen when you override a method? The parent method will
>>>    never be
>>>    called and thus, you'll never automatically inherit some
>>>    treatment, unless
>>>    you do a call to super.methodName.
>>>
>>>    This would be, I believe, the best way to work with the skin as
>>>    well since
>>>    you don't have to know what properties are set by the parent.
>>>    Considering
>>>    it's planned to be able to extends any skin in the future, I
>>>    believe it
>>>    will be hard for the framework users to know all the properties
>>>    they need
>>>    to suppress from the parent at first because of automatic
>>>    inheritance of
>>>    the parent skin's properties, they will have to execute the page
>>>    and see
>>>    the result, which seems counter-intuitive and unproductive.
>>>
>>>    So, my suggestions for the skin facility would be:
>>>
>>>    1) Add a new keyword like -super or -inherit that would make the
>>>    current
>>>    selector inherit the properties defined by its parent
>>>    2) Add a -suppressProperty or -inhibit property to remove some
>>>    items added
>>>    by calling a -super
>>>    3) Add also a -suppressImport or -inhibitImport that would remove 
>>>      
>>>
>an
>  
>
>>>    -ora-rule-ref from the parent.
>>>    4) Give priority to the more specific over the more general
>>>    relatively to
>>>    the imported aliases. That is:
>>>
>>>    Given we have 2 skins, parent.css and child.css defining the 
>>>following
>>>
>>>    parent.css
>>>
>>>    aliasParent:alias
>>>    {
>>>     someProperty1 : someValue1;
>>>     someProperty2 : someValue2;
>>>     someProperty3 : someValue3;
>>>    }
>>>
>>>    aSelector
>>>    {
>>>     -ora-rule-ref("selector: aliasParent:alias");
>>>     someProperty1: someValue4;
>>>    }
>>>
>>>    child.css
>>>
>>>    aliasChild:alias
>>>    {
>>>     someProperty2 : someValue5;
>>>    }
>>>
>>>    aSelector
>>>    {
>>>     -super;
>>>     -ora-rule-ref("selector: aliasChild:alias");
>>>     someProperty3 : someValue6;
>>>    }
>>>
>>>    Then the resulting CSS for the parent skin would use for selector
>>>    aSelector:
>>>     someProperty1 : someValue4;
>>>     someProperty2 : someValue2;
>>>     someProperty3 : someValue3;
>>>
>>>    and the resulting CSS for child skin would use:
>>>     someProperty1 : someValue4;
>>>     someProperty2 : someValue5;
>>>     someProperty3 : someValue6;
>>>
>>>
>>>
>>>    Sounds good?
>>>
>>>
>>>    Simon Lessard
>>>    DMR Conseil Inc. (http://www.dmrconseil.ca
>>>    <http://www.dmrconseil.ca/>)
>>>    Téléphone : (418) 653-6881
>>>
>>>    Sun Certified Programmer for Java 2 Platform 1.4
>>>
>>>
>>>
>>>
>>>    "John Fallows" <john.r.fallows@gmail.com>
>>>    2006-06-29 20:17
>>>    Please respond to adffaces-dev
>>>
>>>           To:     adffaces-dev@incubator.apache.org,
>>>    mmarinschek@apache.org
>>>           cc:
>>>           Subject:        Re: [Proposal] inhibiting css properties in
>>>    skin
>>>    definition file
>>>
>>>
>>>    On 6/25/06, Martin Marinschek <martin.marinschek@gmail.com> wrote:
>>>    >
>>>    > +1 for the proposal in a whole
>>>    > +1 for using inhibit - I like it more than reset or null
>>>
>>>
>>>    Agreed.  +1 proposal, +1 inhibit.
>>>
>>>    suggestion for ca new prefix-name: changing ora to oam (org apache
>>>    myfaces)
>>>
>>>
>>>    Yes, this is another part of the repackaging effort.  Are we
>>>    limited to 3
>>>    chars here?
>>>
>>>    tc,
>>>    -john.
>>>
>>>    regards,
>>>    >
>>>    > Martin
>>>    >
>>>    > On 6/24/06, Jeanne Waldman <jeanne.waldman@oracle.com> wrote:
>>>    > >
>>>    > > Hi there,
>>>    > >
>>>    > >
>>>    > > I have another skinning proposal. This is a useful feature
>>>    that is in
>>>    > > xss that I think we should port to skinning css. It is the css
>>>    property
>>>    > > resetting feature.
>>>    > >
>>>    > > A bit of background first. Trinidad defines a base skin. We
>>>    call this
>>>    > > skin 'simple'. It defines basic, simple css properties for the
>>>    Trinidad
>>>    > > components. An application developer can create a skin, and 
>>>      
>>>
>this
>  
>
>>>    > > automatically extends the simple skin. Think of the simple
>>>    skin as a
>>>    > > base class in Java. You can extend one skin from another, but
>>>    they are
>>>    > > all derived from the base skin.
>>>    > >
>>>    > > When a skin extends the base skin, it is ADDING style
>>>    properties to
>>>    the
>>>    > > base skin's style properties.
>>>    > >
>>>    > > Let's say the base skin defines the font-size for the
>>>    > > af|inputText::label selector. This means that your skin will
>>>    inherit
>>>    > > this font. Your skin can redefine font-size, and put a new
>>>    font-size
>>>    > > instead. But currently, you can't say, "I don't want any 
>>>font-size
>>>    > > specified on af|inputText::label".
>>>    > >
>>>    > > I'm proposing that we come up with a skinning syntax that
>>>    allows the
>>>    > > person writing a skin to do this.
>>>    > >
>>>    > > We have this feature in the .xss syntax. In .xss, you'd do 
>>>      
>>>
>this:
>  
>
>>>    > >
>>>    > > <style name="foo" resetProperties="true"/>
>>>    > > or to reset one property, you'd do this:
>>>    > > <style name="foo">
>>>    > >      <property name="font-size"/>
>>>    > > </style>
>>>    > >
>>>    > > How could we do this in css-syntax?
>>>    > >
>>>    > > One proposal is to add a special property like our 
>>>'-ora-rule-ref'
>>>    > > property. (by the way, we'll need another discussion on 
>>>whether to
>>>    > > change the -ora- prefix, and what to change it to).
>>>    > >
>>>    > > Here is a proposal:
>>>    > >
>>>    > > .foo {-ora-inhibit: all}
>>>    > > .bar {-ora-inhibit: text-align font-size color} //
>>>    inhibit/reset/null
>>>    > > out these specific properties
>>>    > >
>>>    > > Let me know what you think.
>>>    > >
>>>    > > Thanks,
>>>    > > Jeanne
>>>    > >
>>>    > >
>>>    > >
>>>    > >
>>>    >
>>>    >
>>>    > --
>>>    >
>>>    > http://www.irian.at <http://www.irian.at/>
>>>    >
>>>    > Your JSF powerhouse -
>>>    > JSF Consulting, Development and
>>>    > Courses in English and German
>>>    >
>>>    > Professional Support for Apache MyFaces
>>>    >
>>>    >
>>>
>>>
>>>    --     http://apress.com/book/bookDisplay.html?bID=10044
>>>    Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>
>  
>


Mime
View raw message