Hello Simon, Jeanne,
I have some comments on both your email exhanges. I have consolidated all the
items below as it was getting hard to read.
>>>>
- 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
>>>>
- Do you think we need to support an "af|train::stop:visited:readOnly"
- I believe Jeanne wanted to have states that don't use camel case. So readOnly
should be read-only
>>>>
- af|train::link
>>>>
- should this be ::stop-link or ::link good enough?
>>>>
- 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)
>>>>
- :join-outer pseudo element is good enough. Is this used outside the parent
train icons or between the parent train icons and the overflow (or stop)?
- do we still have the join-overflow? This comes between the overflow and
regular stops. It may be useful in cases where only these joins need not be
displayed.
>>>>
- af|train::overflow-start combinable with :disabled and :readOnly
- af|train::overflow-end combinable with :disabled, :unvisited and :readOnly
>>>>
- Do you think we should support :unvisited state on overflow-start? This may
be useful in cases where the train is not sequential? I have a scenario where
all stops in the train are enabled and user can jump around any stop without a
prescribed order.
>>>>
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) -content (for example, the following is valid:
af|train::stop-content and
af|train::stop:selected-content. This selector refers to the link cell (of the
train)
>>>>
- I agree with Jeanne. Let's call it stop-content:selected. I don't think we
need stop-content:visited or stop-content:unvisited. It's an overkill.
>>>>
-icon-block (as above but refers to the icon cell)
>>>>
- Perhaps we should have a convention of using -block suffix for style classes
that go on <div> and -cell for styles that go on td. Is that acceptable?
>>>>
I use the same join rule as you, that is previous stop determine the join
state, except for the join after the selected stop. The only exception are
disabled stops, those have disabled joins on both sides.
>>>>
- the join after the selected stop should ideally have the state of the
following stop. Isn't it? Do you think it will be easier to just show the left
join of a disabled stop as "disabled". So if an unvisited stop follows the
disabled stop, the join between them will show up as unvisited. At least this
is how I have implemented it. I use the same rule for displaying joins before
overflows.
>>>>
I also go rid of the separator, it's redundant as you can add padding to
-content selector. I also added two aliases .AFTrainContent:alias and
.AFTrainIconBlock. So you can add spacing between stop with something like the
following:
.AFTrainContent:alias
{
padding-left: 8px;
padding-right: 8px;
}
>>>>
When you say separator, do you mean the spacer that separates stops? Where is
the alias above included? Can you send me a HTML fragment?
Thanks
- Pavitra
> -----Original Message-----
> From: Simon Lessard [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 29, 2006 11:43 AM
> To: [email protected]
> Subject: Re: TrainRenderer using the new train selectors
>
> Ok,
>
> Then if those selectors are ok for you as well Pavitra I'll
> make the changes to -outer and and -icon-cell tonight and
> upload the patch as well as a test skin I used.
>
>
> Regards,
>
> ~ Simon
>
> On 8/29/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
> >
> > 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
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > >
> > >> >> > >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
>
