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
>
