yep, it all makes sense.
I can see where you'd want to use a ::content. That would make sense. We
don't do this yet in any of our skinning keys, so I am fine with the
-content, since we do that all over the place. :)
- Jeanne
Simon Lessard 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
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>
