Ah, don't that expose the markup though? ~ Simon
On 8/29/06, Pavitra Subramaniam <[EMAIL PROTECTED]> wrote:
I am using block to indicate style class that goes in a <div> and technically I should use cell for style class that goes in a <td> - Pavitra > -----Original Message----- > From: Simon Lessard [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 29, 2006 11:18 AM > To: [email protected] > Subject: Re: TrainRenderer using the new train selectors > > Oups, comments below > > On 8/29/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote: > > > > one question below > > > > Simon Lessard wrote: > > > > > Hello Pavitra, > > > > > > I had to do about the same changes on my side. Here's my list of > > selector > > > and the rules I used: > > > > > > - af|train::stop combinable with :selected, :disabled, :completed > > > (will probably become p_AFVisited) and :unvisited. You can append > > > :readOnly at the end of the result. So > > > af|train::stop:unvisited:readOnly is valid > > > - af|train::link > > > - af|train::join combinable with :disabled, :completed, > :unvisited > > > and :outer (:outer is used to add joins outside the edge of the > > > train. I don't think many will use it, but it cost > nothing and add > > > more customization > > > possibilities) > > > > Is :outer a state? It sounds to me like it should be > > af|train::join-outer > > > yes, it could be ::join-outer, was made a state only to fit > the other join selectors, but it does make more sense to use > -outer for that one. > > > Does that make more sense now? > > > Regards, > > ~ Simon > > > - af|train::overflow-start combinable with :disabled and :readOnly > > > - af|train::overflow-end combinable with :disabled, > :unvisited and > > > :readOnly > > > > > > I have the following valid suffixes: (I could not use > ::content for > > > example since double :: is now prevented from Adam's change to > > > prevent some strange behavior it seem) > > > > I don't think two pseudo-elements make sense, does it? I > suppose you > > could have a piece of a piece. Adam prevented it because there were > > bugs in it. I can't recall what the bugs were. > > > I was seeing them more as sub-elements, like ::stop::content > (content of the > stop) > > > -content (for example, the following is valid: > af|train::stop-content > > > and > > > af|train::stop:selected-content. This selector refers to the link > > > af|cell > > fo > > > the train) > > > > What does a :selected-content 'state' mean? > > How is it different than af|train::stop-content:selected? > > > My bad there, af|train::stop-content:selected is actually > what I use. Even if a better selector would have been > af|train::stop:selected::content imho. > > > -icon-block (as above but refers to the icon cell) > > > > Could you say -icon-cell? We use 'cell' quite a bit in our skinning > > selectors. > > > Yes I could, I was using block only because it was in Pavitra > document at first. > > > > > > The icons follow the same rule. > > > > > > On 8/28/06, Pavitra Subramaniam > <[EMAIL PROTECTED]> wrote: > > > > > >> > > >> Hello Simon, > > >> > > >> I have also almost completed implementing the > TrainRenderer using > > >> the new skin selectors. It's great to know you are done > as well. If > > >> you plan to check in the train renderer code anytime > soon, can we > > >> agree on the common list of skin selectors, so that I can reuse > > >> them for my work internally at Oracle? I had to make the > following > > >> changes and wanted to give you an update. > > >> > > >> 1. I had to introduce a new state called "read-only". This is > > >> different from "disabled" state, like I explained in a > previous email. > > >> > > >> 2. I removed some redundant skin hooks - I can send you > the updated > > list > > >> of selectors I am using. I also couldn't get the > "pass-through states" > > >> :visited, :active and :unvisited to work, just as you. So I have > > >> temporarily defined selectors like Jeanne suggested (using > > >> p_AFVisited, p_AFUnvisited etc. and renamed :active to > :selected). > > >> > > >> 3. Finally I have simplified the rules for determining > the state of > > >> joins. > > >> I figured it would be much simpler if we did the following. The > > >> join to the left of a stop, is 'always in the same state as the > > >> stop' (Overflows could also follow the same rules as > stops). So for > > >> instance for a train like > > >> > > >> V ----- VR ----- UV ----- A ----- D ----- UVR ----- V > > >> vr uv v d uvr v > > >> > > >> > > >> NOTE: The only exception, is the join to the left of an > active stop > > >> is visited. Also, UVR and VR are stops that are in 2 states > > >> simulataneously - 'visited & read-only' and 'unvisited & > > >> read-only'. Read-only implies > > the > > >> stop cannot be reached (and hence not clickable) and is > dictated by > > >> the 'readOnly' property on the component commandNavigationItem. > > >> > > >> Please let me know if the above is ok. > > >> > > >> > > >> Thanks > > >> - Pavitra > > >> > > >> > > >> > -----Original Message----- > > >> > From: Simon Lessard [mailto:[EMAIL PROTECTED] > > >> > Sent: Monday, August 28, 2006 11:43 AM > > >> > To: [email protected] > > >> > Subject: Re: Train selectors > > >> > > > >> > Hmmm you mean somthing like af|train::stop.p_AFVisited? > > >> > > > >> > On 8/28/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote: > > >> > > > > >> > > I was thinking :selected for :active. :selected > could be used > > >> > > for other components, too. > > >> > > For :visited/:unvisited, I can't think of a better name. > > >> > I'm thinking > > >> > > that we should use .p_AFVisited, .P_AFUnvisited > until we have > > >> > > the pseudo-class support in. These wouldn't in a public api > > >> > format, though. > > >> > > > > >> > > - Jeanne > > >> > > > > >> > > [EMAIL PROTECTED] wrote: > > >> > > > > >> > > >Hello, > > >> > > > > > >> > > >I thought about the following name changes for the > selectors: > > >> > > > > > >> > > >:active --> :current or :selected :visited/:unvisited --> > > >> > > >:completed/:uncompleted or :seen/:unseen > > >> > > > > > >> > > > > > >> > > >Do you have any other idea/preference? > > >> > > > > > >> > > > > > >> > > >Regards, > > >> > > > > > >> > > >~ Simon > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > >"Simon Lessard" <[EMAIL PROTECTED]> > > >> > > >2006-08-25 22:49 > > >> > > >Please respond to adffaces-dev > > >> > > > > > >> > > > To: "Trinidad - Dev" > > >> > <[email protected]> > > >> > > > cc: > > >> > > > Subject: Train selectors > > >> > > > > > >> > > > > > >> > > >Yes... again... > > >> > > > > > >> > > >I made a new renderer and it work quite well, but I > had to use > > >> > > >:ora-visited and :ora-active for some selectors > because those > > >> > > >are "pass through" > > >> > > >values. > > >> > > >Anyone have better name suggestion while we implement state > > >> > > >interception on a per component basis? > > >> > > > > > >> > > > > > >> > > >Regards, > > >> > > > > > >> > > >~ Simon > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > > > > > > > > >
