Hi, is there a wiki for some of the items, discussed here ?
Thanks, Matthias On Tue, Jan 6, 2009 at 10:44 AM, Simon Lessard <[email protected]> wrote: > Hi all, > > Sorry about the long delay, Holiday vacations as well as business trip > delayed my answer. > > Anyway, happy new year to everyone ans see me answers inline. > > > Regards, > > ~ Simon > > On Mon, Dec 15, 2008 at 1:19 PM, Scott O'Bryan <[email protected]> wrote: >> >> Simon Lessard wrote: >>> >>> >>> Also, for portlets, we have a styleClassMap where we map a >>> renderer's skin selectors to a portlet skin selector, like >>> af|inputText::content - portlet-form, for example. >>> >>> >>> That one is a hard one. Although falling into jsf-portlet bridge scope, >>> the spec would have to support such thing. I tried to find a clean way to >>> define that in the past two days and the cleanest I could find would be to >>> have the getStyleClass / getStyleClasses receive a second optional argument >>> defining the selector's "family" in a document markup semantic, like is the >>> selector representing a header, a list, a definition or whatnot. The portlet >>> bridge could wrap all skins with a special wrapper that use that optional >>> parameter to return the portlet specific style class instead of or in >>> addtion to the normal ones >> >> This is not something that the bridge CAN support, but we should be able >> to support the skinning system within the bridge if it was coded to handle >> such a case. Trinidad does it today with the simple portlet skin. >> >> The concept here is that the portal provides some styles as part of the >> portlet spec. The skin system could map some styles to delegate to those >> portal styles. > > I don't see how my suggestion does not enable exactly that. > >> >> As an extension to this, for renderkits supporting the skinning system, >> the container should be able to pass in proprietary information with >> skinning information and a hashcode. > > Can you elaborate on this please? I don't think I understand what kind of > information gets passed there. > >> >> I'm not sure if the skinning system would need to support this so much as >> allow each renderkit using it to programatically get access to the >> information that is needed. This type of support would require an extension >> to both the consumer (portal) and producer (portlet) to work effectively. >> Nonetheless, I could certainly make a bridge extension for the skinning >> system which could standardize this somewhat if that's what people want. >> >> Undertstand though that until the skinning system is an approved JSR, it's >> unlikely the bridge or Portal would have spec support for it. > > Yes, but even if the API does not make it in to the spec then it would most > likely be a myfaces-skinning project and nothing would prevent us to also > have a myfaces-portlet-bridge-extension project to add MyFaces skinning > support to the bridge if needed. > >> >> Scott >>> >>> >>> >>> >>> Also, it would be great to have a feature where the skin selectors >>> are stored in an xml file that can be read from the renderer and >>> from a tool that creates documentation so we have a single source >>> of truth. This could be tied into the renderer knowing about its >>> selectors. It is possible for selectors to be different from one >>> render kit to another because, although we try to keep the names >>> abstract, it really is tied to the output (HTML). >>> >>> >>> Yes, personally I would add those directly under <renderer/> as >>> <skin-selectors><selector>*</supported-selectors>. However, such proposal >>> would be out-of-scope of JSR-314 and would be transferred to JSR 276: >>> Design-Time Metadata for JavaServer^TM Faces Components EG instead. The >>> downside I see, however is the way renderers are defined in JSF which is bad >>> imho. Adding metadata to the renderer tag mean that anyone wanting to reuse >>> the renderer within a different render kit has to also redefine the >>> renderer. There's nothing we can do about it, but I think the faces-config >>> should have looked more like the following for purpose of defining renderers >>> and render kit: >>> >>> <renderer> >>> <renderer-type/> >>> <renderer-class/> >>> <skin-properties> >>> <property/> >>> <property/> >>> <property/> >>> </skin-properties> >>> <skin-selectors> >>> <selector/> >>> <selector/> >>> <selector/> >>> </skin-selectors> >>> </renderer> >>> <render-kit> >>> <render-kit-id/> >>> <render-kit-class/> >>> <renderer-usage> >>> <component-family/> >>> <renderer-type/> >>> </renderer-usage> >>> <renderer-usage> >>> <component-family/> >>> <renderer-type/> >>> </renderer-usage> >>> </render-kit> >>> >>> Reusing an existing renderer within a new render kit would have simply >>> been to link the renderer type with the component family, not having to know >>> the class or the skin selectors used. Anyway, that part is only rambling on >>> my side. >>> >>> >>> >>> We might want 'base' skins to not be tied to a render-kit, but >>> generic so that desktop, pda, etc can extend from the base skin. >>> We sort of have this in Trinidad because the skin xss file has >>> imports, but it is messy. The entire composition/extension will >>> need a lot of thought and use cases. >>> >>> >>> I believe that's implementation specific. I assume you want to use such >>> base skins to define aliases. The way to do it with the API I proposed for >>> the extension requirement would be: >>> >>> 1. Define a base skin with selectors meant to be aliases >>> 2. Define skin1 extending base to use the aliases >>> 3. Define skin2 extending base to use the aliases >>> 4. Define skin3 extending base to use the aliases >>> 5. and so on >>> >>> The way to define addition with what I proposed is to declare a fully >>> fledged skin, the factory is reponsible for aggregation/composition so in >>> the previous case, skin1, skin2 and skin3 would have to be defined with the >>> same skin family and render kit id. >>> >>> >>> >>> People have been asking for an API to return the skinning >>> properties (css properties, like color: black) given a skinning key. >>> >>> >>> I forgot that requirement even though the API I proposed supports it... >>> I'll add that one in the new version of the list. >>> >>> >>> >>> I know these requirements aren't as general as yours Simon, so >>> maybe these are implementation as well. >>> >>> Jeanne >>> >>> >>> >>> Simon Lessard wrote, On 12/9/2008 12:36 PM PT: >>> >>> Hi Andrew, >>> >>> Strictly speaking it's an implementation detail. However, it's >>> so complex that maybe it should get some form of API support >>> as well, not sure. Maybe by adding a method to the Skin class >>> like Skin.getStyleClasses(UIComponent)? Then some >>> implementations could choose to evaluate the tree hierarchy >>> and return a different style class depending on it... The >>> implementation would be very complex and very linked to the >>> render kit it'd be attached to... this is indeed a big one to >>> chew on. >>> >>> >>> Regards, >>> >>> ~ Simon >>> >>> On Tue, Dec 9, 2008 at 2:59 PM, Andrew Robinson >>> <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> wrote: >>> >>> I am not sure of how feasible this is, but I know one >>> complication of >>> skinning components rather than styling HTML is that of >>> nesting. In >>> CSS you can have: >>> >>> DIV.myclass > SPAN.myclass >>> >>> to single out a specific parent-child relationship. This is >>> very >>> powerful as it does not affect all children but only the direct >>> children. The problem with skinning and components is that >>> this is not >>> possible to have this type of relationship: >>> >>> af|borderLayout > af|tree >>> >>> The reason this is hard is that a component may render many >>> HTML >>> elements. So af|borderLayout may be on a DIV but have other >>> HTML >>> elements under that DIV before the tree is begun. >>> >>> It would be great if this were possible. In order to do it >>> the skin >>> would have to be made aware of how the renderers render >>> HTML though. I >>> know this would be a challenge, but if possible I think it >>> would be a >>> great feature. >>> >>> This would make things possible like this: >>> >>> af|panelBorderLayout.darkBackground > af|tree >>> >>> This is better than: >>> >>> af|panelBorderLayout.darkBackground af|tree >>> >>> because it would not break this: >>> >>> af|borderLayout.lightBackground af|tree >>> >>> Full theoretical use case: >>> >>> af|panelBorderLayout.darkBackground { >>> background-color: black; >>> color: white; >>> } >>> af|panelBorderLayout.darkBackground > af|tree { >>> color: yellow; >>> } >>> af|panelBorderLayout.lightBackground { >>> background-color: white; >>> color: black; >>> } >>> af|panelBorderLayout.darkBackground > af|tree { >>> color: gray; >>> } >>> >>> This is a very simple use case, but basically there could >>> be times >>> where it is desirable to skin a direct child component and >>> not all >>> children components of a type. >>> >>> Something to chew on... >>> >>> -Andrew >>> >>> On Tue, Dec 9, 2008 at 9:41 AM, Simon Lessard >>> <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> wrote: >>> > Hi, >>> > >>> > This post is to determine the requirements of a common >>> skinning >>> module for >>> > MyFaces and potentially for JSF 2.0 if good enough. It's >>> following the post >>> > about skinning from the previous days. I'll leave this post >>> opened for 72 >>> > hours then we'll start designing accordingly, most likely >>> starting from what >>> > I proposed in the aforementioned skinning post with some >>> potential changes >>> > to fit the requirements we're going to choose. >>> > >>> > Paul Rivera proposed the following list: >>> > >>> > from trinidad: >>> > >>> > basic css style skinning >>> > global styles/aliases >>> > skin extensions >>> > skin additions for custom component developers >>> > properties skinning >>> > icon skinning >>> > text skinning / translations >>> > >>> > using bundle-name >>> > using translation-source >>> > >>> > skin variants based on: >>> > >>> > agent name >>> > agent version >>> > platform name >>> > accessibility-profile >>> > direction (:rtl) >>> > locale (@locale, :lang) -> Accdg to the skinning guide, >>> this is >>> not yet >>> > implemented in trinidad >>> > >>> > dynamically changing skins at runtime >>> > compressed styleclass names feature >>> > CHECK_FILE_MODIFICATION feature >>> > And as Jeanne mentioned, compatibility with portals. I don't >>> have much >>> > experience with portals. I will probably need to look >>> more into >>> this. >>> > >>> > added requirements: >>> > >>> > tomahawk-support: make use of AddResource and >>> ExtensionsFilter >>> > generic-support >>> > >>> > Personally I disagree quite a lot with that list. Not >>> that those >>> aren't nice >>> > features, it's just that they're implementation details >>> and not API >>> > requirements imho. I would indeed like to see a special >>> implementation >>> > support all that, I would just not link them o the base >>> API in >>> any way. >>> > Among other thing it expose way too much about the rendering >>> technology >>> > being used and nothing about the extensibility >>> requirement that >>> fits JSF >>> > architecture. My own list would look like the following. >>> It's a >>> priority >>> > list so I believe overdoing a lower requirement at the >>> expense >>> of the higher >>> > shouldn't be done: >>> > >>> > The skinning module should >>> > >>> > Be pluggable like other JSF modules (various handlers) >>> > Allow skin composition and extension for maximum reuse and >>> enforce better >>> > interoperability between various extensions >>> > Allow skin change at runtime >>> > Be localizable >>> > Leverages existing API (JSF 2.0) whenever possible rather >>> than >>> adding extra >>> > classes and methods >>> > Be independant from the rendering technology used (not >>> necessarily CSS for >>> > HTML render kit) >>> > Allow maximum compatibility with existing skin/theme modules >>> (Trinidad, >>> > IceFaces, Richfaces), not necessarily by providing direct >>> support for those >>> > feature but by allowing extension to implement those features >>> using the >>> > module's API >>> > Be fast, the module shouldn't induce an inherent performance >>> overhaul >>> > >>> > My list is way more general, but you can place some of >>> what Paul >>> mentioned >>> > in one of them so here's Paul list again but with what >>> requirement it would >>> > fall in in my list. The elements in green are covered by the >>> requirements, >>> > those in red are implementation detail that shouldn't be >>> required for all >>> > implementation and the skin's general contract. Elements >>> in blue >>> are those >>> > that should have a requirement but currently don't because I >>> don't know how >>> > to put them down or if they really should be requirement and >>> finally, >>> > elements in orange are relevant but that I didn't >>> consider in my >>> proposed >>> > API (which is a problem): >>> > >>> > from trinidad: >>> > >>> > basic css style skinning (implementation detail, not a hard >>> requirement) >>> > global styles/aliases (implementation detail, not a hard >>> requirement) >>> > skin extensions (REQ 2 through extension) >>> > skin additions for custom component developers (REQ 2 through >>> composition) >>> > properties skinning (Not currently a requirement) >>> > icon skinning (Not currently a requirement) >>> > text skinning / translations (REQ 4) >>> > >>> > using bundle-name >>> > using translation-source >>> > >>> > skin variants based on: (implementation detail, not a hard >>> requirement, >>> > could be implemented at RenderKit level, Factory level or >>> loader >>> level with >>> > what I proposed) >>> > >>> > agent name >>> > agent version >>> > platform name >>> > accessibility-profile >>> > direction (:rtl) >>> > locale (@locale, :lang) -> Accdg to the skinning guide, >>> this is >>> not yet >>> > implemented in trinidad >>> > >>> > dynamically changing skins at runtime (REQ 3) >>> > compressed styleclass names feature (implementation >>> detail, not >>> a hard >>> > requirement) >>> > CHECK_FILE_MODIFICATION feature (implementation detail, >>> not a hard >>> > requirement) >>> > And as Jeanne mentioned, compatibility with portals. I don't >>> have much >>> > experience with portals. I will probably need to look >>> more into >>> this. (REQ >>> > 1, through module override the portlet bridge could most >>> likely >>> achieve it, >>> > adding explicit support for that would go against REQs 1, >>> 5, 6 >>> and 7 I >>> > think) >>> > >>> > added requirements: >>> > >>> > tomahawk-support: make use of AddResource and >>> ExtensionsFilter >>> > (implementation detail, not a hard requirement) >>> > generic-support (implementation detail, not a hard >>> requirement) >>> > >>> > Regards, >>> > >>> > ~ Simon >>> > >>> >>> >>> >> > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
