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
------------------------------------------------------------------------
