Re: [Proposal] inhibiting css properties in skin definition file

[Si...@DMR.CA]

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)
Téléphone : (418) 653-6881

Sun Certified Programmer for Java 2 Platform 1.4




"John Fallows" <jo...@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 <ma...@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 <je...@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
>
> 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