Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 67500 invoked from network); 31 Jul 2007 15:01:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 Jul 2007 15:01:20 -0000 Received: (qmail 38702 invoked by uid 500); 31 Jul 2007 15:00:29 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 38086 invoked by uid 500); 31 Jul 2007 15:00:26 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 37634 invoked by uid 99); 31 Jul 2007 15:00:24 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Jul 2007 08:00:24 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of simon.lessard.3@gmail.com designates 209.85.198.190 as permitted sender) Received: from [209.85.198.190] (HELO rv-out-0910.google.com) (209.85.198.190) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Jul 2007 14:32:16 +0000 Received: by rv-out-0910.google.com with SMTP id c27so547137rvf for ; Tue, 31 Jul 2007 07:31:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=fXnROthVgW2F72xvbkCGElC47QSteR5Nqs2O0eA7ML31LV/dmkYxELRPamxnDTXxiHRDRVFhyoRKP2P8JdoJCmYqUttLsbbpr11reQZhl/H4ypD1pUCCC9Dg6hVUwjpgGm1jhKkOW+NoxxrmjPdYw4Kwz1VQN38PbeUHkrX++yM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OJk/trZYaUpxEenlRpTMinqXayof3vNc19fkBJGnKjpNzZFefK/u4sei/61Aq8/Dsx9FrTEp7cnYWsncRG2bfcMroaZZv2Hd3Ad1T6ytzlE+jdPOzGBK5FzriOC2am5cJbIoaW87JgI+4jvqSt62yQUC3zxdqfxklxq33TEAb58= Received: by 10.115.108.1 with SMTP id k1mr6735238wam.1185892316012; Tue, 31 Jul 2007 07:31:56 -0700 (PDT) Received: by 10.114.152.7 with HTTP; Tue, 31 Jul 2007 07:31:55 -0700 (PDT) Message-ID: <254acf980707310731t279bf672labb7091b46c32da9@mail.gmail.com> Date: Tue, 31 Jul 2007 10:31:55 -0400 From: "Simon Lessard" To: "MyFaces Discussion" Subject: Re: [TRINIDAD] Skinning in a portlet environment In-Reply-To: <5a99335f0707310715j567ca385qbe85e7b5b853d86b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38028_4679523.1185892315897" References: <5a99335f0707260849v61bb94ftf77cc8b117abde17@mail.gmail.com> <46AE3BA0.80506@oracle.com> <5a99335f0707301256h674fcab6g7c9ebbb4ffed13f2@mail.gmail.com> <46AE8EFD.8070907@oracle.com> <5a99335f0707302340o7424fc85o875e1a5af4c33691@mail.gmail.com> <254acf980707310655y462ba3d4u741beff80469f5d4@mail.gmail.com> <5a99335f0707310715j567ca385qbe85e7b5b853d86b@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_38028_4679523.1185892315897 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 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 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 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: > > > > > > > > > > > > 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(""); > > > context.getResponseWriter().write(buf.toString()); > > > > > > super.encodeBegin(context); > > > } > > > } > > > > > > On 7/31/07, Jeanne Waldman 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 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. > > > > >> *

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

> > > > >> *

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

> > > > >> * @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: > > > > >>> > > > > >>> simple > > > > >>> > > > > >>> 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 > ------=_Part_38028_4679523.1185892315897 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 <martin.marinschek@gmail.com> 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 <simon.lessard.3@gmail.com > 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 <martin.marinschek@gmail.com> 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 < jeanne.waldman@oracle.com > 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 < jeanne.waldman@oracle.com> 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

------=_Part_38028_4679523.1185892315897--