Hello Jeanne and Simon,
There could be cases where intercepted states for a component or it's
sub-part need to be considered together rather than individually. Or in some
case it might be too early for even the renderer to provide a valid
interceptor-state list at init time. The best time may be at rendering time.
For instance, let's assume that the component sub-part "af|train::stop"
can be in the following states :visited and :selected states.
At runtime if the stop is selected, it may be rendered as a span and as an
anchor, <a >, if it was visited before (and hence clickable). Both these
elements may want to support the :hover pseudo-class.
If I wanted the :hover to pass through if it's for selected stop (for the
<span>) and intercept :hover if it's for a stop that is visited (link),
would the proposed solution work?
Thanks
- Pavitra
-----Original Message-----
From: Simon Lessard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 6:28 AM
To: [email protected]
Subject: Re: ADFFACES-49 inputText::content:required or
inputText:required::content
Hello Jeanne,
Yes I'm aware that states can go on the component's sub-part, but are you
suggesting that we extends the concept to be flexible enough to allow
thecomponent to intercept a given state on the root element but not on the
sub-part? e.g. inputText would intercept :disabled when placed on
af|inputText but not on af|inputText::content? That's some complexity
af|but
it's doable I guess.
Regards,
~Simon
On 8/22/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>
> I agree that only the renderers should know what states they want to
> intercept. I was thinking we add this information in the renderer .xml
> file and then when we build our classes, we can put this information
> somewhere -- not sure where.
>
> I'm sure you realize this, but just in case... the states do not have
> to go on the root dom element, they can go on sub-root elements, like
> af|train::stop:disabled.
>
> Simon Lessard wrote:
>
> > Hmmm, I'm leaning toward the per component basis option more and more.
> > However, I hate static lists and additional config files are not all
> that
> > great. I see a possibility though. Maybe it will work, but I did not
> > explore that area much yet so I might say something stupid.
> > Currently it seem to me that skins are linked to the renderkit. So,
> > how feasible would it be to create a SkinRenderKitFactory that
> > would, before giving away any renderer, would populate a
> > Map<component, list<state>> be interrogating all renderers in the
> > kit. That way, when StyleSheetRenderer would do its work, we would
> > be sure that the list is populated. Also, with that solution, only
> > the renderers would have to know what states they want to intercept.
> > This also fix the synchronization issue, changing the kit or the
> > renderer would automatically update the interception list. We would
> > have to create a
> new
> > BaseRenderer in the API however. I see two additional methods needed
> > for such renderers:
> >
> > public String getComponentName() // or I guess getRootStyleClass
> > would work just as well public List<String> getInterceptedStates();
> > // Returning the list of states to intercept.
> >
> >
> > Makes sense?
> >
> > ~ Simon
> >
> > On 8/21/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> More comments inline.
> >> Which way are you leaning?
> >>
> >> - Jeanne
> >>
> >> Simon Lessard wrote:
> >>
> >> > Hello Jeanne,
> >> >
> >> > Thanks for the complete answer.
> >> >
> >> > On 8/21/06, Jeanne Waldman <[EMAIL PROTECTED] > wrote:
> >> >
> >> >>
> >> >> Hi Simon,
> >> >> Thanks for the email.
> >> >>
> >> >> [EMAIL PROTECTED] wrote:
> >> >>
> >> >> >>We use both syntaxes, and they mean different things.
> >> >> >>For example:
> >> >> >>af|train::stop:disabled (when this train's stop is disabled,
> >> >> >>af|then
> >> >> style
> >> >> >>the stop like this)
> >> >> >>af|train:disabled::stop (when the entire train is disabled,
> >> style all
> >> >> >>the stops like this)
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >Agreed.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>Let's say I have this: <span class="myText">Hello!</span> and
> >> >> >>this
> >> >> css:
> >> >> >>.myText {color: black}
> >> >> >>.myText:hover {color:red}
> >> >> >>Does this work? (not in my tests)
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >It works in Firefox, not IE, as usual. W3C specifies that
> >> >> >:hover
> >> should
> >> >> >work with everything, but it's not like all browsers will
> >> >> >support everything W3C says anytime soon. Maybe we should
> >> >> >intercept all pseudo-classes, if it can be resolved on Java
> >> >> >side (like
> :disabled),
> >> we
> >> >> >resolve it there and it never pass through so we prevent all
> >> >> >bad
> >> >> support
> >> >> >from the browser. For states that cannot be resolved in Java,
> >> >> >we
> >> could
> >> >> ask
> >> >> >the Agent if it supports the specified pseudo-class for the
> >> generated
> >> >> >element (link:hover works in IE, but not on anything else). If
> >> >> >the
> >> >> agent
> >> >> >supports it, we let the class pass through to the generated CSS
> >> >> file, if
> >> >> >the agent does not, then we could add some JS code to emulate it.
> >> >> >
> >> >> >
> >> >> We generate the css file before we render the components, so
> >> >> when
> you
> >> >> say we should intercept all pseudo-classes and if it can be
> >> resolved on
> >> >> the Java side, we should resolve it. But how would we know at
> >> >> this
> >> point
> >> >> where we are going to render the pseudo-class? that af|foo:hover
> will
> >> be
> >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
> >> >> af|foo::step:hover is on the link. (we would know if we kept the
> >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
> >> literally
> >> >> that if we can resolve it on the Java side -- even if the
> >> >> browser
> can
> >> as
> >> >> well -- we go ahead and do that?
> >> >
> >> >
> >> >
> >> > I mean litterally that we make a list of pseudo-classes that we
> >> > know we can always resolve during rendering, like :disabled, and
> >> > always intercept it. In a sense it would be a way to cover
> >> > browsers' lack of support for
> those
> >> > pseudo-classes.
> >> >
> >> > In the case of :hover, do we pass that through for IE or not?
> >> > Let's
> >> say
> >> >
> >> >> we don't pass it through for IE. Then we'll need some code that
> >> >> gets :hover and says, oh, we are on IE, so don't pass this
> >> >> through but instead do some onmouseover + css magic. This seems
> >> >> like it could
> get
> >> >> messy fast.
> >> >
> >> >
> >> >
> >> > Fair point, the renderers would have to check if there's a
> >> > selector
> >> using
> >> > :hover defined in the current skin and add some JS, it's messy
> indeed.
> >> >
> >> >> The main problem I have the "per component" option is the
> >> >> potential
> >> >> >performance overhaul it represents as well as the increased
> >> component
> >> >> >development complexity (since you have to put more information
> >> >> >in
> >> the
> >> >> >metadata).
> >> >> >
> >> >> >
> >> >> I don't think of this as a performance hit, since this will
> >> >> happen
> at
> >> >> the css generation time, not with every renderer. And we cache
> >> >> the generated css file.
> >> >> It would be like the map I have now in FileSystemStyleCache.
> >> >
> >> >
> >> >
> >> > Small question here. When is the CSS generated exactly? Is it at
> >> > startup or at the first request for a given skin family? If it is
> >> > during
> startup,
> >> > the
> >> > performance hit is indeed a non issue.
> >>
> >> rendered in StyleSheetRenderer. We get it out of the cache if it is
> >> there, otherwise we generate it.
> >>
> >> >
> >> > However, we would need to keep the renderer and this map in sync.
> >> For my
> >> >
> >> >> renderer 'foo', I know that I want to handle 'hover' myself, so
> >> >> I
> put
> >> >> the hover -> p_AFHover in the map that will be consulted when we
> >> >> generate the css file. af|foo:hover does not pass through. All
> >> >> other :hover passes through. I don't think this is that
> >> >> terrible. I like
> >> this
> >> >> better than the prefix, because if, down the line, we decide
> >> >> that we
> >> can
> >> >> pass through the pseudo-class, the user's skin will not have to
> >> change,
> >> >> but our code will get simpler.
> >> >
> >> >
> >> >
> >> > Not that bad, but I kind of dislike hard coded lists as component
> >> > developers won't be able to use the skinning feature without
> >> > giving it to
> >> Trinidad
> >> > project since they will have to hack Trinidad's jar file to add
> >> > their
> >> own
> >> > states to the map. If that way is chosen, I would rather use
> >> > another configuration file or some faces-config meta-data
> >> > entries. For now skin is not a public API, but I'm prety sure it
> >> > will become one at some
> >> point in
> >> > time.
> >>
> >> We definitely need to get it out of FileSystemStyleCache. No doubt
> about
> >> it.
> >>
> >> >
> >> >> The prefix is ok, but I find it a bit counter intuitive since
> >> >> the user has
> >> >> >to know which states will be handled by browser and which are
> >> >> managed by
> >> >> >Trinidad. I would prefer to hide that kind of low level
> >> implementation
> >> >> >details to skinners.
> >> >> >
> >> >> >
> >> >> We would definitely document all the -tri- pseudo-classes per
> >> skinning
> >> >> key. For example:
> >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
> >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
> >> >> we'd document that they can use :hover.
> >> >
> >> >
> >> >
> >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
> >> > out,
> >> such
> >> > solution would force skin CSS changes if we beside to let any
> >> > given
> >> state
> >> > pass through in the future.
> >>
> >> true.
> >>
> >> >
> >> >> On a side note that could lead to a new post, what should we do
> >> >> with
> >> >> >icons? Currently the engine considers a selector an icon one if
> >> >> >it
> >> ends
> >> >> >with -icon. This lead to some strange selectors sometimes like
> >> >> >-icon-style-class simply to prevent the parser to interpret it
> >> >> >as
> an
> >> >> icon.
> >> >> >Maybe we should add something like :::icon, ::tri-icon or --icon?
> >> That
> >> >> way
> >> >> >there will be no ambiguity left.
> >> >> >
> >> >> >
> >> >> I don't have a problem with saying -icon-style when what you
> >> >> mean is that you want to style the icon, and ending the key with
> >> >> -icon
> >> when it
> >> >> means an icon.
> >> >
> >> >
> >> >
> >> > It's not that bad, true, but do we have a doc somewhere to
> >> > document
> >> this
> >> > kind of skinning rules? If not, should I add a wiki entry for it
> >> > even if the API is not public yet? Other things interesting I see
> >> > are
> >> FileSystemCache
> >> > and the mandatory "af" namespace.
> >>
> >> We don't have a skinning document for Trinidad developers (as
> >> opposed
> to
> >> application developers using Trinidad).
> >> Starting a wiki would be great. I can populate it with some
> >> information I have.
> >>
> >> Yeah, the namespace is purely to make it so that the skinner knows
> there
> >> are Trinidad keys.
> >> We need to change these to tr for one thing. The code might be a
> >> little bit hardcoded to use 'af', so that will need to change.
> >> We don't honor the actual namespace in that you can't add
> >> @namespace to the top of the css file and then be able to use
> >> whatever prefix you want. That was very low priority when I was
> >> doing the skinning, and I'm not so sure we'd want to do that
> >> anyway, becuase what would we do, substitute the namespace for the
> >> prefix? Then our css would be huge. :) Maybe some day the browsers
> >> would work with the @namespace, and when that happens we can render
> >> it out to our css.
> >>
> >> >
> >> > - Jeanne
> >> >
> >> >>
> >> >> >
> >> >> >Regards
> >> >> >
> >> >> >� Simon
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >Jeanne Waldman <[EMAIL PROTECTED] >
> >> >> >2006-08-18 18:27
> >> >> >Please respond to adffaces-dev
> >> >> >
> >> >> > To: [email protected]
> >> >> > cc:
> >> >> > Subject: Re: ADFFACES-49
> >> inputText::content:required or
> >> >> >inputText:required::content
> >> >> >
> >> >> >
> >> >> >see inline for some random thoughts. :) I'm glad you brought
> >> this up,
> >> >> >because I need to come up with a solution soon for our internal
> >> project
> >> >> >that we are working on so that our developers can write their
> >> renderers
> >> >> >correctly.
> >> >> >
> >> >> >[EMAIL PROTECTED] wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> >>Hello all,
> >> >> >>
> >> >> >>I raised that issue a while back, but now it's a bit more
> important
> >> >> since
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >>I'm trying to finalize ADFFACES-49 issue. What selector
> >> >> >>synthax do
> >> you
> >> >> >>prefer for states:
> >> >> >>1.1. <component>::<subPart>:<state> 1.2.
> >> >> >><component>:<state>::<subPart>.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >We use both syntaxes, and they mean different things.
> >> >> >
> >> >> >1.1 means this: The subPart of the component is in this state.
> >> >> >For example:
> >> >> >af|train::stop:disabled (when this train's stop is disabled,
> >> >> >af|then
> >> style
> >> >> >the stop like this)
> >> >> >af|train:disabled::stop (when the entire train is disabled,
> >> >> >af|style
> >> all
> >> >> >the stops like this)
> >> >> >
> >> >> >1.2 means this: The component is in this state, and this is the
> >> >> subpart.
> >> >> >For example:
> >> >> >af|inputText:disabled::content (when the af:inputText
> >> disabled="true",
> >> >> >then style the content piece like this)
> >> >> >
> >> >> >
> >> >> >
> >> >> >>I prefer the former and it's easier to implement. However, we
> >> already
> >> >> >>
> >> >> >>
> >> >> >have
> >> >> >
> >> >> >
> >> >> >>some :disabled that use the latter synthax.
> >> >> >>
> >> >> >>Secondly, there's also the issue raised by Jeanne, how should
> >> >> >>we
> >> >> manage
> >> >> >>which states are intercepted and which should pass through and
> >> >> >>be
> >> >> copied
> >> >> >>in the final CSS:
> >> >> >>2.1. Use a component specific list, so that :disabled could
> >> >> >>pass
> >> >> through
> >> >>
> >> >> >>for some components but get intercepted for some others? If
> >> >> >>that
> >> >> solution
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >>is selected, how/where should we configure that list, in the
> >> >> >>faces-config's metadata?
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >I like this one the best because let's say I use :disabled and
> >> >> >I intercept it and do some funky things with it. Then let's say
> >> >> >I
> >> decide
> >> >> >that the css spec deals
> >> >> >with :disabled perfectly fine, and I don't need to intercept it.
> >> >> >Also, let's say :hover and :active work great on some dom
> >> >> >elements,
> >> but
> >> >> >do they work for everything?
> >> >> >Let's say I have this: <span class="myText">Hello!</span> and
> >> >> >this
> >> css:
> >> >> >.myText {color: black}
> >> >> >.myText:hover {color:red}
> >> >> >Does this work? (not in my tests)
> >> >> >
> >> >> >But what if this represents a component. I might want them to
> >> >> >be
> >> >> able to
> >> >> >specify .myText:hover and have it work even if the built-in
> >> >> >browser support wasn't there.
> >> >> >So I would want
> >> >> >af|myComponent:hover to work.
> >> >> >I'd render this
> >> >> ><span class="af_myComponent p_AFHover">Hello!</span> when they
> >> >> >are hovering over my span.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>2.2. Use a list of pseudo-classes passing through for all
> >> components.
> >> >> >>
> >> >> >>
> >> >> >Such
> >> >> >
> >> >> >
> >> >> >>list would have to be based on W3C, but as Jeanne observed,
> >> >> >>such
> >> list
> >> >> >>would break our :disabled that we're intercepting currently
> >> >> >>and
> >> could
> >> >> >>
> >> >> >>
> >> >> >lead
> >> >> >
> >> >> >
> >> >> >>to som.e problems if more pseudo-classes are added in future
> >> >> version of
> >> >> >>CSS.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >Yes, I'd have to change the name of :disabled. But so far that
> >> >> >is
> >> the
> >> >> >only css valid pseudo-class that I use to date.
> >> >> >We have others like :hover (see above... if we don't want this
> >> >> >to
> >> pass
> >> >> >through, we'll need to change it to something else).
> >> >> >
> >> >> >
> >> >> >
> >> >> >>2.3. Use a static list of pseudo-classes to intercept used by
> >> >> >>all components? If so, where should we place it? This solution
> probably
> >> >> has
> >> >> >>the same flaws as 2.2 if a new pseudo-classes i nthe CSS
> >> specification
> >> >> >>matches a name defined in the intercept list.
> >> >> >>2.4. Use a prefix for intercepted pseudo-classes like the
> >> >> >>-ora-
> >> >> used for
> >> >>
> >> >> >>properties?
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >I like this second best. If we did this, then I'd suggest that
> >> >> >we
> >> also
> >> >> >prefix the pseudo-elements.
> >> >> >The problem is, taking my :hover example, some components might
> >> >> >be rendered such that the browser automatically works with
> >> >> >:hover on the generated css, but others
> >> don't,
> >> >> >so those that don't have to have :-tri-hover ?
> >> >> >
> >> >> >
> >> >> >
> >> >> >>My votes are:
> >> >> >>+1 for 1.1
> >> >> >>+1 for 2.2, but I would not place states resolvable during
> >> >> rendering in
> >> >> >>that list, so that disabled is still intercepted.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
