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: [email protected]
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 : [email protected]
>> De : [EMAIL PROTECTED]
>> Date : 03/07/2006 08:33AM
>> cc: [email protected], [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: [email protected],
>> [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
>>
>>
>
>
