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 Wed, 05 Jul 2006 21:40:05 GMT
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