myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: Requirements for skinning module
Date Wed, 07 Jan 2009 21:34:42 GMT
Hi,

is there a wiki for some of the items, discussed here ?

Thanks,
Matthias

On Tue, Jan 6, 2009 at 10:44 AM, Simon Lessard
<simon.lessard.3@gmail.com> wrote:
> Hi all,
>
> Sorry about the long delay, Holiday vacations as well as business trip
> delayed my answer.
>
> Anyway, happy new year to everyone ans see me answers inline.
>
>
> Regards,
>
> ~ Simon
>
> On Mon, Dec 15, 2008 at 1:19 PM, Scott O'Bryan <darkarena@gmail.com> wrote:
>>
>> Simon Lessard wrote:
>>>
>>>
>>>    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
>>
>> This is not something that the bridge CAN support, but we should be able
>> to support the skinning system within the bridge if it was coded to handle
>> such a case.  Trinidad does it today with the simple portlet skin.
>>
>> The concept here is that the portal provides some styles as part of the
>> portlet spec.  The skin system could map some styles to delegate to those
>> portal styles.
>
> I don't see how my suggestion does not enable exactly that.
>
>>
>> As an extension to this, for renderkits supporting the skinning system,
>> the container should be able to pass in proprietary information with
>> skinning information and a hashcode.
>
> Can you elaborate on this please? I don't think I understand what kind of
> information gets passed there.
>
>>
>> I'm not sure if the skinning system would need to support this so much as
>> allow each renderkit using it to programatically get access to the
>> information that is needed.  This type of support would require an extension
>> to both the consumer (portal) and producer (portlet) to work effectively.
>>  Nonetheless, I could certainly make a bridge extension for the skinning
>> system which could standardize this somewhat if that's what people want.
>>
>> Undertstand though that until the skinning system is an approved JSR, it's
>> unlikely the bridge or Portal would have spec support for it.
>
> Yes, but even if the API does not make it in to the spec then it would most
> likely be a myfaces-skinning project and nothing would prevent us to also
> have a myfaces-portlet-bridge-extension project to add MyFaces skinning
> support to the bridge if needed.
>
>>
>> Scott
>>>
>>>
>>>
>>>
>>>    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
>>>        <andrew.rw.robinson@gmail.com
>>>        <mailto:andrew.rw.robinson@gmail.com>
>>>        <mailto:andrew.rw.robinson@gmail.com
>>>        <mailto:andrew.rw.robinson@gmail.com>>> 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
>>>           <simon.lessard.3@gmail.com
>>>        <mailto:simon.lessard.3@gmail.com>
>>>        <mailto:simon.lessard.3@gmail.com
>>>        <mailto: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
>>>           > 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
>>>           >
>>>
>>>
>>>
>>
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Mime
View raw message