Hi. On Tue, Dec 9, 2008 at 5:41 PM, Simon Lessard <[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
haven't read the old post #badme However, it would be cool if that could end up in JSF 2.0 If we plan something like that (a prototype for JSF2) this should have more API character and some of the suggested features could be implemented (or not, if one of the JSF libs isn't interested, for what ever reason). > 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 +1 I agree here. I like the idea of a more general API. > 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 +1 making it flexible sounds great. > 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 I like your approach of a more general API based apporach that is flexible as well. We could more easily sell this API set to the RI folks (EG guys) and our libs could "just" jump in, easily. This would be better instead of implementing a *large* overall, one size-all fit skinning for our libs. It also would be bad if that wouldn't be compliant to a JSF skinning (not sure if that is included) Thanks for putting this mail together. -Matthias > 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
