Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 43271 invoked from network); 6 Jan 2009 17:45:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Jan 2009 17:45:16 -0000 Received: (qmail 76624 invoked by uid 500); 6 Jan 2009 17:45:16 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 76169 invoked by uid 500); 6 Jan 2009 17:45:15 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 76159 invoked by uid 99); 6 Jan 2009 17:45:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jan 2009 09:45:15 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of simon.lessard.3@gmail.com designates 209.85.132.248 as permitted sender) Received: from [209.85.132.248] (HELO an-out-0708.google.com) (209.85.132.248) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jan 2009 17:45:05 +0000 Received: by an-out-0708.google.com with SMTP id b2so2651850ana.36 for ; Tue, 06 Jan 2009 09:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=jbkkX2a7/++xYE+TsR3W4vbrrl9bw0sIfkVkWIs7e8M=; b=YA/hstaFhY7DnZd+fRVaRS4Kv4uqaMtxs+Hji202EeEufqiG59alvieG3pHRECYT1c qqFTX5ceYYFpjXHA7z5ErteSVqJ9aHhXwhNj9zT29eQFjtI5i5XRtyUxlZ/ZOZLDz+pR dHO1w+ZcY/xUuChlEwhNfGBWPb5ywAnwlKrzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=LZxpUZQ7ioBAfIthGQC2ZtiZflEK0au9gxPCWlADo1cb1GxXZjc6AQzkSCVy/Asj2Q l2VrTAKCQQ9DnLIeV+rgqYjeRrK8OXNOKkS6WbdfMKSj0CV3u8WmUx1GDkcgeiKeHd/B o8OyPMOFPFNxLZ2UUKHl7RLy3C2loGeVeVv3w= Received: by 10.100.228.13 with SMTP id a13mr11834789anh.110.1231263884183; Tue, 06 Jan 2009 09:44:44 -0800 (PST) Received: by 10.101.67.15 with HTTP; Tue, 6 Jan 2009 09:44:44 -0800 (PST) Message-ID: <254acf980901060944se7dd618xca64d17ca805a224@mail.gmail.com> Date: Tue, 6 Jan 2009 12:44:44 -0500 From: "Simon Lessard" To: "MyFaces Development" Subject: Re: Requirements for skinning module In-Reply-To: <49469FB0.7070109@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_86009_28724912.1231263884175" References: <254acf980812090841g30ef2b5em3ebdd8205d7d4b07@mail.gmail.com> <254acf980812091236w7c36cd1ck9d24b7cbd7f6cb89@mail.gmail.com> <493F1860.5020500@oracle.com> <254acf980812100805t34c928a6x20166fdb4b37f914@mail.gmail.com> <49469FB0.7070109@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_86009_28724912.1231263884175 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 as >> *. 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: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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 >> > >> > >> 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 >> > >> > >> 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 >> > >> >> >> >> > ------=_Part_86009_28724912.1231263884175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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
          >





------=_Part_86009_28724912.1231263884175--