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]> 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]>
> 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
> >
>
