myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Petracek" <gerhard.petra...@gmail.com>
Subject Re: Requirements for skinning module
Date Tue, 09 Dec 2008 20:13:32 GMT
+1

regards,
gerhard



2008/12/9 Matthias Wessendorf <matzew@apache.org>

> Hi.
>
> On Tue, Dec 9, 2008 at 5:41 PM, Simon Lessard <simon.lessard.3@gmail.com>
> 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

Mime
View raw message