Bleh, the

"Does that make more sense now?


Regards,

~ Simon"

should have been placed much later, there're comments after it. And it
should have been

"Does it make more sense now?


Regards,

~ Simon"

Thanks to my broken English...

On 8/29/06, Simon Lessard <[EMAIL PROTECTED]> wrote:

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 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
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >
>
>

Reply via email to