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 Thu, 05 Oct 2006 17:19:56 GMT
Oh, I see. Yeah, if the CSS generator break it that way, it would work.

However, that kind of behavior would have to be well documented to allow
developers to create new components because they would have no way to guess
that af|train::link (for example) is valid to use in the renderer code.


Regards,

~ Simon

On 10/5/06, Jeanne Waldman <jeanne.waldman@oracle.com> wrote:
>
> I might be assuming something that is not correct, so let me ask,
> in the case of the train, what part is delegating to the navigationItem
> renderer?
> I'm assuming the af|train::link part.
> So, regardless of the skinning syntax (af|train::stop::link or
> af|train::stop af|train::link)
> you would map af|navigationItem to af|train::link.
>
> The af|train::stop/p_AFUnvisited, and p_AFReadOnly are still within the
> train
> renderer, right? So there is no need put those on the resource map.
>
> If we used af|train::stop::link format, the css parser would break it
> apart, and it would end up
> to be the same as if the skinner wrote af|train::stop af|train::link.
> Same with  af|train::stop:unvisited:read-only::link.
> We'd break it apart and make it be:
> af|tarin::stop:unvisited:read-only af|train::link
>
> It's like how the user types this:
> af|inputText:read-only::content
> and we resolve it to this:
> af|inputText:read-only af|inputText::content
>
> - Jeanne
>
> Simon Lessard wrote:
>
> > 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