myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanne Waldman <jeanne.wald...@oracle.com>
Subject Re: [TRINIDAD] Skinning in a portlet environment
Date Mon, 30 Jul 2007 19:27:28 GMT
When you are in a portlet environment, we render the 'portlet' skin.
If your skin is set to simple (which is the default), then you'll get the
simple.portlet skin instead of the simple.desktop skin that you would
normally get if you are not in a portlet.

If your skin is set to 'foo', you'll get the 'foo.portlet' skin. If the 
app hasn't
defined a 'foo.portlet' skin, you'll get the default 'simple.portlet' skin.

The SimplePortlet skin maps (see getStyleClassMap in the 
SimplePortletSkin.java code)
Trinidad selectors to Portlet selectors where applicable.
For example, we map af|inputText::label to portlet-form-label.

You can see what we are doing by using Firebug and looking at the 
generated html and the
css selectors.

We are expecting a stylesheet on the page where the portlet styles
(e.g., portlet-form-label {font-family: Tahoma; font-size: 11px} are 
defined.
Otherwise it will look like your picture - no styling.

Now if you have a usecase where you want to use a skin like 
'purple.desktop' EVEN if you
are in a portlet environment, then you can send request parameters to 
let us know.

See StyleSheetRenderer for this. Here is the comment:

      // If the requestMap has a skin-id, a skin's stylesheet's id and 
suppressStylesheet
      // is true, and the skin information matches our current skin, 
then it is safe
      // to not write out the css. This means that it will be written 
out by the external
      // source, like the portal container.

This is from CoreRenderingContext.java:

  /**
   * Returns the skin that is requested on the request map if the exact 
skin exists.
   * <p>
   * If we are in a portlet, then we might need to recalculate the skin.
   * The portal container might have its own skin that it wants us to 
use instead
   * of what we picked based on the skin-family and render-kit-id.
   * If it does, it will send the skin-id and the skin's 
styleSheetDocument id
   * in the request map.
   * </p>
   * <p>
   * If we have the skin with that id and the stylesheetdocument's id match,
   * then we return that skin; else we return null, indicating that 
there is no
   * requestMap skin.
   * </p>
   * @return null if there is no local skin that matches the requestMap 
skin, if any.
   *         skin that is requested to be used on the requestMap if we 
can find that
   *         exact skin with the same stylesheetdocument id locally.
   */
  public Skin getRequestMapSkin()


Note that we will not use the skin requested if it doesn't match exactly 
the portlet container's skin,
otherwise there will be conflicts in the css and weird things could happen.

Hope this helps,

Jeanne

Martin Marinschek wrote:
> After playing around for a while and finally finding out that it was
> as easy as setting:
>
>  <skin-family>simple</skin-family>
>
> in the trinidad-config.xml I got skinning to run in the portlet
> environment. In the end, I'm not very happy with what I see, though.
>
> I'm attaching a screenshot - basically, not much change happens by
> applying skinning - obviously due to the fact that the portlet
> containers don't offer many default style-class hooks.
> Have I been getting this wrong or does it really look like this?
>
> If I have been doing the right thing, wouldn't it be nice to have a
> way of adding the stylesheet with javascript dynamically in the body?
>
> Something like this:
>
> http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
>
> might be in order to have full skinning available, and still be
> standards compliant.
>
> I'd implement this in a component, if nobody has better ideas...
>
> regards,
>
> Martin
>
>
>
> ------------------------------------------------------------------------
>

Mime
View raw message