I'll give this a try when I get a chance. Thanks.
- Jeanne
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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.
[EMAIL PROTECTED] 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 : [EMAIL PROTECTED]
Date : 03/07/2006 08:33AM
cc: adffaces-dev@incubator.apache.org, [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
2006-06-29 20:17
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org,
[EMAIL PROTECTED]
cc:
Subject: Re: [Proposal] inhibiting css properties in
skin
definition file
On 6/25/06, Martin Marinschek <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
