Yeah, plus shared styles are a good thing. If you don't want shared
styles there is nothing to say you can't have your own portal skin that
overrides the styles using the skinning keys.
Martin Marinschek wrote:
Hi Simon,
See attached a screenshot what the page I'm working on currently looks
like - the input fields are somewhat off. I'd say this is the
conflicts which Jeanne is talking about in action ;)
regards,
Martin
On 7/31/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
Hmmm, I really don't see how that could happen if we namespace every single
selectors and ignore portal ones. I worked a bit with portal, but not that
much so I'm kind of a newbie and you may need a hard stick to strike the
thing in my head. Do you have any example of a kind of instructions that
would create conflicts?
Regards,
~ Simon
On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Hi Simon,
yes, that makes sense - but the issue is before this, that the
Portlet-Container itself emits a style-sheet - and that instructions
in this stylesheet might conflict with the skinning instructions in
the page.
regards,
Martin
On 7/31/07, Simon Lessard <[EMAIL PROTECTED] > wrote:
Hello all,
I thought about the name clashes yesterday and maybe we could namespace
the
selectors and the stylesheet if we decide to JavaScript push the skin?
RenderingContext.getStyleClass could be in charge of adding the prefix
when
it detect a portlet environment that didn't include the special render
parameter and the application requires a more complex skin. The only
hard
part here would be what to use as a prefix, maybe something like
t<someTimeStamp> where someTimeStamp is the last 4 digits of a
System.getCurrentTimeMillis() call made by the stylesheet generation
code.
That way all portlets in the portal would be able to have a distinct
skin
without any chance of name clashes and without any special action from
the
user or the portlet container.
However, since it's going to include the CSS everytime, this strategy
greatly increase the response size thus increasing the latency.
Does that make any sense?
~ Simon
On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
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
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
