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. > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> > > >> > >> > > > >
