From adffaces-dev-return-358-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Thu Jul 06 20:45:15 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 40333 invoked from network); 6 Jul 2006 20:45:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jul 2006 20:45:15 -0000 Received: (qmail 43487 invoked by uid 500); 6 Jul 2006 20:45:15 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 43464 invoked by uid 500); 6 Jul 2006 20:45:15 -0000 Mailing-List: contact adffaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-dev@incubator.apache.org Delivered-To: mailing list adffaces-dev@incubator.apache.org Received: (qmail 43453 invoked by uid 99); 6 Jul 2006 20:45:14 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 13:45:14 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [141.146.126.228] (HELO agminet01.oracle.com) (141.146.126.228) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 13:45:13 -0700 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k66KiqjR002976 for ; Thu, 6 Jul 2006 15:44:52 -0500 Received: from [127.0.0.1] (jwaldman-pc.us.oracle.com [130.35.101.32]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k66Kip2l025344 for ; Thu, 6 Jul 2006 14:44:52 -0600 Message-ID: <44AD7640.90100@oracle.com> Date: Thu, 06 Jul 2006 13:44:48 -0700 From: Jeanne Waldman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: adffaces-dev@incubator.apache.org Subject: Re: Tr :Re: [Proposal] inhibiting css properties in skin definition file References: <44AD5197.6010900@oracle.com> In-Reply-To: <44AD5197.6010900@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 >> 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: >> >> >> >> purpleExtension.desktop >> >> >> purpleExtension >> >> purple.desktop >> >> org.apache.myfaces.adf.desktop >> >> >> skins/purple/purpleExtensionSkin.css >> >> >> And I added this to a .jspx demo: >> >> > 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/) >>>> >>>> Member of the quebec JUG (http://www.javaquebec.org) >>>> >>>> >>>> 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 >>>> ) >>>> T�l�phone : (418) 653-6881 >>>> >>>> Sun Certified Programmer for Java 2 Platform 1.4 >>>> >>>> >>>> >>>> >>>> "John Fallows" >>>> 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 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 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: >> >> >>>> > > >>>> > > >>>> > > >>>> > > 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 >>>> >>>> >>>> >>> >>> >> >> >> >> >> >> > >