Martin Marinschek wrote:
Hi Jeanne,
@reusing basic portlet-stylesheet: ok, but my assumption holds true
that this will only do the most basic styling, as there are not many
styles defined in the portlet spec? In any case, I must have done
something wrong - cause I never got 'portlet_form_label' to show up -
it was always Trinidad-styleClass-names, I'll check again.
Yes. this will be the most basic styling. You will see
trinidad-style-names also in some cases,
but in the portlet skin, the css properties for the trinidad-style-names
are purely for layout reasons.
They have no font/color information. This is supposed to be picked up by
the portlet-font or other
portlet styles.
But, that said, you can extend the simple.portlet skin and create your
own portlet skin, like 'purple.portlet' skin
that adds the colors back, for example. Then, you'd say skin-family is
purple, and the purple.portlet skin
will get chosen if you are in a portlet.
@passing down renderer-parameters: this will only work if the portlet
container supports the Trinidad-stylesheet. Realistically, this will
only be implemented in one or two portlet container implementations
anytime soon.
yes. The portlet container needs to have Trinidad and a Trinidad skin so
it can pass the skin id and the
id of the skin's stylesheet document to tell the portlet to use that.
@dynamically adding trinidad stylesheet: you have a good point with
interfering style-classes. I'd still say this is the only route I can
go as for the above reasons, I'll need to edit the portlet-container
stylesheet (or reconfigure it) so that no conflicts occur. Anyways,
with this point you're right that this is not a generally useful
solution, so I'll keep the hack I have right now and be happy with it.
What is your problem exactly and how are you working around it? I gather
that you are writing the
a new css to the page in addition to the portlet's css file?? What is in
the new css document?
regards,
Martin
On 7/30/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
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
------------------------------------------------------------------------
