incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard" <simon.lessar...@gmail.com>
Subject Re: svn commit: r451772 [1/8] - in /incubator/adffaces/trunk/trinidad: src/site/xdoc/ trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/desktop/ trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/co
Date Wed, 04 Oct 2006 16:56:48 GMT
Linking af|train::link to navigation item alone would not be enough with
af|train::stop::link.

This is currently what I use, another why I used a single selecor for all
links.

However take af|train::stop:unvisited:read-only::link

The only way I see would be to set all 3 selectors on the resource map
(af|train::stop::link, p_AFUnvisited and p_AFReadOnly) for both link
seletors (disabled and normal). The main disadvantage with that is that it
requires the use of one map instance per station being rendered, which will
be much less efficient than the currently singleton map.


Regards,

~ Simon

On 10/4/06, Jeanne Waldman <jeanne.waldman@oracle.com> wrote:
>
>
>
> Simon Lessard wrote:
>
> > Hello all,
> >
> > Well, at first I made it that way beause dual pseudo-element was
> > completely
> > removed because it was buggy.
>
> yep, we never had keys with multi-pseudo-elements, so it wasn't written
> to support it.
>
> > However, now that it was made that way I don't
> > dislike it. It depends how you see the link I guess, both have a
> semantic
> > sense. That being said, on a practical side, the current version is much
> > easier since the link rendering is deferred to the navigationItem
> > renderer
> > so pushing complex style class in it can be problematic. For instance,
> > how
> > would it be possible to emulate the following using resource map?
> >
> > af|train::stop:unvisited:read-only af|train::link
>
> You would map af|train::link to af|navigationItem.
>
> >
> > The new version of the selector would be
> > af|train::stop:unvisited:read-only::link, but I don'T know if the
> current
> > architecture could support that.
>
> The parser would have to change, definitely to support it.
> We can leave this issue alone for now, since there are so many more
> important issues to work out.
>
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 10/4/06, Jeanne Waldman <jeanne.waldman@oracle.com> wrote:
> >
> >>
> >> I wonder if we should support multiple pseudo-elements. That is, I
> >> wonder if :
> >>
> >> af|train::stop af|train::link
> >> af|train::overflow-start af|train::link
> >> af|train::overflow-end af|train::link
> >>
> >> would make more css-sense if the skinning definition was instead
> >>
> >> af|train::stop::link
> >> af|train::overflow-start::link
> >> af|train::overflow-end::link
> >>
> >> The top bunch seems to say "style the train's link for the train that
> is
> >> inside the other train's stop".
> >>
> >> Up until now I have said that multiple pseudo-elements is illegal. I
> >> don't
> >> see it used in the css spec at all. But it seems to me that it fits
> >> the css
> >> syntax more than the top definition. What do people think?
> >>
> >> Some background:
> >>
> >> I used to have this:
> >> af|inputText:disabled af|inputText::content
> >>
> >> and a team member pointed out that it makes more css sense to have
> this:
> >>
> >> af|inputText:disabled::content.
> >>
> >> So I changed the definition to be af|inputText:disabled::content, but
> >> the
> >> parser still parses it to af|inputText:disabled af|inputText::content
> >> and it
> >> gets generated to .af_inputText.p_AFDisabled .af_inputText_content.
> >>
> >>
> >>
> >>
> >>
> >> Pavitra Subramaniam wrote:
> >>
> >> >I didn't realize that it was going to be used this way. We don't
> >> need the
> >> stop-link like I suggested.
> >> >
> >> >Thanks
> >> >- Pavitra
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message