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, 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, then
style
>> >the stop like this)
>> >af|train:disabled::stop (when the entire train is disabled, 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.
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>>
>>
>
