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 20:44:48 GMT
Can you give me another example?
It appears that the Trinidad code no longer has this skinning key (this 
is a bug).
Also, are you using the Trinidad code in your tests?

- Jeanne

Jeanne Waldman wrote:

> 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