Hi Jeanne,
See inline.
~ Simon
On Tue, Dec 9, 2008 at 8:16 PM, Jeanne Waldman <[EMAIL PROTECTED]>wrote:
> I was going to add a 'requirement' that is along these lines in that the
> renderer may choose to map a selector from one thing to something else. You
> can look at Trinidad's FileSystemStyleCache for where we do this today in
> Trinidad in a not-very-clean way.
Would be doable through SkinWrapper pattern or could be added directly in
the API, the former would means that it isn't an API requirement, while the
second does.
>
> Also, for portlets, we have a styleClassMap where we map a renderer's skin
> selectors to a portlet skin selector, like af|inputText::content -
> portlet-form, for example.
That one is a hard one. Although falling into jsf-portlet bridge scope, the
spec would have to support such thing. I tried to find a clean way to define
that in the past two days and the cleanest I could find would be to have the
getStyleClass / getStyleClasses receive a second optional argument defining
the selector's "family" in a document markup semantic, like is the selector
representing a header, a list, a definition or whatnot. The portlet bridge
could wrap all skins with a special wrapper that use that optional parameter
to return the portlet specific style class instead of or in addtion to the
normal ones
>
>
> 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 JavaServerTM 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]>>
>> 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]>> 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
>> >
>>
>>
>>
