myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: [TRINIDAD] Skinning in a portlet environment
Date Tue, 31 Jul 2007 15:14:52 GMT
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 <simon.lessard.3@gmail.com> 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 <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
> >
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Mime
View raw message