+1 regards, gerhard
2008/12/9 Matthias Wessendorf <[EMAIL PROTECTED]> > 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 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
