Hi Matthias, Not to my knowledge, do you think it's worth it? From my experience wikis are great once most agree to something but are messy while it's still in discussion. I 100% agree that one should be created once the requirements are fixed and most likely others pages too when the API design is decided for reference purpose during implementation.
Regards, ~ Simon On Wed, Jan 7, 2009 at 4:34 PM, Matthias Wessendorf <[email protected]>wrote: > 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 >
