Hi Jeanne,
I repost what I have been doing - essentially, I have been including
the full Trinidad-CSS-file with JavaScript - as a fallback for the
case that the container doesn't include it. In this case, I'll need to
strip the portlet-css file to the bare minimum, that's clear. In the
case of the project I'm doing this for this is ok, as only Trinidad
portlets will be included on the portal-page.
regards,
Martin
---------------------
Hi Simon, Scott,
I've made skinning work now in any container - this is the code that
I've used, for other users as a reference. We should carry on the
discussion if and how to integrate this into Trinidad itself, though.
regards,
Martin
--------------------
use a binding attribute on your tr:form:
<tr:form id="helloForm" binding="#{personPage.form}">
provide a getter for this form in your backing-bean:
public CoreForm getForm() {
CoreForm coreForm = new MyCoreForm();
return coreForm;
}
write the class MyCoreForm, extending Trinidad's CoreForm - with that,
you should be good.
public static class MyCoreForm extends CoreForm {
@Override
public void encodeBegin(FacesContext context) throws IOException {
StyleContext styleContext = ((CoreRenderingContext)
RenderingContext.getCurrentInstance()).getStyleContext();
String uri =
styleContext.getStyleProvider().getStyleSheetURI(styleContext);
String contextUri =
context.getExternalContext().getRequestContextPath();
String baseURL = contextUri + XhtmlConstants.STYLES_CACHE_DIRECTORY;
String finalUri = context.getExternalContext
().encodeResourceURL(baseURL+uri);
StringBuffer buf = new StringBuffer();
buf.append("<script type=\"text/javascript\">\n" +
"\n" +
"//<![CDATA[\n" +
"\n" +
"if(document.createStyleSheet) {\n" +
"\n" +
"document.createStyleSheet('"+finalUri+"');\n" +
"\n" +
"}\n" +
"\n" +
"else {\n" +
"\n" +
"var styles = \"@import url('"+finalUri+"');\";\n" +
"\n" +
"var newSS=document.createElement('link');\n" +
"\n" +
"newSS.rel='stylesheet';\n" +
"\n" +
"newSS.href='"+finalUri+"';\n" +
"\n" +
"document.getElementsByTagName(\"head\")[0].appendChild(newSS);\n" +
"\n" +
"}\n" +
"\n" +
"//]]>\n" +
"\n" +
"</script>");
context.getResponseWriter().write(buf.toString());
super.encodeBegin(context);
}
}
On 7/31/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>
>
> 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
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------
> >>>
> >>>
> >
> >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
