You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2007/07/26 17:49:30 UTC
[TRINIDAD] Skinning in a portlet environment
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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
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 <si...@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 <ma...@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 <ma...@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
>>>
>>>
>>
>
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
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 <si...@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 <ma...@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 <ma...@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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
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 <ma...@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 <si...@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 <ma...@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 <je...@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
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
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 <si...@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 <ma...@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 <je...@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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
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 <ma...@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 <je...@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 <je...@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
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
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 <je...@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 <je...@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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Jeanne Waldman <je...@oracle.com>.
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 <je...@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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
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.
@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.
@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.
regards,
Martin
On 7/30/07, Jeanne Waldman <je...@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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Jeanne Waldman <je...@oracle.com>.
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
>
>
>
> ------------------------------------------------------------------------
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
Ok, so what you are saying is you want the portlet container to render
the Trinidad CSS-file for skinning?
But how to get the portlet container to do so? You'd need to change
the portlet container, right? I don't know of any standard way to tell
a portlet container to include a CSS file in the header?
It might as well be that I'm on the wrong track here - sorry if I beat
a dead horse.
regards,
Martin
On 7/26/07, Simon Lessard <si...@gmail.com> wrote:
> Not really, I think we detect a specific parameter pushed by the container.
> So only container supporting skinning would push it, effectively
> synchronizing all portlet LaF. For other container I think we simply use the
> normal code path... That or I had some serious hallucinations in the past
> months and imagined all this...
>
>
> On 7/26/07, Martin Marinschek <ma...@gmail.com> wrote:
> > Hi Simon,
> >
> > well, but this would then be portlet container dependent, right? You'd
> > effectively need to implement trinidad skinning in every portlet
> > container.
> >
> > regards,
> >
> > Martin
> >
> > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > Personally, I don't see why the portal should not be able to provide all
> > > selectors.
> > >
> > > Aren't we just not compressing the selector names when we detect a
> portal
> > > environment or did I miss something? I think that strategy cannot
> provides
> > > the icons though.
> > >
> > >
> > > On 7/26/07, Martin Marinschek <martin.marinschek@gmail.com > wrote:
> > > > Does the portlet container really provide every styleclass that is
> > > > necessary for Trinidad components to look like they normally look?
> > > >
> > > > I'm just thinking that what is currently being done is not enough to
> > > > have the full skinning features available, and that going the
> > > > direction of adding the CSS dynamically would allow to do so.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/26/07, Scott O'Bryan <da...@gmail.com> wrote:
> > > > > Hey Martin,
> > > > >
> > > > > Does the simple-portlet skin render any better? I *THINK* that when
> > > > > running in a portal environment you always get the simple-portlet
> skin
> > > > > unless your portal provides one of the necessary skin extensions
> which,
> > > > > right now, it trinidad proprietary. Maybe this is just a case of us
> > > > > needing to bug-fix the portlet skin.
> > > > >
> > > > > That article is interesting, but I think that Trinidad has attempted
> to
> > > > > do the same thing only in a different way. Instead of using
> javascript
> > > > > to copy in the styles, we actually change the class names that get
> > > > > rendered on the client to use the portal styles where appropriate.
> > > > > Still, I'm not sure that this has been tested extensively because
> before
> > > > > we started looking at 301, much of Trinidad's portal work has been
> done
> > > > > with a Proof of Concept environment.
> > > > >
> > > > > Scott
> > > > >
> > > > > 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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
Exactly. Now we might be able to do something on the "client" side to
tell if a CSS has been loaded or not. But we still have an issue with
the skinning extension.
The other option is to see if maybe JSR-286 is going to supply a more
complete list of styles and try to leverage those in the Trinidad
components.
Scott
Simon Lessard wrote:
> Bleh that wouldn't work, there would be no way for the first portlet
> to actually know that it's the first portlet... Would have to be the
> portal itself, but that's quite against the idea of making the portlet
> portable...
>
> On 7/30/07, *Simon Lessard* <simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
>
> Ok, I'm really getting out of ideas here... But here's another attempt
>
> Couldn't we use the portlet message event model for that ? If all
> portlets broadcast a message event containing their stylesheet
> (yeah, it will be ugly on the network latency...) then the first
> Trinidad portlet that catch those messages get in charge of
> rendering the styles and warn the other portlets that it's going
> to be by broadcasting yet another message (dunno if you can
> broadcast from an event listener though... I have yet to read most
> of the spec on portlet events)...
>
>
> Regards,
>
> ~ Simon
>
>
> On 7/30/07, *Scott O'Bryan* < darkarena@gmail.com
> <ma...@gmail.com>> wrote:
>
> Oops. Submitted before I was done.
>
> Currently Trinidad supports the ability to turn off
> stylesheets, it also
> supports the ability to force a certain skin to
> render. Making is so
> that the stylesheet only loads once, however, is not trivial
> and since
> skinning extensions are currently combined into a single style
> sheet,
> the first portlet and/or the portal container would need to
> make sure
> those skinning extensions are installed as well.
>
> Scott
>
> Scott O'Bryan wrote:
> > This won't work in WSRP Portal environments that may use
> distributed
> > portlets. This is because the portlets may exist on different
> > servers. Furthermore different portlets may have different
> skinning
> > extensions. This will hose the styling if a portlet with no
> skinning
> > extensions gets added before portlets WITH skinning
> extensions. The
> > skinning extensions will not be available
> >
> >
> > Martin Marinschek wrote:
> >> Sure, this would work.
> >>
> >> Everyone agreeing we should do it this way?
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 7/28/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>
> >>> Yeah, that would imply every single renderers. In a
> non-portlet
> >>> environment
> >>> the performance hit would not be big though as it would
> only be on
> >>> method
> >>> call and checking if we run in a portlet environment would
> not be an
> >>> expensive operation compared to the overall job done by
> renderers.
> >>> However
> >>> in the portlet environment, it would be a tad more...
> >>>
> >>> What about a ResponseWriter decorator applied by the
> renderkit if it
> >>> get
> >>> called by a portlet environment? The decorator could inject the
> >>> JavaScript
> >>> style copy just before the first non <html>, <head> or <body>
> >>> element then
> >>> set a boolean flag to false to inhibit itself. The overhaul
> would
> >>> then be a
> >>> single if evaluation per startElement. It would be called
> often, but
> >>> a if
> >>> with a boolean flag get evaluated in 2 ticks, which is
> nothing for all
> >>> practical purposes.
> >>>
> >>>
> >>> On 7/28/07, Martin Marinschek <martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
> >>>
> >>>> But you'd need to do this check in every renderer then,
> right? I
> >>>> wonder if this is good performance wise.
> >>>>
> >>>> regards,
> >>>>
> >>>> Martin
> >>>>
> >>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>
> >>>>> One way would be to have something along those line:
> >>>>>
> >>>>> CoreRenderer.java
> >>>>>
> >>>>> public void encodeBegin(FacesContext context,
> UIComponent component)
> >>>>> {
> >>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
> >>>>>
> >>> !isStyleSheetCopied())
> >>>
> >>>>> {
> >>>>> pushStyleSheet(context);
> >>>>> }
> >>>>>
> >>>>> // Do normal processing
> >>>>> }
> >>>>>
> >>>>> protected abstract boolean isXhtmlRootElement();
> >>>>>
> >>>>> Then we would simply have to make isXhtmlRootElement()
> return true
> >>>>> for
> >>>>> document, head and body renderers and false for the
> others. But
> >>>>> it's not
> >>>>> extremely clean.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> ~ Simon
> >>>>>
> >>>>>
> >>>>> On 7/27/07, Martin Marinschek <
> martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>
> >>>>>> Sure, it would be better for the user if it works out of
> the box.
> >>>>>>
> >>>>>> As much as I think, I don't find a central place where
> to put it,
> >>>>>>
> >>> though.
> >>>
> >>>>>> Ideas anyone?
> >>>>>>
> >>>>>> regards,
> >>>>>>
> >>>>>> Martin
> >>>>>>
> >>>>>> On 7/27/07, Simon Lessard <simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>>
> >>>>>>> Hello Martin,
> >>>>>>>
> >>>>>>> Yeah I thought about a new component and we actually
> already have
> >>>>>>> <trh:styleSheet/> that could be slightly altered to do
> that work,
> >>>>>>>
> >>> but I
> >>>
> >>>>>>> would prefer a way not involving any action from users.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 7/27/07, Martin Marinschek <
> martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>>>
> >>>>>>>> Hi Simon,
> >>>>>>>>
> >>>>>>>> true. The form-render was good for my nice small
> example, but is
> >>>>>>>>
> >>> no
> >>>
> >>>>>>>> general solution of course.
> >>>>>>>>
> >>>>>>>> I wonder if this would mandate a special component
> which does
> >>>>>>>>
> >>> nothing
> >>>
> >>>>>>>> but adding the stylesheet to the head?
> >>>>>>>>
> >>>>>>>> Eventually, the component could be generalized, so
> that all kinds
> >>>>>>>>
> >>> of
> >>>
> >>>>>>>> stylesheets can be added, if a link is provided and
> the stylesheet
> >>>>>>>> hasn't been added so far - I think this solution might be
> >>>>>>>>
> >>> interesting
> >>>
> >>>>>>>> for the portlet-developer in general.
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>>
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>>>>
> >>>>>>>>> Issue with #3 is not very hard, we already have a
> >>>>>>>>>
> >>> RenderingContext
> >>>
> >>>>> that
> >>>>>
> >>>>>>> can
> >>>>>>>
> >>>>>>>>> be used for that. We could probably hook that code in
> >>>>>>>>>
> >>> CoreRenderer
> >>>
> >>>>> or
> >>>>>
> >>>>>>>>> XhtmlRenderer. The only issue left then would be to
> not have
> >>>>>>>>>
> >>>>> document,
> >>>>>
> >>>>>>> head
> >>>>>>>
> >>>>>>>>> and body renderer to execute it. Placing it in
> FormRenderer only
> >>>>>>>>>
> >>>>> does
> >>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>>> seems right in case your page does not contain a form
> at all or
> >>>>>>>>>
> >>> use
> >>>
> >>>>> a
> >>>>>
> >>>>>>> basic
> >>>>>>>
> >>>>>>>>> JSF form (extremely unlikely though).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 7/27/07, Martin Marinschek <
> martin.marinschek@gmail.com <ma...@gmail.com>>
> >>>>>>>>>
> >>> wrote:
> >>>
> >>>>>>>>>> For the discussion on if and how to integrate this into
> >>>>>>>>>>
> >>> Trinidad -
> >>>
> >>>>> I
> >>>>>
> >>>>>>>>>> see three cases:
> >>>>>>>>>>
> >>>>>>>>>> 1) people only want basic skinning, Trinidad uses
> >>>>>>>>>>
> >>> simple.portlet,
> >>>
> >>>>> and
> >>>>>
> >>>>>>>>>> emits portlet-standard compliant skinning hooks
> >>>>>>>>>>
> >>>>>>>>>> 2) people want normal Trinidad skinning, portlet
> container
> >>>>>>>>>>
> >>>>> provides
> >>>>>
> >>>>>>>>>> CSS file in the head, Trinidad doesn't have to do
> anything
> >>>>>>>>>>
> >>>>> (especially
> >>>>>
> >>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
> >>>>>>>>>>
> >>>>>>>>>> 3) people want Trinidad skinning, portlet container
> does not
> >>>>>>>>>>
> >>>>> provide
> >>>>>
> >>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS
> file with
> >>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to
> be added
> >>>>>>>>>>
> >>> only
> >>>
> >>>>>>>>>> once.
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>>
> >>>>>>>>>> Martin
> >>>>>>>>>>
> >>>>>>>>>> On 7/27/07, Martin Marinschek <
> martin.marinschek@gmail.com <ma...@gmail.com> >
> >>>>>>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>>>>>>> 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/26/07, Simon Lessard <
> simon.lessard.3@gmail.com <ma...@gmail.com>>
> >>>>>>>>>>>
> >>> wrote:
> >>>
> >>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
> >>>>>>>>>>>>
> >>>>> vendor(s)...
> >>>>>
> >>>>>>> Ok,
> >>>>>>>
> >>>>>>>>> I see
> >>>>>>>>>
> >>>>>>>>>>>> the issue now... bleh...
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> <ma...@gmail.com> > wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Simon, you are correct. The portal would be able to
> >>>>>>>>>>>>>
> >>> push a
> >>>
> >>>>>>>>> parameter to
> >>>>>>>>>
> >>>>>>>>>>>>> Trinidad. Always in a portal environment the
> skin is
> >>>>>>>>>>>>>
> >>>>>>> uncompressed
> >>>>>>>
> >>>>>>>>> so
> >>>>>>>>>
> >>>>>>>>>>>>> that is also not an issue. But currently
> changing the
> >>>>>>>>>>>>>
> >>>>>>> stylesheet
> >>>>>>>
> >>>>>>>>>>>>> provided by the Portal is a modification that
> needs to
> >>>>>>>>>>>>>
> >>> be
> >>>
> >>>>> made
> >>>>>
> >>>>>>> to
> >>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>>>>>> portal itself. I think that's where Martin is coming
> >>>>>>>>>>>>>
> >>> from.
> >>>
> >>>>> An
> >>>>>
> >>>>>>>>>>>>> unmodified portal container doesn't look very
> good when
> >>>>>>>>>>>>>
> >>>>>>> displaying
> >>>>>>>
> >>>>>>>>> faces
> >>>>>>>>>
> >>>>>>>>>>>>> and forcing every portal container to provide a skin
> >>>>>>>>>>>>>
> >>> that is
> >>>
> >>>>> not
> >>>>>
> >>>>>>>>> based
> >>>>>>>>>
> >>>>>>>>>>>>> off a standard is not going to be very successful
> in the
> >>>>>>>>>>>>>
> >>>>> general
> >>>>>
> >>>>>>>>> case.
> >>>>>>>>>
> >>>>>>>>>>>>> I totally agree with this, but we're sort of
> between a
> >>>>>>>>>>>>>
> >>> rock
> >>>
> >>>>> and
> >>>>>
> >>>>>>> a
> >>>>>>>
> >>>>>>>>> hard
> >>>>>>>>>
> >>>>>>>>>>>>> place. :)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Simon Lessard wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Not really, I think we detect a specific parameter
> >>>>>>>>>>>>>>
> >>> pushed
> >>>
> >>>>> by
> >>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>>>>>>>> container. So only container supporting skinning
> would
> >>>>>>>>>>>>>>
> >>>>> push
> >>>>>
> >>>>>>> it,
> >>>>>>>
> >>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For
> other
> >>>>>>>>>>>>>>
> >>>>> container
> >>>>>
> >>>>>>> I
> >>>>>>>
> >>>>>>>>> think
> >>>>>>>>>
> >>>>>>>>>>>>>> we simply use the normal code path... That or I had
> >>>>>>>>>>>>>>
> >>> some
> >>>
> >>>>>>> serious
> >>>>>>>
> >>>>>>>>>>>>>> hallucinations in the past months and imagined all
> >>>>>>>>>>>>>>
> >>> this...
> >>>
> >>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
> >>>>>>>>>>>>>>
> >>>>> martin.marinschek@gmail.com
> <ma...@gmail.com>
> >>>>>
> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
> <ma...@gmail.com> >> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Simon,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> well, but this would then be portlet container
> >>>>>>>>>>>>>>
> >>>>> dependent,
> >>>>>
> >>>>>>>>> right?
> >>>>>>>>>
> >>>>>>>>>>>> You'd
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> effectively need to implement trinidad
> skinning in
> >>>>>>>>>>>>>>
> >>>>> every
> >>>>>
> >>>>>>>>> portlet
> >>>>>>>>>
> >>>>>>>>>>>>>> container.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Martin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
> >>>>>>>>>>>>>>
> >>> simon.lessard.3@gmail.com <ma...@gmail.com>
> >>>
> >>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com
> <ma...@gmail.com>>> wrote:
> >>>>>>>>>>>>>> > Personally, I don't see why the portal should
> >>>>>>>>>>>>>>
> >>> not be
> >>>
> >>>>>>> able to
> >>>>>>>
> >>>>>>>>>>>>>> provide all
> >>>>>>>>>>>>>> > selectors.
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> > Aren't we just not compressing the selector
> >>>>>>>>>>>>>>
> >>> names
> >>>
> >>>>> when
> >>>>>
> >>>>>>> we
> >>>>>>>
> >>>>>>>>> detect
> >>>>>>>>>
> >>>>>>>>>>>>>> a portal
> >>>>>>>>>>>>>> > environment or did I miss something? I think
> >>>>>>>>>>>>>>
> >>> that
> >>>
> >>>>>>> strategy
> >>>>>>>
> >>>>>>>>>>>>>> cannot provides
> >>>>>>>>>>>>>> > the icons though.
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
> >>>>>>>>>>>>>>
> >>>>>>> martin.marinschek@gmail.com
> <ma...@gmail.com>
> >>>>>>>
> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
> <ma...@gmail.com> >> wrote:
> >>>>>>>>>>>>>> > > Does the portlet container really provide
> >>>>>>>>>>>>>>
> >>> every
> >>>
> >>>>>>> styleclass
> >>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>>>>> is
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> > > necessary for Trinidad components to
> look like
> >>>>>>>>>>>>>>
> >>>>> they
> >>>>>
> >>>>>>>>> normally
> >>>>>>>>>
> >>>>>>>>>>>> look?
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > I'm just thinking that what is currently
> being
> >>>>>>>>>>>>>>
> >>>>> done is
> >>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>>>>>>>> enough to
> >>>>>>>>>>>>>> > > have the full skinning features
> available, and
> >>>>>>>>>>>>>>
> >>>>> that
> >>>>>
> >>>>>>> going
> >>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>>>>>>> > > direction of adding the CSS dynamically
> would
> >>>>>>>>>>>>>>
> >>>>> allow to
> >>>>>
> >>>>>>> do
> >>>>>>>
> >>>>>>>>> so.
> >>>>>>>>>
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > regards,
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > Martin
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
> >>>>>>>>>>>>>>
> >>> darkarena@gmail.com <ma...@gmail.com>
> >>>
> >>>>>>>>>>>>>> <mailto: darkarena@gmail.com
> <ma...@gmail.com>>> wrote:
> >>>>>>>>>>>>>> > > > Hey Martin,
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
> >>>>>>>>>>>>>>
> >>> better?
> >>>
> >>>>> I
> >>>>>
> >>>>>>>>> *THINK*
> >>>>>>>>>
> >>>>>>>>>>>>>> that when
> >>>>>>>>>>>>>> > > > running in a portal environment you always
> >>>>>>>>>>>>>>
> >>> get
> >>>
> >>>>> the
> >>>>>
> >>>>>>>>>>>>>> simple-portlet skin
> >>>>>>>>>>>>>> > > > unless your portal provides one of the
> >>>>>>>>>>>>>>
> >>> necessary
> >>>
> >>>>>>> skin
> >>>>>>>
> >>>>>>>>>>>>>> extensions which,
> >>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
> >>>>>>>>>>>>>>
> >>> this
> >>>
> >>>>> is
> >>>>>
> >>>>>>> just
> >>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>>>>>>> case of us
> >>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > That article is interesting, but I think
> >>>>>>>>>>>>>>
> >>> that
> >>>
> >>>>>>> Trinidad
> >>>>>>>
> >>>>>>>>> has
> >>>>>>>>>
> >>>>>>>>>>>>>> attempted to
> >>>>>>>>>>>>>> > > > do the same thing only in a different way.
> >>>>>>>>>>>>>>
> >>>>> Instead
> >>>>>
> >>>>>>> of
> >>>>>>>
> >>>>>>>>> using
> >>>>>>>>>
> >>>>>>>>>>>>>> javascript
> >>>>>>>>>>>>>> > > > to copy in the styles, we actually change
> >>>>>>>>>>>>>>
> >>> the
> >>>
> >>>>> class
> >>>>>
> >>>>>>>>> names
> >>>>>>>>>
> >>>>>>>>>>>>>> that get
> >>>>>>>>>>>>>> > > > rendered on the client to use the portal
> >>>>>>>>>>>>>>
> >>> styles
> >>>
> >>>>>>> where
> >>>>>>>
> >>>>>>>>>>>>>> appropriate.
> >>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
> >>>>>>>>>>>>>>
> >>> tested
> >>>
> >>>>>>>>> extensively
> >>>>>>>>>
> >>>>>>>>>>>>>> because before
> >>>>>>>>>>>>>> > > > we started looking at 301, much of
> >>>>>>>>>>>>>>
> >>> Trinidad's
> >>>
> >>>>> portal
> >>>>>
> >>>>>>>>> work
> >>>>>>>>>
> >>>>>>>>>>>>>> has been done
> >>>>>>>>>>>>>> > > > with a Proof of Concept environment.
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > Scott
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > 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
> <http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html>
> >>>
> >>>>>>>>>>>> <
> >>>>>>>>>>>>
> >>>
> http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> <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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> http://www.irian.at <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 <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
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
>
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Bleh that wouldn't work, there would be no way for the first portlet to
actually know that it's the first portlet... Would have to be the portal
itself, but that's quite against the idea of making the portlet portable...
On 7/30/07, Simon Lessard <si...@gmail.com> wrote:
>
> Ok, I'm really getting out of ideas here... But here's another attempt
>
> Couldn't we use the portlet message event model for that ? If all portlets
> broadcast a message event containing their stylesheet (yeah, it will be ugly
> on the network latency...) then the first Trinidad portlet that catch those
> messages get in charge of rendering the styles and warn the other portlets
> that it's going to be by broadcasting yet another message (dunno if you can
> broadcast from an event listener though... I have yet to read most of the
> spec on portlet events)...
>
>
> Regards,
>
> ~ Simon
>
> On 7/30/07, Scott O'Bryan <da...@gmail.com> wrote:
> >
> > Oops. Submitted before I was done.
> >
> > Currently Trinidad supports the ability to turn off stylesheets, it also
> > supports the ability to force a certain skin to render. Making is so
> > that the stylesheet only loads once, however, is not trivial and since
> > skinning extensions are currently combined into a single style sheet,
> > the first portlet and/or the portal container would need to make sure
> > those skinning extensions are installed as well.
> >
> > Scott
> >
> > Scott O'Bryan wrote:
> > > This won't work in WSRP Portal environments that may use distributed
> > > portlets. This is because the portlets may exist on different
> > > servers. Furthermore different portlets may have different skinning
> > > extensions. This will hose the styling if a portlet with no skinning
> > > extensions gets added before portlets WITH skinning extensions. The
> > > skinning extensions will not be available
> > >
> > >
> > > Martin Marinschek wrote:
> > >> Sure, this would work.
> > >>
> > >> Everyone agreeing we should do it this way?
> > >>
> > >> regards,
> > >>
> > >> Martin
> > >>
> > >> On 7/28/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > >>
> > >>> Yeah, that would imply every single renderers. In a non-portlet
> > >>> environment
> > >>> the performance hit would not be big though as it would only be on
> > >>> method
> > >>> call and checking if we run in a portlet environment would not be an
> > >>> expensive operation compared to the overall job done by renderers.
> > >>> However
> > >>> in the portlet environment, it would be a tad more...
> > >>>
> > >>> What about a ResponseWriter decorator applied by the renderkit if it
> > >>> get
> > >>> called by a portlet environment? The decorator could inject the
> > >>> JavaScript
> > >>> style copy just before the first non <html>, <head> or <body>
> > >>> element then
> > >>> set a boolean flag to false to inhibit itself. The overhaul would
> > >>> then be a
> > >>> single if evaluation per startElement. It would be called often, but
> > >>> a if
> > >>> with a boolean flag get evaluated in 2 ticks, which is nothing for
> > all
> > >>> practical purposes.
> > >>>
> > >>>
> > >>> On 7/28/07, Martin Marinschek <ma...@gmail.com> wrote:
> > >>>
> > >>>> But you'd need to do this check in every renderer then, right? I
> > >>>> wonder if this is good performance wise.
> > >>>>
> > >>>> regards,
> > >>>>
> > >>>> Martin
> > >>>>
> > >>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > >>>>
> > >>>>> One way would be to have something along those line:
> > >>>>>
> > >>>>> CoreRenderer.java
> > >>>>>
> > >>>>> public void encodeBegin(FacesContext context, UIComponent
> > component)
> > >>>>> {
> > >>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
> > >>>>>
> > >>> !isStyleSheetCopied())
> > >>>
> > >>>>> {
> > >>>>> pushStyleSheet(context);
> > >>>>> }
> > >>>>>
> > >>>>> // Do normal processing
> > >>>>> }
> > >>>>>
> > >>>>> protected abstract boolean isXhtmlRootElement();
> > >>>>>
> > >>>>> Then we would simply have to make isXhtmlRootElement() return true
> >
> > >>>>> for
> > >>>>> document, head and body renderers and false for the others. But
> > >>>>> it's not
> > >>>>> extremely clean.
> > >>>>>
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> ~ Simon
> > >>>>>
> > >>>>>
> > >>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
> > wrote:
> > >>>>>
> > >>>>>> Sure, it would be better for the user if it works out of the box.
> > >>>>>>
> > >>>>>> As much as I think, I don't find a central place where to put it,
> >
> > >>>>>>
> > >>> though.
> > >>>
> > >>>>>> Ideas anyone?
> > >>>>>>
> > >>>>>> regards,
> > >>>>>>
> > >>>>>> Martin
> > >>>>>>
> > >>>>>> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > >>>>>>
> > >>>>>>> Hello Martin,
> > >>>>>>>
> > >>>>>>> Yeah I thought about a new component and we actually already
> > have
> > >>>>>>> <trh:styleSheet/> that could be slightly altered to do that
> > work,
> > >>>>>>>
> > >>> but I
> > >>>
> > >>>>>>> would prefer a way not involving any action from users.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
> > wrote:
> > >>>>>>>
> > >>>>>>>> Hi Simon,
> > >>>>>>>>
> > >>>>>>>> true. The form-render was good for my nice small example, but
> > is
> > >>>>>>>>
> > >>> no
> > >>>
> > >>>>>>>> general solution of course.
> > >>>>>>>>
> > >>>>>>>> I wonder if this would mandate a special component which does
> > >>>>>>>>
> > >>> nothing
> > >>>
> > >>>>>>>> but adding the stylesheet to the head?
> > >>>>>>>>
> > >>>>>>>> Eventually, the component could be generalized, so that all
> > kinds
> > >>>>>>>>
> > >>> of
> > >>>
> > >>>>>>>> stylesheets can be added, if a link is provided and the
> > stylesheet
> > >>>>>>>> hasn't been added so far - I think this solution might be
> > >>>>>>>>
> > >>> interesting
> > >>>
> > >>>>>>>> for the portlet-developer in general.
> > >>>>>>>>
> > >>>>>>>> regards,
> > >>>>>>>>
> > >>>>>>>> Martin
> > >>>>>>>>
> > >>>>>>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>>> Issue with #3 is not very hard, we already have a
> > >>>>>>>>>
> > >>> RenderingContext
> > >>>
> > >>>>> that
> > >>>>>
> > >>>>>>> can
> > >>>>>>>
> > >>>>>>>>> be used for that. We could probably hook that code in
> > >>>>>>>>>
> > >>> CoreRenderer
> > >>>
> > >>>>> or
> > >>>>>
> > >>>>>>>>> XhtmlRenderer. The only issue left then would be to not have
> > >>>>>>>>>
> > >>>>> document,
> > >>>>>
> > >>>>>>> head
> > >>>>>>>
> > >>>>>>>>> and body renderer to execute it. Placing it in FormRenderer
> > only
> > >>>>>>>>>
> > >>>>> does
> > >>>>>
> > >>>>>>> not
> > >>>>>>>
> > >>>>>>>>> seems right in case your page does not contain a form at all
> > or
> > >>>>>>>>>
> > >>> use
> > >>>
> > >>>>> a
> > >>>>>
> > >>>>>>> basic
> > >>>>>>>
> > >>>>>>>>> JSF form (extremely unlikely though).
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
> > >>>>>>>>>
> > >>> wrote:
> > >>>
> > >>>>>>>>>> For the discussion on if and how to integrate this into
> > >>>>>>>>>>
> > >>> Trinidad -
> > >>>
> > >>>>> I
> > >>>>>
> > >>>>>>>>>> see three cases:
> > >>>>>>>>>>
> > >>>>>>>>>> 1) people only want basic skinning, Trinidad uses
> > >>>>>>>>>>
> > >>> simple.portlet,
> > >>>
> > >>>>> and
> > >>>>>
> > >>>>>>>>>> emits portlet-standard compliant skinning hooks
> > >>>>>>>>>>
> > >>>>>>>>>> 2) people want normal Trinidad skinning, portlet container
> > >>>>>>>>>>
> > >>>>> provides
> > >>>>>
> > >>>>>>>>>> CSS file in the head, Trinidad doesn't have to do anything
> > >>>>>>>>>>
> > >>>>> (especially
> > >>>>>
> > >>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
> > >>>>>>>>>>
> > >>>>>>>>>> 3) people want Trinidad skinning, portlet container does not
> > >>>>>>>>>>
> > >>>>> provide
> > >>>>>
> > >>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS file with
> > >>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to be added
> >
> > >>>>>>>>>>
> > >>> only
> > >>>
> > >>>>>>>>>> once.
> > >>>>>>>>>>
> > >>>>>>>>>> regards,
> > >>>>>>>>>>
> > >>>>>>>>>> Martin
> > >>>>>>>>>>
> > >>>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
> > >>>>>>>>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>>>>>>> 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/26/07, Simon Lessard < simon.lessard.3@gmail.com>
> > >>>>>>>>>>>
> > >>> wrote:
> > >>>
> > >>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
> > >>>>>>>>>>>>
> > >>>>> vendor(s)...
> > >>>>>
> > >>>>>>> Ok,
> > >>>>>>>
> > >>>>>>>>> I see
> > >>>>>>>>>
> > >>>>>>>>>>>> the issue now... bleh...
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Simon, you are correct. The portal would be able to
> > >>>>>>>>>>>>>
> > >>> push a
> > >>>
> > >>>>>>>>> parameter to
> > >>>>>>>>>
> > >>>>>>>>>>>>> Trinidad. Always in a portal environment the skin is
> > >>>>>>>>>>>>>
> > >>>>>>> uncompressed
> > >>>>>>>
> > >>>>>>>>> so
> > >>>>>>>>>
> > >>>>>>>>>>>>> that is also not an issue. But currently changing the
> > >>>>>>>>>>>>>
> > >>>>>>> stylesheet
> > >>>>>>>
> > >>>>>>>>>>>>> provided by the Portal is a modification that needs to
> > >>>>>>>>>>>>>
> > >>> be
> > >>>
> > >>>>> made
> > >>>>>
> > >>>>>>> to
> > >>>>>>>
> > >>>>>>>>> the
> > >>>>>>>>>
> > >>>>>>>>>>>>> portal itself. I think that's where Martin is coming
> > >>>>>>>>>>>>>
> > >>> from.
> > >>>
> > >>>>> An
> > >>>>>
> > >>>>>>>>>>>>> unmodified portal container doesn't look very good when
> > >>>>>>>>>>>>>
> > >>>>>>> displaying
> > >>>>>>>
> > >>>>>>>>> faces
> > >>>>>>>>>
> > >>>>>>>>>>>>> and forcing every portal container to provide a skin
> > >>>>>>>>>>>>>
> > >>> that is
> > >>>
> > >>>>> not
> > >>>>>
> > >>>>>>>>> based
> > >>>>>>>>>
> > >>>>>>>>>>>>> off a standard is not going to be very successful in the
> > >>>>>>>>>>>>>
> > >>>>> general
> > >>>>>
> > >>>>>>>>> case.
> > >>>>>>>>>
> > >>>>>>>>>>>>> I totally agree with this, but we're sort of between a
> > >>>>>>>>>>>>>
> > >>> rock
> > >>>
> > >>>>> and
> > >>>>>
> > >>>>>>> a
> > >>>>>>>
> > >>>>>>>>> hard
> > >>>>>>>>>
> > >>>>>>>>>>>>> place. :)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Simon Lessard wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Not really, I think we detect a specific parameter
> > >>>>>>>>>>>>>>
> > >>> pushed
> > >>>
> > >>>>> by
> > >>>>>
> > >>>>>>> the
> > >>>>>>>
> > >>>>>>>>>>>>>> container. So only container supporting skinning would
> > >>>>>>>>>>>>>>
> > >>>>> push
> > >>>>>
> > >>>>>>> it,
> > >>>>>>>
> > >>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For other
> > >>>>>>>>>>>>>>
> > >>>>> container
> > >>>>>
> > >>>>>>> I
> > >>>>>>>
> > >>>>>>>>> think
> > >>>>>>>>>
> > >>>>>>>>>>>>>> we simply use the normal code path... That or I had
> > >>>>>>>>>>>>>>
> > >>> some
> > >>>
> > >>>>>>> serious
> > >>>>>>>
> > >>>>>>>>>>>>>> hallucinations in the past months and imagined all
> > >>>>>>>>>>>>>>
> > >>> this...
> > >>>
> > >>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
> > >>>>>>>>>>>>>>
> > >>>>> martin.marinschek@gmail.com
> > >>>>>
> > >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi Simon,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> well, but this would then be portlet container
> > >>>>>>>>>>>>>>
> > >>>>> dependent,
> > >>>>>
> > >>>>>>>>> right?
> > >>>>>>>>>
> > >>>>>>>>>>>> You'd
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> effectively need to implement trinidad skinning in
> > >>>>>>>>>>>>>>
> > >>>>> every
> > >>>>>
> > >>>>>>>>> portlet
> > >>>>>>>>>
> > >>>>>>>>>>>>>> container.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Martin
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
> > >>>>>>>>>>>>>>
> > >>> simon.lessard.3@gmail.com
> > >>>
> > >>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com >> wrote:
> > >>>>>>>>>>>>>> > Personally, I don't see why the portal should
> > >>>>>>>>>>>>>>
> > >>> not be
> > >>>
> > >>>>>>> able to
> > >>>>>>>
> > >>>>>>>>>>>>>> provide all
> > >>>>>>>>>>>>>> > selectors.
> > >>>>>>>>>>>>>> >
> > >>>>>>>>>>>>>> > Aren't we just not compressing the selector
> > >>>>>>>>>>>>>>
> > >>> names
> > >>>
> > >>>>> when
> > >>>>>
> > >>>>>>> we
> > >>>>>>>
> > >>>>>>>>> detect
> > >>>>>>>>>
> > >>>>>>>>>>>>>> a portal
> > >>>>>>>>>>>>>> > environment or did I miss something? I think
> > >>>>>>>>>>>>>>
> > >>> that
> > >>>
> > >>>>>>> strategy
> > >>>>>>>
> > >>>>>>>>>>>>>> cannot provides
> > >>>>>>>>>>>>>> > the icons though.
> > >>>>>>>>>>>>>> >
> > >>>>>>>>>>>>>> >
> > >>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
> > >>>>>>>>>>>>>>
> > >>>>>>> martin.marinschek@gmail.com
> > >>>>>>>
> > >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
> > >>>>>>>>>>>>>> > > Does the portlet container really provide
> > >>>>>>>>>>>>>>
> > >>> every
> > >>>
> > >>>>>>> styleclass
> > >>>>>>>
> > >>>>>>>>> that
> > >>>>>>>>>
> > >>>>>>>>>>>> is
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> > > necessary for Trinidad components to look like
> > >>>>>>>>>>>>>>
> > >>>>> they
> > >>>>>
> > >>>>>>>>> normally
> > >>>>>>>>>
> > >>>>>>>>>>>> look?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > I'm just thinking that what is currently being
> > >>>>>>>>>>>>>>
> > >>>>> done is
> > >>>>>
> > >>>>>>> not
> > >>>>>>>
> > >>>>>>>>>>>>>> enough to
> > >>>>>>>>>>>>>> > > have the full skinning features available, and
> > >>>>>>>>>>>>>>
> > >>>>> that
> > >>>>>
> > >>>>>>> going
> > >>>>>>>
> > >>>>>>>>> the
> > >>>>>>>>>
> > >>>>>>>>>>>>>> > > direction of adding the CSS dynamically would
> > >>>>>>>>>>>>>>
> > >>>>> allow to
> > >>>>>
> > >>>>>>> do
> > >>>>>>>
> > >>>>>>>>> so.
> > >>>>>>>>>
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > regards,
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > Martin
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
> > >>>>>>>>>>>>>>
> > >>> darkarena@gmail.com
> > >>>
> > >>>>>>>>>>>>>> <mailto: darkarena@gmail.com >> wrote:
> > >>>>>>>>>>>>>> > > > Hey Martin,
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
> > >>>>>>>>>>>>>>
> > >>> better?
> > >>>
> > >>>>> I
> > >>>>>
> > >>>>>>>>> *THINK*
> > >>>>>>>>>
> > >>>>>>>>>>>>>> that when
> > >>>>>>>>>>>>>> > > > running in a portal environment you always
> > >>>>>>>>>>>>>>
> > >>> get
> > >>>
> > >>>>> the
> > >>>>>
> > >>>>>>>>>>>>>> simple-portlet skin
> > >>>>>>>>>>>>>> > > > unless your portal provides one of the
> > >>>>>>>>>>>>>>
> > >>> necessary
> > >>>
> > >>>>>>> skin
> > >>>>>>>
> > >>>>>>>>>>>>>> extensions which,
> > >>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
> > >>>>>>>>>>>>>>
> > >>> this
> > >>>
> > >>>>> is
> > >>>>>
> > >>>>>>> just
> > >>>>>>>
> > >>>>>>>>> a
> > >>>>>>>>>
> > >>>>>>>>>>>>>> case of us
> > >>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > That article is interesting, but I think
> > >>>>>>>>>>>>>>
> > >>> that
> > >>>
> > >>>>>>> Trinidad
> > >>>>>>>
> > >>>>>>>>> has
> > >>>>>>>>>
> > >>>>>>>>>>>>>> attempted to
> > >>>>>>>>>>>>>> > > > do the same thing only in a different way.
> > >>>>>>>>>>>>>>
> > >>>>> Instead
> > >>>>>
> > >>>>>>> of
> > >>>>>>>
> > >>>>>>>>> using
> > >>>>>>>>>
> > >>>>>>>>>>>>>> javascript
> > >>>>>>>>>>>>>> > > > to copy in the styles, we actually change
> > >>>>>>>>>>>>>>
> > >>> the
> > >>>
> > >>>>> class
> > >>>>>
> > >>>>>>>>> names
> > >>>>>>>>>
> > >>>>>>>>>>>>>> that get
> > >>>>>>>>>>>>>> > > > rendered on the client to use the portal
> > >>>>>>>>>>>>>>
> > >>> styles
> > >>>
> > >>>>>>> where
> > >>>>>>>
> > >>>>>>>>>>>>>> appropriate.
> > >>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
> > >>>>>>>>>>>>>>
> > >>> tested
> > >>>
> > >>>>>>>>> extensively
> > >>>>>>>>>
> > >>>>>>>>>>>>>> because before
> > >>>>>>>>>>>>>> > > > we started looking at 301, much of
> > >>>>>>>>>>>>>>
> > >>> Trinidad's
> > >>>
> > >>>>> portal
> > >>>>>
> > >>>>>>>>> work
> > >>>>>>>>>
> > >>>>>>>>>>>>>> has been done
> > >>>>>>>>>>>>>> > > > with a Proof of Concept environment.
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > Scott
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > 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
> > >>>
> > >>>>>>>>>>>> <
> > >>>>>>>>>>>>
> > >>> 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
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>> --
> > >>>>
> > >>>> http://www.irian.at
> > >>>>
> > >>>> Your JSF powerhouse -
> > >>>> JSF Consulting, Development and
> > >>>> Courses in English and German
> > >>>>
> > >>>> Professional Support for Apache MyFaces
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
Totally agree. And this is where Jeanne comes in because I suspect some
of this work may be done already. I think the missing piece may be to
split up the base skin from any skin extensions so that if a skin is
loaded but a skin extension is not, then they can be loaded separately.
Scott
Martin Marinschek wrote:
> Or we provide this additional component/tweak the existing
> stylesheet-component to provide such a feature optionally. Better have
> a way of doing this that requires customization than not having a way
> of doing this at all, right?
>
> regards,
>
> Martin
>
> On 7/30/07, Scott O'Bryan <da...@gmail.com> wrote:
>
>> It's possible, but Portlet events won't be available until JSR-286. And
>> although I've seen some of the AJAX support for 286, I'm not sure what
>> the eventing model will and will not support. So either way, we'll need
>> to revisit this I think when 286 comes out. For now we're probably
>> stuck with the simple styling.
>>
>> Simon Lessard wrote:
>>
>>> Ok, I'm really getting out of ideas here... But here's another attempt
>>>
>>> Couldn't we use the portlet message event model for that ? If all
>>> portlets broadcast a message event containing their stylesheet (yeah,
>>> it will be ugly on the network latency...) then the first Trinidad
>>> portlet that catch those messages get in charge of rendering the
>>> styles and warn the other portlets that it's going to be by
>>> broadcasting yet another message (dunno if you can broadcast from an
>>> event listener though... I have yet to read most of the spec on
>>> portlet events)...
>>>
>>>
>>> Regards,
>>>
>>> ~ Simon
>>>
>>> On 7/30/07, *Scott O'Bryan* <darkarena@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> Oops. Submitted before I was done.
>>>
>>> Currently Trinidad supports the ability to turn off stylesheets,
>>> it also
>>> supports the ability to force a certain skin to render. Making is so
>>> that the stylesheet only loads once, however, is not trivial and
>>> since
>>> skinning extensions are currently combined into a single style sheet,
>>> the first portlet and/or the portal container would need to make sure
>>> those skinning extensions are installed as well.
>>>
>>> Scott
>>>
>>> Scott O'Bryan wrote:
>>> > This won't work in WSRP Portal environments that may use distributed
>>> > portlets. This is because the portlets may exist on different
>>> > servers. Furthermore different portlets may have different
>>> skinning
>>> > extensions. This will hose the styling if a portlet with no
>>> skinning
>>> > extensions gets added before portlets WITH skinning extensions. The
>>> > skinning extensions will not be available
>>> >
>>> >
>>> > Martin Marinschek wrote:
>>> >> Sure, this would work.
>>> >>
>>> >> Everyone agreeing we should do it this way?
>>> >>
>>> >> regards,
>>> >>
>>> >> Martin
>>> >>
>>> >> On 7/28/07, Simon Lessard < simon.lessard.3@gmail.com
>>> <ma...@gmail.com>> wrote:
>>> >>
>>> >>> Yeah, that would imply every single renderers. In a non-portlet
>>> >>> environment
>>> >>> the performance hit would not be big though as it would only
>>> be on
>>> >>> method
>>> >>> call and checking if we run in a portlet environment would not
>>> be an
>>> >>> expensive operation compared to the overall job done by renderers.
>>> >>> However
>>> >>> in the portlet environment, it would be a tad more...
>>> >>>
>>> >>> What about a ResponseWriter decorator applied by the renderkit
>>> if it
>>> >>> get
>>> >>> called by a portlet environment? The decorator could inject the
>>> >>> JavaScript
>>> >>> style copy just before the first non <html>, <head> or <body>
>>> >>> element then
>>> >>> set a boolean flag to false to inhibit itself. The overhaul would
>>> >>> then be a
>>> >>> single if evaluation per startElement. It would be called
>>> often, but
>>> >>> a if
>>> >>> with a boolean flag get evaluated in 2 ticks, which is nothing
>>> for all
>>> >>> practical purposes.
>>> >>>
>>> >>>
>>> >>> On 7/28/07, Martin Marinschek <martin.marinschek@gmail.com
>>> <ma...@gmail.com>> wrote:
>>> >>>
>>> >>>> But you'd need to do this check in every renderer then, right? I
>>> >>>> wonder if this is good performance wise.
>>> >>>>
>>> >>>> regards,
>>> >>>>
>>> >>>> Martin
>>> >>>>
>>> >>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
>>> <ma...@gmail.com>> wrote:
>>> >>>>
>>> >>>>> One way would be to have something along those line:
>>> >>>>>
>>> >>>>> CoreRenderer.java
>>> >>>>>
>>> >>>>> public void encodeBegin(FacesContext context, UIComponent
>>> component)
>>> >>>>> {
>>> >>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
>>> >>>>>
>>> >>> !isStyleSheetCopied())
>>> >>>
>>> >>>>> {
>>> >>>>> pushStyleSheet(context);
>>> >>>>> }
>>> >>>>>
>>> >>>>> // Do normal processing
>>> >>>>> }
>>> >>>>>
>>> >>>>> protected abstract boolean isXhtmlRootElement();
>>> >>>>>
>>> >>>>> Then we would simply have to make isXhtmlRootElement()
>>> return true
>>> >>>>> for
>>> >>>>> document, head and body renderers and false for the others. But
>>> >>>>> it's not
>>> >>>>> extremely clean.
>>> >>>>>
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>>
>>> >>>>> ~ Simon
>>> >>>>>
>>> >>>>>
>>> >>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com
>>> <ma...@gmail.com>> wrote:
>>> >>>>>
>>> >>>>>> Sure, it would be better for the user if it works out of
>>> the box.
>>> >>>>>>
>>> >>>>>> As much as I think, I don't find a central place where to
>>> put it,
>>> >>>>>>
>>> >>> though.
>>> >>>
>>> >>>>>> Ideas anyone?
>>> >>>>>>
>>> >>>>>> regards,
>>> >>>>>>
>>> >>>>>> Martin
>>> >>>>>>
>>> >>>>>> On 7/27/07, Simon Lessard <simon.lessard.3@gmail.com
>>> <ma...@gmail.com>> wrote:
>>> >>>>>>
>>> >>>>>>> Hello Martin,
>>> >>>>>>>
>>> >>>>>>> Yeah I thought about a new component and we actually
>>> already have
>>> >>>>>>> <trh:styleSheet/> that could be slightly altered to do
>>> that work,
>>> >>>>>>>
>>> >>> but I
>>> >>>
>>> >>>>>>> would prefer a way not involving any action from users.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On 7/27/07, Martin Marinschek <
>>> martin.marinschek@gmail.com <ma...@gmail.com>>
>>> wrote:
>>> >>>>>>>
>>> >>>>>>>> Hi Simon,
>>> >>>>>>>>
>>> >>>>>>>> true. The form-render was good for my nice small example,
>>> but is
>>> >>>>>>>>
>>> >>> no
>>> >>>
>>> >>>>>>>> general solution of course.
>>> >>>>>>>>
>>> >>>>>>>> I wonder if this would mandate a special component which does
>>> >>>>>>>>
>>> >>> nothing
>>> >>>
>>> >>>>>>>> but adding the stylesheet to the head?
>>> >>>>>>>>
>>> >>>>>>>> Eventually, the component could be generalized, so that
>>> all kinds
>>> >>>>>>>>
>>> >>> of
>>> >>>
>>> >>>>>>>> stylesheets can be added, if a link is provided and the
>>> stylesheet
>>> >>>>>>>> hasn't been added so far - I think this solution might be
>>> >>>>>>>>
>>> >>> interesting
>>> >>>
>>> >>>>>>>> for the portlet-developer in general.
>>> >>>>>>>>
>>> >>>>>>>> regards,
>>> >>>>>>>>
>>> >>>>>>>> Martin
>>> >>>>>>>>
>>> >>>>>>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
>>> <ma...@gmail.com>> wrote:
>>> >>>>>>>>
>>> >>>>>>>>> Issue with #3 is not very hard, we already have a
>>> >>>>>>>>>
>>> >>> RenderingContext
>>> >>>
>>> >>>>> that
>>> >>>>>
>>> >>>>>>> can
>>> >>>>>>>
>>> >>>>>>>>> be used for that. We could probably hook that code in
>>> >>>>>>>>>
>>> >>> CoreRenderer
>>> >>>
>>> >>>>> or
>>> >>>>>
>>> >>>>>>>>> XhtmlRenderer. The only issue left then would be to not
>>> have
>>> >>>>>>>>>
>>> >>>>> document,
>>> >>>>>
>>> >>>>>>> head
>>> >>>>>>>
>>> >>>>>>>>> and body renderer to execute it. Placing it in
>>> FormRenderer only
>>> >>>>>>>>>
>>> >>>>> does
>>> >>>>>
>>> >>>>>>> not
>>> >>>>>>>
>>> >>>>>>>>> seems right in case your page does not contain a form at
>>> all or
>>> >>>>>>>>>
>>> >>> use
>>> >>>
>>> >>>>> a
>>> >>>>>
>>> >>>>>>> basic
>>> >>>>>>>
>>> >>>>>>>>> JSF form (extremely unlikely though).
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> On 7/27/07, Martin Marinschek <
>>> martin.marinschek@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>
>>> >>> wrote:
>>> >>>
>>> >>>>>>>>>> For the discussion on if and how to integrate this into
>>> >>>>>>>>>>
>>> >>> Trinidad -
>>> >>>
>>> >>>>> I
>>> >>>>>
>>> >>>>>>>>>> see three cases:
>>> >>>>>>>>>>
>>> >>>>>>>>>> 1) people only want basic skinning, Trinidad uses
>>> >>>>>>>>>>
>>> >>> simple.portlet,
>>> >>>
>>> >>>>> and
>>> >>>>>
>>> >>>>>>>>>> emits portlet-standard compliant skinning hooks
>>> >>>>>>>>>>
>>> >>>>>>>>>> 2) people want normal Trinidad skinning, portlet container
>>> >>>>>>>>>>
>>> >>>>> provides
>>> >>>>>
>>> >>>>>>>>>> CSS file in the head, Trinidad doesn't have to do anything
>>> >>>>>>>>>>
>>> >>>>> (especially
>>> >>>>>
>>> >>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
>>> >>>>>>>>>>
>>> >>>>>>>>>> 3) people want Trinidad skinning, portlet container
>>> does not
>>> >>>>>>>>>>
>>> >>>>> provide
>>> >>>>>
>>> >>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS
>>> file with
>>> >>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to be
>>> added
>>> >>>>>>>>>>
>>> >>> only
>>> >>>
>>> >>>>>>>>>> once.
>>> >>>>>>>>>>
>>> >>>>>>>>>> regards,
>>> >>>>>>>>>>
>>> >>>>>>>>>> Martin
>>> >>>>>>>>>>
>>> >>>>>>>>>> On 7/27/07, Martin Marinschek <
>>> martin.marinschek@gmail.com <ma...@gmail.com> >
>>> >>>>>>>>>>
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>>>>>>> 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/26/07, Simon Lessard < simon.lessard.3@gmail.com
>>> <ma...@gmail.com>>
>>> >>>>>>>>>>>
>>> >>> wrote:
>>> >>>
>>> >>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
>>> >>>>>>>>>>>>
>>> >>>>> vendor(s)...
>>> >>>>>
>>> >>>>>>> Ok,
>>> >>>>>>>
>>> >>>>>>>>> I see
>>> >>>>>>>>>
>>> >>>>>>>>>>>> the issue now... bleh...
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com
>>> <ma...@gmail.com> > wrote:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>> Simon, you are correct. The portal would be able to
>>> >>>>>>>>>>>>>
>>> >>> push a
>>> >>>
>>> >>>>>>>>> parameter to
>>> >>>>>>>>>
>>> >>>>>>>>>>>>> Trinidad. Always in a portal environment the skin is
>>> >>>>>>>>>>>>>
>>> >>>>>>> uncompressed
>>> >>>>>>>
>>> >>>>>>>>> so
>>> >>>>>>>>>
>>> >>>>>>>>>>>>> that is also not an issue. But currently changing the
>>> >>>>>>>>>>>>>
>>> >>>>>>> stylesheet
>>> >>>>>>>
>>> >>>>>>>>>>>>> provided by the Portal is a modification that needs to
>>> >>>>>>>>>>>>>
>>> >>> be
>>> >>>
>>> >>>>> made
>>> >>>>>
>>> >>>>>>> to
>>> >>>>>>>
>>> >>>>>>>>> the
>>> >>>>>>>>>
>>> >>>>>>>>>>>>> portal itself. I think that's where Martin is coming
>>> >>>>>>>>>>>>>
>>> >>> from.
>>> >>>
>>> >>>>> An
>>> >>>>>
>>> >>>>>>>>>>>>> unmodified portal container doesn't look very good when
>>> >>>>>>>>>>>>>
>>> >>>>>>> displaying
>>> >>>>>>>
>>> >>>>>>>>> faces
>>> >>>>>>>>>
>>> >>>>>>>>>>>>> and forcing every portal container to provide a skin
>>> >>>>>>>>>>>>>
>>> >>> that is
>>> >>>
>>> >>>>> not
>>> >>>>>
>>> >>>>>>>>> based
>>> >>>>>>>>>
>>> >>>>>>>>>>>>> off a standard is not going to be very successful in the
>>> >>>>>>>>>>>>>
>>> >>>>> general
>>> >>>>>
>>> >>>>>>>>> case.
>>> >>>>>>>>>
>>> >>>>>>>>>>>>> I totally agree with this, but we're sort of between a
>>> >>>>>>>>>>>>>
>>> >>> rock
>>> >>>
>>> >>>>> and
>>> >>>>>
>>> >>>>>>> a
>>> >>>>>>>
>>> >>>>>>>>> hard
>>> >>>>>>>>>
>>> >>>>>>>>>>>>> place. :)
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Simon Lessard wrote:
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Not really, I think we detect a specific parameter
>>> >>>>>>>>>>>>>>
>>> >>> pushed
>>> >>>
>>> >>>>> by
>>> >>>>>
>>> >>>>>>> the
>>> >>>>>>>
>>> >>>>>>>>>>>>>> container. So only container supporting skinning would
>>> >>>>>>>>>>>>>>
>>> >>>>> push
>>> >>>>>
>>> >>>>>>> it,
>>> >>>>>>>
>>> >>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For other
>>> >>>>>>>>>>>>>>
>>> >>>>> container
>>> >>>>>
>>> >>>>>>> I
>>> >>>>>>>
>>> >>>>>>>>> think
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> we simply use the normal code path... That or I had
>>> >>>>>>>>>>>>>>
>>> >>> some
>>> >>>
>>> >>>>>>> serious
>>> >>>>>>>
>>> >>>>>>>>>>>>>> hallucinations in the past months and imagined all
>>> >>>>>>>>>>>>>>
>>> >>> this...
>>> >>>
>>> >>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
>>> >>>>>>>>>>>>>>
>>> >>>>> martin.marinschek@gmail.com <ma...@gmail.com>
>>> >>>>>
>>> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
>>> <ma...@gmail.com> >> wrote:
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Hi Simon,
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> well, but this would then be portlet container
>>> >>>>>>>>>>>>>>
>>> >>>>> dependent,
>>> >>>>>
>>> >>>>>>>>> right?
>>> >>>>>>>>>
>>> >>>>>>>>>>>> You'd
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>>> effectively need to implement trinidad skinning in
>>> >>>>>>>>>>>>>>
>>> >>>>> every
>>> >>>>>
>>> >>>>>>>>> portlet
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> container.
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> regards,
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Martin
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
>>> >>>>>>>>>>>>>>
>>> >>> simon.lessard.3@gmail.com <ma...@gmail.com>
>>> >>>
>>> >>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com
>>> <ma...@gmail.com>>> wrote:
>>> >>>>>>>>>>>>>> > Personally, I don't see why the portal should
>>> >>>>>>>>>>>>>>
>>> >>> not be
>>> >>>
>>> >>>>>>> able to
>>> >>>>>>>
>>> >>>>>>>>>>>>>> provide all
>>> >>>>>>>>>>>>>> > selectors.
>>> >>>>>>>>>>>>>> >
>>> >>>>>>>>>>>>>> > Aren't we just not compressing the selector
>>> >>>>>>>>>>>>>>
>>> >>> names
>>> >>>
>>> >>>>> when
>>> >>>>>
>>> >>>>>>> we
>>> >>>>>>>
>>> >>>>>>>>> detect
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> a portal
>>> >>>>>>>>>>>>>> > environment or did I miss something? I think
>>> >>>>>>>>>>>>>>
>>> >>> that
>>> >>>
>>> >>>>>>> strategy
>>> >>>>>>>
>>> >>>>>>>>>>>>>> cannot provides
>>> >>>>>>>>>>>>>> > the icons though.
>>> >>>>>>>>>>>>>> >
>>> >>>>>>>>>>>>>> >
>>> >>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
>>> >>>>>>>>>>>>>>
>>> >>>>>>> martin.marinschek@gmail.com
>>> <ma...@gmail.com>
>>> >>>>>>>
>>> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
>>> <ma...@gmail.com> >> wrote:
>>> >>>>>>>>>>>>>> > > Does the portlet container really provide
>>> >>>>>>>>>>>>>>
>>> >>> every
>>> >>>
>>> >>>>>>> styleclass
>>> >>>>>>>
>>> >>>>>>>>> that
>>> >>>>>>>>>
>>> >>>>>>>>>>>> is
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>>> > > necessary for Trinidad components to look like
>>> >>>>>>>>>>>>>>
>>> >>>>> they
>>> >>>>>
>>> >>>>>>>>> normally
>>> >>>>>>>>>
>>> >>>>>>>>>>>> look?
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>>> > >
>>> >>>>>>>>>>>>>> > > I'm just thinking that what is currently being
>>> >>>>>>>>>>>>>>
>>> >>>>> done is
>>> >>>>>
>>> >>>>>>> not
>>> >>>>>>>
>>> >>>>>>>>>>>>>> enough to
>>> >>>>>>>>>>>>>> > > have the full skinning features available, and
>>> >>>>>>>>>>>>>>
>>> >>>>> that
>>> >>>>>
>>> >>>>>>> going
>>> >>>>>>>
>>> >>>>>>>>> the
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> > > direction of adding the CSS dynamically would
>>> >>>>>>>>>>>>>>
>>> >>>>> allow to
>>> >>>>>
>>> >>>>>>> do
>>> >>>>>>>
>>> >>>>>>>>> so.
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> > >
>>> >>>>>>>>>>>>>> > > regards,
>>> >>>>>>>>>>>>>> > >
>>> >>>>>>>>>>>>>> > > Martin
>>> >>>>>>>>>>>>>> > >
>>> >>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
>>> >>>>>>>>>>>>>>
>>> >>> darkarena@gmail.com <ma...@gmail.com>
>>> >>>
>>> >>>>>>>>>>>>>> <mailto: darkarena@gmail.com
>>> <ma...@gmail.com>>> wrote:
>>> >>>>>>>>>>>>>> > > > Hey Martin,
>>> >>>>>>>>>>>>>> > > >
>>> >>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
>>> >>>>>>>>>>>>>>
>>> >>> better?
>>> >>>
>>> >>>>> I
>>> >>>>>
>>> >>>>>>>>> *THINK*
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> that when
>>> >>>>>>>>>>>>>> > > > running in a portal environment you always
>>> >>>>>>>>>>>>>>
>>> >>> get
>>> >>>
>>> >>>>> the
>>> >>>>>
>>> >>>>>>>>>>>>>> simple-portlet skin
>>> >>>>>>>>>>>>>> > > > unless your portal provides one of the
>>> >>>>>>>>>>>>>>
>>> >>> necessary
>>> >>>
>>> >>>>>>> skin
>>> >>>>>>>
>>> >>>>>>>>>>>>>> extensions which,
>>> >>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
>>> >>>>>>>>>>>>>>
>>> >>> this
>>> >>>
>>> >>>>> is
>>> >>>>>
>>> >>>>>>> just
>>> >>>>>>>
>>> >>>>>>>>> a
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> case of us
>>> >>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
>>> >>>>>>>>>>>>>> > > >
>>> >>>>>>>>>>>>>> > > > That article is interesting, but I think
>>> >>>>>>>>>>>>>>
>>> >>> that
>>> >>>
>>> >>>>>>> Trinidad
>>> >>>>>>>
>>> >>>>>>>>> has
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> attempted to
>>> >>>>>>>>>>>>>> > > > do the same thing only in a different way.
>>> >>>>>>>>>>>>>>
>>> >>>>> Instead
>>> >>>>>
>>> >>>>>>> of
>>> >>>>>>>
>>> >>>>>>>>> using
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> javascript
>>> >>>>>>>>>>>>>> > > > to copy in the styles, we actually change
>>> >>>>>>>>>>>>>>
>>> >>> the
>>> >>>
>>> >>>>> class
>>> >>>>>
>>> >>>>>>>>> names
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> that get
>>> >>>>>>>>>>>>>> > > > rendered on the client to use the portal
>>> >>>>>>>>>>>>>>
>>> >>> styles
>>> >>>
>>> >>>>>>> where
>>> >>>>>>>
>>> >>>>>>>>>>>>>> appropriate.
>>> >>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
>>> >>>>>>>>>>>>>>
>>> >>> tested
>>> >>>
>>> >>>>>>>>> extensively
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> because before
>>> >>>>>>>>>>>>>> > > > we started looking at 301, much of
>>> >>>>>>>>>>>>>>
>>> >>> Trinidad's
>>> >>>
>>> >>>>> portal
>>> >>>>>
>>> >>>>>>>>> work
>>> >>>>>>>>>
>>> >>>>>>>>>>>>>> has been done
>>> >>>>>>>>>>>>>> > > > with a Proof of Concept environment.
>>> >>>>>>>>>>>>>> > > >
>>> >>>>>>>>>>>>>> > > > Scott
>>> >>>>>>>>>>>>>> > > >
>>> >>>>>>>>>>>>>> > > > 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
>>> >>>
>>> >>>>>>>>>>>> <
>>> >>>>>>>>>>>>
>>> >>> 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
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>> --
>>> >>>>>>>>>>
>>> >>>>>>>>>> http://www.irian.at <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
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>> --
>>> >>>>
>>> >>>> http://www.irian.at
>>> >>>>
>>> >>>> Your JSF powerhouse -
>>> >>>> JSF Consulting, Development and
>>> >>>> Courses in English and German
>>> >>>>
>>> >>>> Professional Support for Apache MyFaces
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>
>
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
Or we provide this additional component/tweak the existing
stylesheet-component to provide such a feature optionally. Better have
a way of doing this that requires customization than not having a way
of doing this at all, right?
regards,
Martin
On 7/30/07, Scott O'Bryan <da...@gmail.com> wrote:
> It's possible, but Portlet events won't be available until JSR-286. And
> although I've seen some of the AJAX support for 286, I'm not sure what
> the eventing model will and will not support. So either way, we'll need
> to revisit this I think when 286 comes out. For now we're probably
> stuck with the simple styling.
>
> Simon Lessard wrote:
> > Ok, I'm really getting out of ideas here... But here's another attempt
> >
> > Couldn't we use the portlet message event model for that ? If all
> > portlets broadcast a message event containing their stylesheet (yeah,
> > it will be ugly on the network latency...) then the first Trinidad
> > portlet that catch those messages get in charge of rendering the
> > styles and warn the other portlets that it's going to be by
> > broadcasting yet another message (dunno if you can broadcast from an
> > event listener though... I have yet to read most of the spec on
> > portlet events)...
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 7/30/07, *Scott O'Bryan* <darkarena@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Oops. Submitted before I was done.
> >
> > Currently Trinidad supports the ability to turn off stylesheets,
> > it also
> > supports the ability to force a certain skin to render. Making is so
> > that the stylesheet only loads once, however, is not trivial and
> > since
> > skinning extensions are currently combined into a single style sheet,
> > the first portlet and/or the portal container would need to make sure
> > those skinning extensions are installed as well.
> >
> > Scott
> >
> > Scott O'Bryan wrote:
> > > This won't work in WSRP Portal environments that may use distributed
> > > portlets. This is because the portlets may exist on different
> > > servers. Furthermore different portlets may have different
> > skinning
> > > extensions. This will hose the styling if a portlet with no
> > skinning
> > > extensions gets added before portlets WITH skinning extensions. The
> > > skinning extensions will not be available
> > >
> > >
> > > Martin Marinschek wrote:
> > >> Sure, this would work.
> > >>
> > >> Everyone agreeing we should do it this way?
> > >>
> > >> regards,
> > >>
> > >> Martin
> > >>
> > >> On 7/28/07, Simon Lessard < simon.lessard.3@gmail.com
> > <ma...@gmail.com>> wrote:
> > >>
> > >>> Yeah, that would imply every single renderers. In a non-portlet
> > >>> environment
> > >>> the performance hit would not be big though as it would only
> > be on
> > >>> method
> > >>> call and checking if we run in a portlet environment would not
> > be an
> > >>> expensive operation compared to the overall job done by renderers.
> > >>> However
> > >>> in the portlet environment, it would be a tad more...
> > >>>
> > >>> What about a ResponseWriter decorator applied by the renderkit
> > if it
> > >>> get
> > >>> called by a portlet environment? The decorator could inject the
> > >>> JavaScript
> > >>> style copy just before the first non <html>, <head> or <body>
> > >>> element then
> > >>> set a boolean flag to false to inhibit itself. The overhaul would
> > >>> then be a
> > >>> single if evaluation per startElement. It would be called
> > often, but
> > >>> a if
> > >>> with a boolean flag get evaluated in 2 ticks, which is nothing
> > for all
> > >>> practical purposes.
> > >>>
> > >>>
> > >>> On 7/28/07, Martin Marinschek <martin.marinschek@gmail.com
> > <ma...@gmail.com>> wrote:
> > >>>
> > >>>> But you'd need to do this check in every renderer then, right? I
> > >>>> wonder if this is good performance wise.
> > >>>>
> > >>>> regards,
> > >>>>
> > >>>> Martin
> > >>>>
> > >>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
> > <ma...@gmail.com>> wrote:
> > >>>>
> > >>>>> One way would be to have something along those line:
> > >>>>>
> > >>>>> CoreRenderer.java
> > >>>>>
> > >>>>> public void encodeBegin(FacesContext context, UIComponent
> > component)
> > >>>>> {
> > >>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
> > >>>>>
> > >>> !isStyleSheetCopied())
> > >>>
> > >>>>> {
> > >>>>> pushStyleSheet(context);
> > >>>>> }
> > >>>>>
> > >>>>> // Do normal processing
> > >>>>> }
> > >>>>>
> > >>>>> protected abstract boolean isXhtmlRootElement();
> > >>>>>
> > >>>>> Then we would simply have to make isXhtmlRootElement()
> > return true
> > >>>>> for
> > >>>>> document, head and body renderers and false for the others. But
> > >>>>> it's not
> > >>>>> extremely clean.
> > >>>>>
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> ~ Simon
> > >>>>>
> > >>>>>
> > >>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com
> > <ma...@gmail.com>> wrote:
> > >>>>>
> > >>>>>> Sure, it would be better for the user if it works out of
> > the box.
> > >>>>>>
> > >>>>>> As much as I think, I don't find a central place where to
> > put it,
> > >>>>>>
> > >>> though.
> > >>>
> > >>>>>> Ideas anyone?
> > >>>>>>
> > >>>>>> regards,
> > >>>>>>
> > >>>>>> Martin
> > >>>>>>
> > >>>>>> On 7/27/07, Simon Lessard <simon.lessard.3@gmail.com
> > <ma...@gmail.com>> wrote:
> > >>>>>>
> > >>>>>>> Hello Martin,
> > >>>>>>>
> > >>>>>>> Yeah I thought about a new component and we actually
> > already have
> > >>>>>>> <trh:styleSheet/> that could be slightly altered to do
> > that work,
> > >>>>>>>
> > >>> but I
> > >>>
> > >>>>>>> would prefer a way not involving any action from users.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 7/27/07, Martin Marinschek <
> > martin.marinschek@gmail.com <ma...@gmail.com>>
> > wrote:
> > >>>>>>>
> > >>>>>>>> Hi Simon,
> > >>>>>>>>
> > >>>>>>>> true. The form-render was good for my nice small example,
> > but is
> > >>>>>>>>
> > >>> no
> > >>>
> > >>>>>>>> general solution of course.
> > >>>>>>>>
> > >>>>>>>> I wonder if this would mandate a special component which does
> > >>>>>>>>
> > >>> nothing
> > >>>
> > >>>>>>>> but adding the stylesheet to the head?
> > >>>>>>>>
> > >>>>>>>> Eventually, the component could be generalized, so that
> > all kinds
> > >>>>>>>>
> > >>> of
> > >>>
> > >>>>>>>> stylesheets can be added, if a link is provided and the
> > stylesheet
> > >>>>>>>> hasn't been added so far - I think this solution might be
> > >>>>>>>>
> > >>> interesting
> > >>>
> > >>>>>>>> for the portlet-developer in general.
> > >>>>>>>>
> > >>>>>>>> regards,
> > >>>>>>>>
> > >>>>>>>> Martin
> > >>>>>>>>
> > >>>>>>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
> > <ma...@gmail.com>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Issue with #3 is not very hard, we already have a
> > >>>>>>>>>
> > >>> RenderingContext
> > >>>
> > >>>>> that
> > >>>>>
> > >>>>>>> can
> > >>>>>>>
> > >>>>>>>>> be used for that. We could probably hook that code in
> > >>>>>>>>>
> > >>> CoreRenderer
> > >>>
> > >>>>> or
> > >>>>>
> > >>>>>>>>> XhtmlRenderer. The only issue left then would be to not
> > have
> > >>>>>>>>>
> > >>>>> document,
> > >>>>>
> > >>>>>>> head
> > >>>>>>>
> > >>>>>>>>> and body renderer to execute it. Placing it in
> > FormRenderer only
> > >>>>>>>>>
> > >>>>> does
> > >>>>>
> > >>>>>>> not
> > >>>>>>>
> > >>>>>>>>> seems right in case your page does not contain a form at
> > all or
> > >>>>>>>>>
> > >>> use
> > >>>
> > >>>>> a
> > >>>>>
> > >>>>>>> basic
> > >>>>>>>
> > >>>>>>>>> JSF form (extremely unlikely though).
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On 7/27/07, Martin Marinschek <
> > martin.marinschek@gmail.com <ma...@gmail.com>>
> > >>>>>>>>>
> > >>> wrote:
> > >>>
> > >>>>>>>>>> For the discussion on if and how to integrate this into
> > >>>>>>>>>>
> > >>> Trinidad -
> > >>>
> > >>>>> I
> > >>>>>
> > >>>>>>>>>> see three cases:
> > >>>>>>>>>>
> > >>>>>>>>>> 1) people only want basic skinning, Trinidad uses
> > >>>>>>>>>>
> > >>> simple.portlet,
> > >>>
> > >>>>> and
> > >>>>>
> > >>>>>>>>>> emits portlet-standard compliant skinning hooks
> > >>>>>>>>>>
> > >>>>>>>>>> 2) people want normal Trinidad skinning, portlet container
> > >>>>>>>>>>
> > >>>>> provides
> > >>>>>
> > >>>>>>>>>> CSS file in the head, Trinidad doesn't have to do anything
> > >>>>>>>>>>
> > >>>>> (especially
> > >>>>>
> > >>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
> > >>>>>>>>>>
> > >>>>>>>>>> 3) people want Trinidad skinning, portlet container
> > does not
> > >>>>>>>>>>
> > >>>>> provide
> > >>>>>
> > >>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS
> > file with
> > >>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to be
> > added
> > >>>>>>>>>>
> > >>> only
> > >>>
> > >>>>>>>>>> once.
> > >>>>>>>>>>
> > >>>>>>>>>> regards,
> > >>>>>>>>>>
> > >>>>>>>>>> Martin
> > >>>>>>>>>>
> > >>>>>>>>>> On 7/27/07, Martin Marinschek <
> > martin.marinschek@gmail.com <ma...@gmail.com> >
> > >>>>>>>>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>>>>>>> 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/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > <ma...@gmail.com>>
> > >>>>>>>>>>>
> > >>> wrote:
> > >>>
> > >>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
> > >>>>>>>>>>>>
> > >>>>> vendor(s)...
> > >>>>>
> > >>>>>>> Ok,
> > >>>>>>>
> > >>>>>>>>> I see
> > >>>>>>>>>
> > >>>>>>>>>>>> the issue now... bleh...
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> > <ma...@gmail.com> > wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Simon, you are correct. The portal would be able to
> > >>>>>>>>>>>>>
> > >>> push a
> > >>>
> > >>>>>>>>> parameter to
> > >>>>>>>>>
> > >>>>>>>>>>>>> Trinidad. Always in a portal environment the skin is
> > >>>>>>>>>>>>>
> > >>>>>>> uncompressed
> > >>>>>>>
> > >>>>>>>>> so
> > >>>>>>>>>
> > >>>>>>>>>>>>> that is also not an issue. But currently changing the
> > >>>>>>>>>>>>>
> > >>>>>>> stylesheet
> > >>>>>>>
> > >>>>>>>>>>>>> provided by the Portal is a modification that needs to
> > >>>>>>>>>>>>>
> > >>> be
> > >>>
> > >>>>> made
> > >>>>>
> > >>>>>>> to
> > >>>>>>>
> > >>>>>>>>> the
> > >>>>>>>>>
> > >>>>>>>>>>>>> portal itself. I think that's where Martin is coming
> > >>>>>>>>>>>>>
> > >>> from.
> > >>>
> > >>>>> An
> > >>>>>
> > >>>>>>>>>>>>> unmodified portal container doesn't look very good when
> > >>>>>>>>>>>>>
> > >>>>>>> displaying
> > >>>>>>>
> > >>>>>>>>> faces
> > >>>>>>>>>
> > >>>>>>>>>>>>> and forcing every portal container to provide a skin
> > >>>>>>>>>>>>>
> > >>> that is
> > >>>
> > >>>>> not
> > >>>>>
> > >>>>>>>>> based
> > >>>>>>>>>
> > >>>>>>>>>>>>> off a standard is not going to be very successful in the
> > >>>>>>>>>>>>>
> > >>>>> general
> > >>>>>
> > >>>>>>>>> case.
> > >>>>>>>>>
> > >>>>>>>>>>>>> I totally agree with this, but we're sort of between a
> > >>>>>>>>>>>>>
> > >>> rock
> > >>>
> > >>>>> and
> > >>>>>
> > >>>>>>> a
> > >>>>>>>
> > >>>>>>>>> hard
> > >>>>>>>>>
> > >>>>>>>>>>>>> place. :)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Simon Lessard wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Not really, I think we detect a specific parameter
> > >>>>>>>>>>>>>>
> > >>> pushed
> > >>>
> > >>>>> by
> > >>>>>
> > >>>>>>> the
> > >>>>>>>
> > >>>>>>>>>>>>>> container. So only container supporting skinning would
> > >>>>>>>>>>>>>>
> > >>>>> push
> > >>>>>
> > >>>>>>> it,
> > >>>>>>>
> > >>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For other
> > >>>>>>>>>>>>>>
> > >>>>> container
> > >>>>>
> > >>>>>>> I
> > >>>>>>>
> > >>>>>>>>> think
> > >>>>>>>>>
> > >>>>>>>>>>>>>> we simply use the normal code path... That or I had
> > >>>>>>>>>>>>>>
> > >>> some
> > >>>
> > >>>>>>> serious
> > >>>>>>>
> > >>>>>>>>>>>>>> hallucinations in the past months and imagined all
> > >>>>>>>>>>>>>>
> > >>> this...
> > >>>
> > >>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
> > >>>>>>>>>>>>>>
> > >>>>> martin.marinschek@gmail.com <ma...@gmail.com>
> > >>>>>
> > >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
> > <ma...@gmail.com> >> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi Simon,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> well, but this would then be portlet container
> > >>>>>>>>>>>>>>
> > >>>>> dependent,
> > >>>>>
> > >>>>>>>>> right?
> > >>>>>>>>>
> > >>>>>>>>>>>> You'd
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> effectively need to implement trinidad skinning in
> > >>>>>>>>>>>>>>
> > >>>>> every
> > >>>>>
> > >>>>>>>>> portlet
> > >>>>>>>>>
> > >>>>>>>>>>>>>> container.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> regards,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Martin
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
> > >>>>>>>>>>>>>>
> > >>> simon.lessard.3@gmail.com <ma...@gmail.com>
> > >>>
> > >>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com
> > <ma...@gmail.com>>> wrote:
> > >>>>>>>>>>>>>> > Personally, I don't see why the portal should
> > >>>>>>>>>>>>>>
> > >>> not be
> > >>>
> > >>>>>>> able to
> > >>>>>>>
> > >>>>>>>>>>>>>> provide all
> > >>>>>>>>>>>>>> > selectors.
> > >>>>>>>>>>>>>> >
> > >>>>>>>>>>>>>> > Aren't we just not compressing the selector
> > >>>>>>>>>>>>>>
> > >>> names
> > >>>
> > >>>>> when
> > >>>>>
> > >>>>>>> we
> > >>>>>>>
> > >>>>>>>>> detect
> > >>>>>>>>>
> > >>>>>>>>>>>>>> a portal
> > >>>>>>>>>>>>>> > environment or did I miss something? I think
> > >>>>>>>>>>>>>>
> > >>> that
> > >>>
> > >>>>>>> strategy
> > >>>>>>>
> > >>>>>>>>>>>>>> cannot provides
> > >>>>>>>>>>>>>> > the icons though.
> > >>>>>>>>>>>>>> >
> > >>>>>>>>>>>>>> >
> > >>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
> > >>>>>>>>>>>>>>
> > >>>>>>> martin.marinschek@gmail.com
> > <ma...@gmail.com>
> > >>>>>>>
> > >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
> > <ma...@gmail.com> >> wrote:
> > >>>>>>>>>>>>>> > > Does the portlet container really provide
> > >>>>>>>>>>>>>>
> > >>> every
> > >>>
> > >>>>>>> styleclass
> > >>>>>>>
> > >>>>>>>>> that
> > >>>>>>>>>
> > >>>>>>>>>>>> is
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> > > necessary for Trinidad components to look like
> > >>>>>>>>>>>>>>
> > >>>>> they
> > >>>>>
> > >>>>>>>>> normally
> > >>>>>>>>>
> > >>>>>>>>>>>> look?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > I'm just thinking that what is currently being
> > >>>>>>>>>>>>>>
> > >>>>> done is
> > >>>>>
> > >>>>>>> not
> > >>>>>>>
> > >>>>>>>>>>>>>> enough to
> > >>>>>>>>>>>>>> > > have the full skinning features available, and
> > >>>>>>>>>>>>>>
> > >>>>> that
> > >>>>>
> > >>>>>>> going
> > >>>>>>>
> > >>>>>>>>> the
> > >>>>>>>>>
> > >>>>>>>>>>>>>> > > direction of adding the CSS dynamically would
> > >>>>>>>>>>>>>>
> > >>>>> allow to
> > >>>>>
> > >>>>>>> do
> > >>>>>>>
> > >>>>>>>>> so.
> > >>>>>>>>>
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > regards,
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > Martin
> > >>>>>>>>>>>>>> > >
> > >>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
> > >>>>>>>>>>>>>>
> > >>> darkarena@gmail.com <ma...@gmail.com>
> > >>>
> > >>>>>>>>>>>>>> <mailto: darkarena@gmail.com
> > <ma...@gmail.com>>> wrote:
> > >>>>>>>>>>>>>> > > > Hey Martin,
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
> > >>>>>>>>>>>>>>
> > >>> better?
> > >>>
> > >>>>> I
> > >>>>>
> > >>>>>>>>> *THINK*
> > >>>>>>>>>
> > >>>>>>>>>>>>>> that when
> > >>>>>>>>>>>>>> > > > running in a portal environment you always
> > >>>>>>>>>>>>>>
> > >>> get
> > >>>
> > >>>>> the
> > >>>>>
> > >>>>>>>>>>>>>> simple-portlet skin
> > >>>>>>>>>>>>>> > > > unless your portal provides one of the
> > >>>>>>>>>>>>>>
> > >>> necessary
> > >>>
> > >>>>>>> skin
> > >>>>>>>
> > >>>>>>>>>>>>>> extensions which,
> > >>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
> > >>>>>>>>>>>>>>
> > >>> this
> > >>>
> > >>>>> is
> > >>>>>
> > >>>>>>> just
> > >>>>>>>
> > >>>>>>>>> a
> > >>>>>>>>>
> > >>>>>>>>>>>>>> case of us
> > >>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > That article is interesting, but I think
> > >>>>>>>>>>>>>>
> > >>> that
> > >>>
> > >>>>>>> Trinidad
> > >>>>>>>
> > >>>>>>>>> has
> > >>>>>>>>>
> > >>>>>>>>>>>>>> attempted to
> > >>>>>>>>>>>>>> > > > do the same thing only in a different way.
> > >>>>>>>>>>>>>>
> > >>>>> Instead
> > >>>>>
> > >>>>>>> of
> > >>>>>>>
> > >>>>>>>>> using
> > >>>>>>>>>
> > >>>>>>>>>>>>>> javascript
> > >>>>>>>>>>>>>> > > > to copy in the styles, we actually change
> > >>>>>>>>>>>>>>
> > >>> the
> > >>>
> > >>>>> class
> > >>>>>
> > >>>>>>>>> names
> > >>>>>>>>>
> > >>>>>>>>>>>>>> that get
> > >>>>>>>>>>>>>> > > > rendered on the client to use the portal
> > >>>>>>>>>>>>>>
> > >>> styles
> > >>>
> > >>>>>>> where
> > >>>>>>>
> > >>>>>>>>>>>>>> appropriate.
> > >>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
> > >>>>>>>>>>>>>>
> > >>> tested
> > >>>
> > >>>>>>>>> extensively
> > >>>>>>>>>
> > >>>>>>>>>>>>>> because before
> > >>>>>>>>>>>>>> > > > we started looking at 301, much of
> > >>>>>>>>>>>>>>
> > >>> Trinidad's
> > >>>
> > >>>>> portal
> > >>>>>
> > >>>>>>>>> work
> > >>>>>>>>>
> > >>>>>>>>>>>>>> has been done
> > >>>>>>>>>>>>>> > > > with a Proof of Concept environment.
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > Scott
> > >>>>>>>>>>>>>> > > >
> > >>>>>>>>>>>>>> > > > 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
> > >>>
> > >>>>>>>>>>>> <
> > >>>>>>>>>>>>
> > >>> 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
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>>
> > >>>>>>>>>> http://www.irian.at <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
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>> --
> > >>>>
> > >>>> 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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
It's possible, but Portlet events won't be available until JSR-286. And
although I've seen some of the AJAX support for 286, I'm not sure what
the eventing model will and will not support. So either way, we'll need
to revisit this I think when 286 comes out. For now we're probably
stuck with the simple styling.
Simon Lessard wrote:
> Ok, I'm really getting out of ideas here... But here's another attempt
>
> Couldn't we use the portlet message event model for that ? If all
> portlets broadcast a message event containing their stylesheet (yeah,
> it will be ugly on the network latency...) then the first Trinidad
> portlet that catch those messages get in charge of rendering the
> styles and warn the other portlets that it's going to be by
> broadcasting yet another message (dunno if you can broadcast from an
> event listener though... I have yet to read most of the spec on
> portlet events)...
>
>
> Regards,
>
> ~ Simon
>
> On 7/30/07, *Scott O'Bryan* <darkarena@gmail.com
> <ma...@gmail.com>> wrote:
>
> Oops. Submitted before I was done.
>
> Currently Trinidad supports the ability to turn off stylesheets,
> it also
> supports the ability to force a certain skin to render. Making is so
> that the stylesheet only loads once, however, is not trivial and
> since
> skinning extensions are currently combined into a single style sheet,
> the first portlet and/or the portal container would need to make sure
> those skinning extensions are installed as well.
>
> Scott
>
> Scott O'Bryan wrote:
> > This won't work in WSRP Portal environments that may use distributed
> > portlets. This is because the portlets may exist on different
> > servers. Furthermore different portlets may have different
> skinning
> > extensions. This will hose the styling if a portlet with no
> skinning
> > extensions gets added before portlets WITH skinning extensions. The
> > skinning extensions will not be available
> >
> >
> > Martin Marinschek wrote:
> >> Sure, this would work.
> >>
> >> Everyone agreeing we should do it this way?
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 7/28/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>
> >>> Yeah, that would imply every single renderers. In a non-portlet
> >>> environment
> >>> the performance hit would not be big though as it would only
> be on
> >>> method
> >>> call and checking if we run in a portlet environment would not
> be an
> >>> expensive operation compared to the overall job done by renderers.
> >>> However
> >>> in the portlet environment, it would be a tad more...
> >>>
> >>> What about a ResponseWriter decorator applied by the renderkit
> if it
> >>> get
> >>> called by a portlet environment? The decorator could inject the
> >>> JavaScript
> >>> style copy just before the first non <html>, <head> or <body>
> >>> element then
> >>> set a boolean flag to false to inhibit itself. The overhaul would
> >>> then be a
> >>> single if evaluation per startElement. It would be called
> often, but
> >>> a if
> >>> with a boolean flag get evaluated in 2 ticks, which is nothing
> for all
> >>> practical purposes.
> >>>
> >>>
> >>> On 7/28/07, Martin Marinschek <martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
> >>>
> >>>> But you'd need to do this check in every renderer then, right? I
> >>>> wonder if this is good performance wise.
> >>>>
> >>>> regards,
> >>>>
> >>>> Martin
> >>>>
> >>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>
> >>>>> One way would be to have something along those line:
> >>>>>
> >>>>> CoreRenderer.java
> >>>>>
> >>>>> public void encodeBegin(FacesContext context, UIComponent
> component)
> >>>>> {
> >>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
> >>>>>
> >>> !isStyleSheetCopied())
> >>>
> >>>>> {
> >>>>> pushStyleSheet(context);
> >>>>> }
> >>>>>
> >>>>> // Do normal processing
> >>>>> }
> >>>>>
> >>>>> protected abstract boolean isXhtmlRootElement();
> >>>>>
> >>>>> Then we would simply have to make isXhtmlRootElement()
> return true
> >>>>> for
> >>>>> document, head and body renderers and false for the others. But
> >>>>> it's not
> >>>>> extremely clean.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> ~ Simon
> >>>>>
> >>>>>
> >>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>
> >>>>>> Sure, it would be better for the user if it works out of
> the box.
> >>>>>>
> >>>>>> As much as I think, I don't find a central place where to
> put it,
> >>>>>>
> >>> though.
> >>>
> >>>>>> Ideas anyone?
> >>>>>>
> >>>>>> regards,
> >>>>>>
> >>>>>> Martin
> >>>>>>
> >>>>>> On 7/27/07, Simon Lessard <simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>>
> >>>>>>> Hello Martin,
> >>>>>>>
> >>>>>>> Yeah I thought about a new component and we actually
> already have
> >>>>>>> <trh:styleSheet/> that could be slightly altered to do
> that work,
> >>>>>>>
> >>> but I
> >>>
> >>>>>>> would prefer a way not involving any action from users.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 7/27/07, Martin Marinschek <
> martin.marinschek@gmail.com <ma...@gmail.com>>
> wrote:
> >>>>>>>
> >>>>>>>> Hi Simon,
> >>>>>>>>
> >>>>>>>> true. The form-render was good for my nice small example,
> but is
> >>>>>>>>
> >>> no
> >>>
> >>>>>>>> general solution of course.
> >>>>>>>>
> >>>>>>>> I wonder if this would mandate a special component which does
> >>>>>>>>
> >>> nothing
> >>>
> >>>>>>>> but adding the stylesheet to the head?
> >>>>>>>>
> >>>>>>>> Eventually, the component could be generalized, so that
> all kinds
> >>>>>>>>
> >>> of
> >>>
> >>>>>>>> stylesheets can be added, if a link is provided and the
> stylesheet
> >>>>>>>> hasn't been added so far - I think this solution might be
> >>>>>>>>
> >>> interesting
> >>>
> >>>>>>>> for the portlet-developer in general.
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>>
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>>>>
> >>>>>>>>> Issue with #3 is not very hard, we already have a
> >>>>>>>>>
> >>> RenderingContext
> >>>
> >>>>> that
> >>>>>
> >>>>>>> can
> >>>>>>>
> >>>>>>>>> be used for that. We could probably hook that code in
> >>>>>>>>>
> >>> CoreRenderer
> >>>
> >>>>> or
> >>>>>
> >>>>>>>>> XhtmlRenderer. The only issue left then would be to not
> have
> >>>>>>>>>
> >>>>> document,
> >>>>>
> >>>>>>> head
> >>>>>>>
> >>>>>>>>> and body renderer to execute it. Placing it in
> FormRenderer only
> >>>>>>>>>
> >>>>> does
> >>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>>> seems right in case your page does not contain a form at
> all or
> >>>>>>>>>
> >>> use
> >>>
> >>>>> a
> >>>>>
> >>>>>>> basic
> >>>>>>>
> >>>>>>>>> JSF form (extremely unlikely though).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 7/27/07, Martin Marinschek <
> martin.marinschek@gmail.com <ma...@gmail.com>>
> >>>>>>>>>
> >>> wrote:
> >>>
> >>>>>>>>>> For the discussion on if and how to integrate this into
> >>>>>>>>>>
> >>> Trinidad -
> >>>
> >>>>> I
> >>>>>
> >>>>>>>>>> see three cases:
> >>>>>>>>>>
> >>>>>>>>>> 1) people only want basic skinning, Trinidad uses
> >>>>>>>>>>
> >>> simple.portlet,
> >>>
> >>>>> and
> >>>>>
> >>>>>>>>>> emits portlet-standard compliant skinning hooks
> >>>>>>>>>>
> >>>>>>>>>> 2) people want normal Trinidad skinning, portlet container
> >>>>>>>>>>
> >>>>> provides
> >>>>>
> >>>>>>>>>> CSS file in the head, Trinidad doesn't have to do anything
> >>>>>>>>>>
> >>>>> (especially
> >>>>>
> >>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
> >>>>>>>>>>
> >>>>>>>>>> 3) people want Trinidad skinning, portlet container
> does not
> >>>>>>>>>>
> >>>>> provide
> >>>>>
> >>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS
> file with
> >>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to be
> added
> >>>>>>>>>>
> >>> only
> >>>
> >>>>>>>>>> once.
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>>
> >>>>>>>>>> Martin
> >>>>>>>>>>
> >>>>>>>>>> On 7/27/07, Martin Marinschek <
> martin.marinschek@gmail.com <ma...@gmail.com> >
> >>>>>>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>>>>>>> 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/26/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>>
> >>>>>>>>>>>
> >>> wrote:
> >>>
> >>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
> >>>>>>>>>>>>
> >>>>> vendor(s)...
> >>>>>
> >>>>>>> Ok,
> >>>>>>>
> >>>>>>>>> I see
> >>>>>>>>>
> >>>>>>>>>>>> the issue now... bleh...
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> <ma...@gmail.com> > wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Simon, you are correct. The portal would be able to
> >>>>>>>>>>>>>
> >>> push a
> >>>
> >>>>>>>>> parameter to
> >>>>>>>>>
> >>>>>>>>>>>>> Trinidad. Always in a portal environment the skin is
> >>>>>>>>>>>>>
> >>>>>>> uncompressed
> >>>>>>>
> >>>>>>>>> so
> >>>>>>>>>
> >>>>>>>>>>>>> that is also not an issue. But currently changing the
> >>>>>>>>>>>>>
> >>>>>>> stylesheet
> >>>>>>>
> >>>>>>>>>>>>> provided by the Portal is a modification that needs to
> >>>>>>>>>>>>>
> >>> be
> >>>
> >>>>> made
> >>>>>
> >>>>>>> to
> >>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>>>>>> portal itself. I think that's where Martin is coming
> >>>>>>>>>>>>>
> >>> from.
> >>>
> >>>>> An
> >>>>>
> >>>>>>>>>>>>> unmodified portal container doesn't look very good when
> >>>>>>>>>>>>>
> >>>>>>> displaying
> >>>>>>>
> >>>>>>>>> faces
> >>>>>>>>>
> >>>>>>>>>>>>> and forcing every portal container to provide a skin
> >>>>>>>>>>>>>
> >>> that is
> >>>
> >>>>> not
> >>>>>
> >>>>>>>>> based
> >>>>>>>>>
> >>>>>>>>>>>>> off a standard is not going to be very successful in the
> >>>>>>>>>>>>>
> >>>>> general
> >>>>>
> >>>>>>>>> case.
> >>>>>>>>>
> >>>>>>>>>>>>> I totally agree with this, but we're sort of between a
> >>>>>>>>>>>>>
> >>> rock
> >>>
> >>>>> and
> >>>>>
> >>>>>>> a
> >>>>>>>
> >>>>>>>>> hard
> >>>>>>>>>
> >>>>>>>>>>>>> place. :)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Simon Lessard wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Not really, I think we detect a specific parameter
> >>>>>>>>>>>>>>
> >>> pushed
> >>>
> >>>>> by
> >>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>>>>>>>> container. So only container supporting skinning would
> >>>>>>>>>>>>>>
> >>>>> push
> >>>>>
> >>>>>>> it,
> >>>>>>>
> >>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For other
> >>>>>>>>>>>>>>
> >>>>> container
> >>>>>
> >>>>>>> I
> >>>>>>>
> >>>>>>>>> think
> >>>>>>>>>
> >>>>>>>>>>>>>> we simply use the normal code path... That or I had
> >>>>>>>>>>>>>>
> >>> some
> >>>
> >>>>>>> serious
> >>>>>>>
> >>>>>>>>>>>>>> hallucinations in the past months and imagined all
> >>>>>>>>>>>>>>
> >>> this...
> >>>
> >>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
> >>>>>>>>>>>>>>
> >>>>> martin.marinschek@gmail.com <ma...@gmail.com>
> >>>>>
> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
> <ma...@gmail.com> >> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Simon,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> well, but this would then be portlet container
> >>>>>>>>>>>>>>
> >>>>> dependent,
> >>>>>
> >>>>>>>>> right?
> >>>>>>>>>
> >>>>>>>>>>>> You'd
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> effectively need to implement trinidad skinning in
> >>>>>>>>>>>>>>
> >>>>> every
> >>>>>
> >>>>>>>>> portlet
> >>>>>>>>>
> >>>>>>>>>>>>>> container.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Martin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
> >>>>>>>>>>>>>>
> >>> simon.lessard.3@gmail.com <ma...@gmail.com>
> >>>
> >>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com
> <ma...@gmail.com>>> wrote:
> >>>>>>>>>>>>>> > Personally, I don't see why the portal should
> >>>>>>>>>>>>>>
> >>> not be
> >>>
> >>>>>>> able to
> >>>>>>>
> >>>>>>>>>>>>>> provide all
> >>>>>>>>>>>>>> > selectors.
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> > Aren't we just not compressing the selector
> >>>>>>>>>>>>>>
> >>> names
> >>>
> >>>>> when
> >>>>>
> >>>>>>> we
> >>>>>>>
> >>>>>>>>> detect
> >>>>>>>>>
> >>>>>>>>>>>>>> a portal
> >>>>>>>>>>>>>> > environment or did I miss something? I think
> >>>>>>>>>>>>>>
> >>> that
> >>>
> >>>>>>> strategy
> >>>>>>>
> >>>>>>>>>>>>>> cannot provides
> >>>>>>>>>>>>>> > the icons though.
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
> >>>>>>>>>>>>>>
> >>>>>>> martin.marinschek@gmail.com
> <ma...@gmail.com>
> >>>>>>>
> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com
> <ma...@gmail.com> >> wrote:
> >>>>>>>>>>>>>> > > Does the portlet container really provide
> >>>>>>>>>>>>>>
> >>> every
> >>>
> >>>>>>> styleclass
> >>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>>>>> is
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> > > necessary for Trinidad components to look like
> >>>>>>>>>>>>>>
> >>>>> they
> >>>>>
> >>>>>>>>> normally
> >>>>>>>>>
> >>>>>>>>>>>> look?
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > I'm just thinking that what is currently being
> >>>>>>>>>>>>>>
> >>>>> done is
> >>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>>>>>>>> enough to
> >>>>>>>>>>>>>> > > have the full skinning features available, and
> >>>>>>>>>>>>>>
> >>>>> that
> >>>>>
> >>>>>>> going
> >>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>>>>>>> > > direction of adding the CSS dynamically would
> >>>>>>>>>>>>>>
> >>>>> allow to
> >>>>>
> >>>>>>> do
> >>>>>>>
> >>>>>>>>> so.
> >>>>>>>>>
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > regards,
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > Martin
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
> >>>>>>>>>>>>>>
> >>> darkarena@gmail.com <ma...@gmail.com>
> >>>
> >>>>>>>>>>>>>> <mailto: darkarena@gmail.com
> <ma...@gmail.com>>> wrote:
> >>>>>>>>>>>>>> > > > Hey Martin,
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
> >>>>>>>>>>>>>>
> >>> better?
> >>>
> >>>>> I
> >>>>>
> >>>>>>>>> *THINK*
> >>>>>>>>>
> >>>>>>>>>>>>>> that when
> >>>>>>>>>>>>>> > > > running in a portal environment you always
> >>>>>>>>>>>>>>
> >>> get
> >>>
> >>>>> the
> >>>>>
> >>>>>>>>>>>>>> simple-portlet skin
> >>>>>>>>>>>>>> > > > unless your portal provides one of the
> >>>>>>>>>>>>>>
> >>> necessary
> >>>
> >>>>>>> skin
> >>>>>>>
> >>>>>>>>>>>>>> extensions which,
> >>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
> >>>>>>>>>>>>>>
> >>> this
> >>>
> >>>>> is
> >>>>>
> >>>>>>> just
> >>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>>>>>>> case of us
> >>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > That article is interesting, but I think
> >>>>>>>>>>>>>>
> >>> that
> >>>
> >>>>>>> Trinidad
> >>>>>>>
> >>>>>>>>> has
> >>>>>>>>>
> >>>>>>>>>>>>>> attempted to
> >>>>>>>>>>>>>> > > > do the same thing only in a different way.
> >>>>>>>>>>>>>>
> >>>>> Instead
> >>>>>
> >>>>>>> of
> >>>>>>>
> >>>>>>>>> using
> >>>>>>>>>
> >>>>>>>>>>>>>> javascript
> >>>>>>>>>>>>>> > > > to copy in the styles, we actually change
> >>>>>>>>>>>>>>
> >>> the
> >>>
> >>>>> class
> >>>>>
> >>>>>>>>> names
> >>>>>>>>>
> >>>>>>>>>>>>>> that get
> >>>>>>>>>>>>>> > > > rendered on the client to use the portal
> >>>>>>>>>>>>>>
> >>> styles
> >>>
> >>>>>>> where
> >>>>>>>
> >>>>>>>>>>>>>> appropriate.
> >>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
> >>>>>>>>>>>>>>
> >>> tested
> >>>
> >>>>>>>>> extensively
> >>>>>>>>>
> >>>>>>>>>>>>>> because before
> >>>>>>>>>>>>>> > > > we started looking at 301, much of
> >>>>>>>>>>>>>>
> >>> Trinidad's
> >>>
> >>>>> portal
> >>>>>
> >>>>>>>>> work
> >>>>>>>>>
> >>>>>>>>>>>>>> has been done
> >>>>>>>>>>>>>> > > > with a Proof of Concept environment.
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > Scott
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > 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
> >>>
> >>>>>>>>>>>> <
> >>>>>>>>>>>>
> >>> 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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> http://www.irian.at <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
> >>>>>>
> >>>>>>
> >>>>>
> >>>> --
> >>>>
> >>>> http://www.irian.at
> >>>>
> >>>> Your JSF powerhouse -
> >>>> JSF Consulting, Development and
> >>>> Courses in English and German
> >>>>
> >>>> Professional Support for Apache MyFaces
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Ok, I'm really getting out of ideas here... But here's another attempt
Couldn't we use the portlet message event model for that ? If all portlets
broadcast a message event containing their stylesheet (yeah, it will be ugly
on the network latency...) then the first Trinidad portlet that catch those
messages get in charge of rendering the styles and warn the other portlets
that it's going to be by broadcasting yet another message (dunno if you can
broadcast from an event listener though... I have yet to read most of the
spec on portlet events)...
Regards,
~ Simon
On 7/30/07, Scott O'Bryan <da...@gmail.com> wrote:
>
> Oops. Submitted before I was done.
>
> Currently Trinidad supports the ability to turn off stylesheets, it also
> supports the ability to force a certain skin to render. Making is so
> that the stylesheet only loads once, however, is not trivial and since
> skinning extensions are currently combined into a single style sheet,
> the first portlet and/or the portal container would need to make sure
> those skinning extensions are installed as well.
>
> Scott
>
> Scott O'Bryan wrote:
> > This won't work in WSRP Portal environments that may use distributed
> > portlets. This is because the portlets may exist on different
> > servers. Furthermore different portlets may have different skinning
> > extensions. This will hose the styling if a portlet with no skinning
> > extensions gets added before portlets WITH skinning extensions. The
> > skinning extensions will not be available
> >
> >
> > Martin Marinschek wrote:
> >> Sure, this would work.
> >>
> >> Everyone agreeing we should do it this way?
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 7/28/07, Simon Lessard <si...@gmail.com> wrote:
> >>
> >>> Yeah, that would imply every single renderers. In a non-portlet
> >>> environment
> >>> the performance hit would not be big though as it would only be on
> >>> method
> >>> call and checking if we run in a portlet environment would not be an
> >>> expensive operation compared to the overall job done by renderers.
> >>> However
> >>> in the portlet environment, it would be a tad more...
> >>>
> >>> What about a ResponseWriter decorator applied by the renderkit if it
> >>> get
> >>> called by a portlet environment? The decorator could inject the
> >>> JavaScript
> >>> style copy just before the first non <html>, <head> or <body>
> >>> element then
> >>> set a boolean flag to false to inhibit itself. The overhaul would
> >>> then be a
> >>> single if evaluation per startElement. It would be called often, but
> >>> a if
> >>> with a boolean flag get evaluated in 2 ticks, which is nothing for all
> >>> practical purposes.
> >>>
> >>>
> >>> On 7/28/07, Martin Marinschek <ma...@gmail.com> wrote:
> >>>
> >>>> But you'd need to do this check in every renderer then, right? I
> >>>> wonder if this is good performance wise.
> >>>>
> >>>> regards,
> >>>>
> >>>> Martin
> >>>>
> >>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> >>>>
> >>>>> One way would be to have something along those line:
> >>>>>
> >>>>> CoreRenderer.java
> >>>>>
> >>>>> public void encodeBegin(FacesContext context, UIComponent
> component)
> >>>>> {
> >>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
> >>>>>
> >>> !isStyleSheetCopied())
> >>>
> >>>>> {
> >>>>> pushStyleSheet(context);
> >>>>> }
> >>>>>
> >>>>> // Do normal processing
> >>>>> }
> >>>>>
> >>>>> protected abstract boolean isXhtmlRootElement();
> >>>>>
> >>>>> Then we would simply have to make isXhtmlRootElement() return true
> >>>>> for
> >>>>> document, head and body renderers and false for the others. But
> >>>>> it's not
> >>>>> extremely clean.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> ~ Simon
> >>>>>
> >>>>>
> >>>>> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> >>>>>
> >>>>>> Sure, it would be better for the user if it works out of the box.
> >>>>>>
> >>>>>> As much as I think, I don't find a central place where to put it,
> >>>>>>
> >>> though.
> >>>
> >>>>>> Ideas anyone?
> >>>>>>
> >>>>>> regards,
> >>>>>>
> >>>>>> Martin
> >>>>>>
> >>>>>> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> >>>>>>
> >>>>>>> Hello Martin,
> >>>>>>>
> >>>>>>> Yeah I thought about a new component and we actually already have
> >>>>>>> <trh:styleSheet/> that could be slightly altered to do that work,
> >>>>>>>
> >>> but I
> >>>
> >>>>>>> would prefer a way not involving any action from users.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>>> Hi Simon,
> >>>>>>>>
> >>>>>>>> true. The form-render was good for my nice small example, but is
> >>>>>>>>
> >>> no
> >>>
> >>>>>>>> general solution of course.
> >>>>>>>>
> >>>>>>>> I wonder if this would mandate a special component which does
> >>>>>>>>
> >>> nothing
> >>>
> >>>>>>>> but adding the stylesheet to the head?
> >>>>>>>>
> >>>>>>>> Eventually, the component could be generalized, so that all kinds
> >>>>>>>>
> >>> of
> >>>
> >>>>>>>> stylesheets can be added, if a link is provided and the
> stylesheet
> >>>>>>>> hasn't been added so far - I think this solution might be
> >>>>>>>>
> >>> interesting
> >>>
> >>>>>>>> for the portlet-developer in general.
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>>
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Issue with #3 is not very hard, we already have a
> >>>>>>>>>
> >>> RenderingContext
> >>>
> >>>>> that
> >>>>>
> >>>>>>> can
> >>>>>>>
> >>>>>>>>> be used for that. We could probably hook that code in
> >>>>>>>>>
> >>> CoreRenderer
> >>>
> >>>>> or
> >>>>>
> >>>>>>>>> XhtmlRenderer. The only issue left then would be to not have
> >>>>>>>>>
> >>>>> document,
> >>>>>
> >>>>>>> head
> >>>>>>>
> >>>>>>>>> and body renderer to execute it. Placing it in FormRenderer only
> >>>>>>>>>
> >>>>> does
> >>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>>> seems right in case your page does not contain a form at all or
> >>>>>>>>>
> >>> use
> >>>
> >>>>> a
> >>>>>
> >>>>>>> basic
> >>>>>>>
> >>>>>>>>> JSF form (extremely unlikely though).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
> >>>>>>>>>
> >>> wrote:
> >>>
> >>>>>>>>>> For the discussion on if and how to integrate this into
> >>>>>>>>>>
> >>> Trinidad -
> >>>
> >>>>> I
> >>>>>
> >>>>>>>>>> see three cases:
> >>>>>>>>>>
> >>>>>>>>>> 1) people only want basic skinning, Trinidad uses
> >>>>>>>>>>
> >>> simple.portlet,
> >>>
> >>>>> and
> >>>>>
> >>>>>>>>>> emits portlet-standard compliant skinning hooks
> >>>>>>>>>>
> >>>>>>>>>> 2) people want normal Trinidad skinning, portlet container
> >>>>>>>>>>
> >>>>> provides
> >>>>>
> >>>>>>>>>> CSS file in the head, Trinidad doesn't have to do anything
> >>>>>>>>>>
> >>>>> (especially
> >>>>>
> >>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
> >>>>>>>>>>
> >>>>>>>>>> 3) people want Trinidad skinning, portlet container does not
> >>>>>>>>>>
> >>>>> provide
> >>>>>
> >>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS file with
> >>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to be added
> >>>>>>>>>>
> >>> only
> >>>
> >>>>>>>>>> once.
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>>
> >>>>>>>>>> Martin
> >>>>>>>>>>
> >>>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
> >>>>>>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>>>>>>> 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/26/07, Simon Lessard < simon.lessard.3@gmail.com>
> >>>>>>>>>>>
> >>> wrote:
> >>>
> >>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
> >>>>>>>>>>>>
> >>>>> vendor(s)...
> >>>>>
> >>>>>>> Ok,
> >>>>>>>
> >>>>>>>>> I see
> >>>>>>>>>
> >>>>>>>>>>>> the issue now... bleh...
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Simon, you are correct. The portal would be able to
> >>>>>>>>>>>>>
> >>> push a
> >>>
> >>>>>>>>> parameter to
> >>>>>>>>>
> >>>>>>>>>>>>> Trinidad. Always in a portal environment the skin is
> >>>>>>>>>>>>>
> >>>>>>> uncompressed
> >>>>>>>
> >>>>>>>>> so
> >>>>>>>>>
> >>>>>>>>>>>>> that is also not an issue. But currently changing the
> >>>>>>>>>>>>>
> >>>>>>> stylesheet
> >>>>>>>
> >>>>>>>>>>>>> provided by the Portal is a modification that needs to
> >>>>>>>>>>>>>
> >>> be
> >>>
> >>>>> made
> >>>>>
> >>>>>>> to
> >>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>>>>>> portal itself. I think that's where Martin is coming
> >>>>>>>>>>>>>
> >>> from.
> >>>
> >>>>> An
> >>>>>
> >>>>>>>>>>>>> unmodified portal container doesn't look very good when
> >>>>>>>>>>>>>
> >>>>>>> displaying
> >>>>>>>
> >>>>>>>>> faces
> >>>>>>>>>
> >>>>>>>>>>>>> and forcing every portal container to provide a skin
> >>>>>>>>>>>>>
> >>> that is
> >>>
> >>>>> not
> >>>>>
> >>>>>>>>> based
> >>>>>>>>>
> >>>>>>>>>>>>> off a standard is not going to be very successful in the
> >>>>>>>>>>>>>
> >>>>> general
> >>>>>
> >>>>>>>>> case.
> >>>>>>>>>
> >>>>>>>>>>>>> I totally agree with this, but we're sort of between a
> >>>>>>>>>>>>>
> >>> rock
> >>>
> >>>>> and
> >>>>>
> >>>>>>> a
> >>>>>>>
> >>>>>>>>> hard
> >>>>>>>>>
> >>>>>>>>>>>>> place. :)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Simon Lessard wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Not really, I think we detect a specific parameter
> >>>>>>>>>>>>>>
> >>> pushed
> >>>
> >>>>> by
> >>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>>>>>>>> container. So only container supporting skinning would
> >>>>>>>>>>>>>>
> >>>>> push
> >>>>>
> >>>>>>> it,
> >>>>>>>
> >>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For other
> >>>>>>>>>>>>>>
> >>>>> container
> >>>>>
> >>>>>>> I
> >>>>>>>
> >>>>>>>>> think
> >>>>>>>>>
> >>>>>>>>>>>>>> we simply use the normal code path... That or I had
> >>>>>>>>>>>>>>
> >>> some
> >>>
> >>>>>>> serious
> >>>>>>>
> >>>>>>>>>>>>>> hallucinations in the past months and imagined all
> >>>>>>>>>>>>>>
> >>> this...
> >>>
> >>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
> >>>>>>>>>>>>>>
> >>>>> martin.marinschek@gmail.com
> >>>>>
> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Simon,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> well, but this would then be portlet container
> >>>>>>>>>>>>>>
> >>>>> dependent,
> >>>>>
> >>>>>>>>> right?
> >>>>>>>>>
> >>>>>>>>>>>> You'd
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> effectively need to implement trinidad skinning in
> >>>>>>>>>>>>>>
> >>>>> every
> >>>>>
> >>>>>>>>> portlet
> >>>>>>>>>
> >>>>>>>>>>>>>> container.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> regards,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Martin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
> >>>>>>>>>>>>>>
> >>> simon.lessard.3@gmail.com
> >>>
> >>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com>> wrote:
> >>>>>>>>>>>>>> > Personally, I don't see why the portal should
> >>>>>>>>>>>>>>
> >>> not be
> >>>
> >>>>>>> able to
> >>>>>>>
> >>>>>>>>>>>>>> provide all
> >>>>>>>>>>>>>> > selectors.
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> > Aren't we just not compressing the selector
> >>>>>>>>>>>>>>
> >>> names
> >>>
> >>>>> when
> >>>>>
> >>>>>>> we
> >>>>>>>
> >>>>>>>>> detect
> >>>>>>>>>
> >>>>>>>>>>>>>> a portal
> >>>>>>>>>>>>>> > environment or did I miss something? I think
> >>>>>>>>>>>>>>
> >>> that
> >>>
> >>>>>>> strategy
> >>>>>>>
> >>>>>>>>>>>>>> cannot provides
> >>>>>>>>>>>>>> > the icons though.
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> >
> >>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
> >>>>>>>>>>>>>>
> >>>>>>> martin.marinschek@gmail.com
> >>>>>>>
> >>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
> >>>>>>>>>>>>>> > > Does the portlet container really provide
> >>>>>>>>>>>>>>
> >>> every
> >>>
> >>>>>>> styleclass
> >>>>>>>
> >>>>>>>>> that
> >>>>>>>>>
> >>>>>>>>>>>> is
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> > > necessary for Trinidad components to look like
> >>>>>>>>>>>>>>
> >>>>> they
> >>>>>
> >>>>>>>>> normally
> >>>>>>>>>
> >>>>>>>>>>>> look?
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > I'm just thinking that what is currently being
> >>>>>>>>>>>>>>
> >>>>> done is
> >>>>>
> >>>>>>> not
> >>>>>>>
> >>>>>>>>>>>>>> enough to
> >>>>>>>>>>>>>> > > have the full skinning features available, and
> >>>>>>>>>>>>>>
> >>>>> that
> >>>>>
> >>>>>>> going
> >>>>>>>
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>>>>>>>> > > direction of adding the CSS dynamically would
> >>>>>>>>>>>>>>
> >>>>> allow to
> >>>>>
> >>>>>>> do
> >>>>>>>
> >>>>>>>>> so.
> >>>>>>>>>
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > regards,
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > Martin
> >>>>>>>>>>>>>> > >
> >>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
> >>>>>>>>>>>>>>
> >>> darkarena@gmail.com
> >>>
> >>>>>>>>>>>>>> <mailto: darkarena@gmail.com>> wrote:
> >>>>>>>>>>>>>> > > > Hey Martin,
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
> >>>>>>>>>>>>>>
> >>> better?
> >>>
> >>>>> I
> >>>>>
> >>>>>>>>> *THINK*
> >>>>>>>>>
> >>>>>>>>>>>>>> that when
> >>>>>>>>>>>>>> > > > running in a portal environment you always
> >>>>>>>>>>>>>>
> >>> get
> >>>
> >>>>> the
> >>>>>
> >>>>>>>>>>>>>> simple-portlet skin
> >>>>>>>>>>>>>> > > > unless your portal provides one of the
> >>>>>>>>>>>>>>
> >>> necessary
> >>>
> >>>>>>> skin
> >>>>>>>
> >>>>>>>>>>>>>> extensions which,
> >>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
> >>>>>>>>>>>>>>
> >>> this
> >>>
> >>>>> is
> >>>>>
> >>>>>>> just
> >>>>>>>
> >>>>>>>>> a
> >>>>>>>>>
> >>>>>>>>>>>>>> case of us
> >>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > That article is interesting, but I think
> >>>>>>>>>>>>>>
> >>> that
> >>>
> >>>>>>> Trinidad
> >>>>>>>
> >>>>>>>>> has
> >>>>>>>>>
> >>>>>>>>>>>>>> attempted to
> >>>>>>>>>>>>>> > > > do the same thing only in a different way.
> >>>>>>>>>>>>>>
> >>>>> Instead
> >>>>>
> >>>>>>> of
> >>>>>>>
> >>>>>>>>> using
> >>>>>>>>>
> >>>>>>>>>>>>>> javascript
> >>>>>>>>>>>>>> > > > to copy in the styles, we actually change
> >>>>>>>>>>>>>>
> >>> the
> >>>
> >>>>> class
> >>>>>
> >>>>>>>>> names
> >>>>>>>>>
> >>>>>>>>>>>>>> that get
> >>>>>>>>>>>>>> > > > rendered on the client to use the portal
> >>>>>>>>>>>>>>
> >>> styles
> >>>
> >>>>>>> where
> >>>>>>>
> >>>>>>>>>>>>>> appropriate.
> >>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
> >>>>>>>>>>>>>>
> >>> tested
> >>>
> >>>>>>>>> extensively
> >>>>>>>>>
> >>>>>>>>>>>>>> because before
> >>>>>>>>>>>>>> > > > we started looking at 301, much of
> >>>>>>>>>>>>>>
> >>> Trinidad's
> >>>
> >>>>> portal
> >>>>>
> >>>>>>>>> work
> >>>>>>>>>
> >>>>>>>>>>>>>> has been done
> >>>>>>>>>>>>>> > > > with a Proof of Concept environment.
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > Scott
> >>>>>>>>>>>>>> > > >
> >>>>>>>>>>>>>> > > > 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
> >>>
> >>>>>>>>>>>> <
> >>>>>>>>>>>>
> >>> 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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>> --
> >>>>
> >>>> http://www.irian.at
> >>>>
> >>>> Your JSF powerhouse -
> >>>> JSF Consulting, Development and
> >>>> Courses in English and German
> >>>>
> >>>> Professional Support for Apache MyFaces
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
Oops. Submitted before I was done.
Currently Trinidad supports the ability to turn off stylesheets, it also
supports the ability to force a certain skin to render. Making is so
that the stylesheet only loads once, however, is not trivial and since
skinning extensions are currently combined into a single style sheet,
the first portlet and/or the portal container would need to make sure
those skinning extensions are installed as well.
Scott
Scott O'Bryan wrote:
> This won't work in WSRP Portal environments that may use distributed
> portlets. This is because the portlets may exist on different
> servers. Furthermore different portlets may have different skinning
> extensions. This will hose the styling if a portlet with no skinning
> extensions gets added before portlets WITH skinning extensions. The
> skinning extensions will not be available
>
>
> Martin Marinschek wrote:
>> Sure, this would work.
>>
>> Everyone agreeing we should do it this way?
>>
>> regards,
>>
>> Martin
>>
>> On 7/28/07, Simon Lessard <si...@gmail.com> wrote:
>>
>>> Yeah, that would imply every single renderers. In a non-portlet
>>> environment
>>> the performance hit would not be big though as it would only be on
>>> method
>>> call and checking if we run in a portlet environment would not be an
>>> expensive operation compared to the overall job done by renderers.
>>> However
>>> in the portlet environment, it would be a tad more...
>>>
>>> What about a ResponseWriter decorator applied by the renderkit if it
>>> get
>>> called by a portlet environment? The decorator could inject the
>>> JavaScript
>>> style copy just before the first non <html>, <head> or <body>
>>> element then
>>> set a boolean flag to false to inhibit itself. The overhaul would
>>> then be a
>>> single if evaluation per startElement. It would be called often, but
>>> a if
>>> with a boolean flag get evaluated in 2 ticks, which is nothing for all
>>> practical purposes.
>>>
>>>
>>> On 7/28/07, Martin Marinschek <ma...@gmail.com> wrote:
>>>
>>>> But you'd need to do this check in every renderer then, right? I
>>>> wonder if this is good performance wise.
>>>>
>>>> regards,
>>>>
>>>> Martin
>>>>
>>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
>>>>
>>>>> One way would be to have something along those line:
>>>>>
>>>>> CoreRenderer.java
>>>>>
>>>>> public void encodeBegin(FacesContext context, UIComponent component)
>>>>> {
>>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
>>>>>
>>> !isStyleSheetCopied())
>>>
>>>>> {
>>>>> pushStyleSheet(context);
>>>>> }
>>>>>
>>>>> // Do normal processing
>>>>> }
>>>>>
>>>>> protected abstract boolean isXhtmlRootElement();
>>>>>
>>>>> Then we would simply have to make isXhtmlRootElement() return true
>>>>> for
>>>>> document, head and body renderers and false for the others. But
>>>>> it's not
>>>>> extremely clean.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> ~ Simon
>>>>>
>>>>>
>>>>> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
>>>>>
>>>>>> Sure, it would be better for the user if it works out of the box.
>>>>>>
>>>>>> As much as I think, I don't find a central place where to put it,
>>>>>>
>>> though.
>>>
>>>>>> Ideas anyone?
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
>>>>>>
>>>>>>> Hello Martin,
>>>>>>>
>>>>>>> Yeah I thought about a new component and we actually already have
>>>>>>> <trh:styleSheet/> that could be slightly altered to do that work,
>>>>>>>
>>> but I
>>>
>>>>>>> would prefer a way not involving any action from users.
>>>>>>>
>>>>>>>
>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> true. The form-render was good for my nice small example, but is
>>>>>>>>
>>> no
>>>
>>>>>>>> general solution of course.
>>>>>>>>
>>>>>>>> I wonder if this would mandate a special component which does
>>>>>>>>
>>> nothing
>>>
>>>>>>>> but adding the stylesheet to the head?
>>>>>>>>
>>>>>>>> Eventually, the component could be generalized, so that all kinds
>>>>>>>>
>>> of
>>>
>>>>>>>> stylesheets can be added, if a link is provided and the stylesheet
>>>>>>>> hasn't been added so far - I think this solution might be
>>>>>>>>
>>> interesting
>>>
>>>>>>>> for the portlet-developer in general.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Issue with #3 is not very hard, we already have a
>>>>>>>>>
>>> RenderingContext
>>>
>>>>> that
>>>>>
>>>>>>> can
>>>>>>>
>>>>>>>>> be used for that. We could probably hook that code in
>>>>>>>>>
>>> CoreRenderer
>>>
>>>>> or
>>>>>
>>>>>>>>> XhtmlRenderer. The only issue left then would be to not have
>>>>>>>>>
>>>>> document,
>>>>>
>>>>>>> head
>>>>>>>
>>>>>>>>> and body renderer to execute it. Placing it in FormRenderer only
>>>>>>>>>
>>>>> does
>>>>>
>>>>>>> not
>>>>>>>
>>>>>>>>> seems right in case your page does not contain a form at all or
>>>>>>>>>
>>> use
>>>
>>>>> a
>>>>>
>>>>>>> basic
>>>>>>>
>>>>>>>>> JSF form (extremely unlikely though).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
>>>>>>>>>
>>> wrote:
>>>
>>>>>>>>>> For the discussion on if and how to integrate this into
>>>>>>>>>>
>>> Trinidad -
>>>
>>>>> I
>>>>>
>>>>>>>>>> see three cases:
>>>>>>>>>>
>>>>>>>>>> 1) people only want basic skinning, Trinidad uses
>>>>>>>>>>
>>> simple.portlet,
>>>
>>>>> and
>>>>>
>>>>>>>>>> emits portlet-standard compliant skinning hooks
>>>>>>>>>>
>>>>>>>>>> 2) people want normal Trinidad skinning, portlet container
>>>>>>>>>>
>>>>> provides
>>>>>
>>>>>>>>>> CSS file in the head, Trinidad doesn't have to do anything
>>>>>>>>>>
>>>>> (especially
>>>>>
>>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
>>>>>>>>>>
>>>>>>>>>> 3) people want Trinidad skinning, portlet container does not
>>>>>>>>>>
>>>>> provide
>>>>>
>>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS file with
>>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to be added
>>>>>>>>>>
>>> only
>>>
>>>>>>>>>> once.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>>
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
>>>>>>>>>>
>>>>> wrote:
>>>>>
>>>>>>>>>>> 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/26/07, Simon Lessard < simon.lessard.3@gmail.com>
>>>>>>>>>>>
>>> wrote:
>>>
>>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
>>>>>>>>>>>>
>>>>> vendor(s)...
>>>>>
>>>>>>> Ok,
>>>>>>>
>>>>>>>>> I see
>>>>>>>>>
>>>>>>>>>>>> the issue now... bleh...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Simon, you are correct. The portal would be able to
>>>>>>>>>>>>>
>>> push a
>>>
>>>>>>>>> parameter to
>>>>>>>>>
>>>>>>>>>>>>> Trinidad. Always in a portal environment the skin is
>>>>>>>>>>>>>
>>>>>>> uncompressed
>>>>>>>
>>>>>>>>> so
>>>>>>>>>
>>>>>>>>>>>>> that is also not an issue. But currently changing the
>>>>>>>>>>>>>
>>>>>>> stylesheet
>>>>>>>
>>>>>>>>>>>>> provided by the Portal is a modification that needs to
>>>>>>>>>>>>>
>>> be
>>>
>>>>> made
>>>>>
>>>>>>> to
>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>>>>> portal itself. I think that's where Martin is coming
>>>>>>>>>>>>>
>>> from.
>>>
>>>>> An
>>>>>
>>>>>>>>>>>>> unmodified portal container doesn't look very good when
>>>>>>>>>>>>>
>>>>>>> displaying
>>>>>>>
>>>>>>>>> faces
>>>>>>>>>
>>>>>>>>>>>>> and forcing every portal container to provide a skin
>>>>>>>>>>>>>
>>> that is
>>>
>>>>> not
>>>>>
>>>>>>>>> based
>>>>>>>>>
>>>>>>>>>>>>> off a standard is not going to be very successful in the
>>>>>>>>>>>>>
>>>>> general
>>>>>
>>>>>>>>> case.
>>>>>>>>>
>>>>>>>>>>>>> I totally agree with this, but we're sort of between a
>>>>>>>>>>>>>
>>> rock
>>>
>>>>> and
>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>>> hard
>>>>>>>>>
>>>>>>>>>>>>> place. :)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Simon Lessard wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not really, I think we detect a specific parameter
>>>>>>>>>>>>>>
>>> pushed
>>>
>>>>> by
>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>>>>>>>> container. So only container supporting skinning would
>>>>>>>>>>>>>>
>>>>> push
>>>>>
>>>>>>> it,
>>>>>>>
>>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For other
>>>>>>>>>>>>>>
>>>>> container
>>>>>
>>>>>>> I
>>>>>>>
>>>>>>>>> think
>>>>>>>>>
>>>>>>>>>>>>>> we simply use the normal code path... That or I had
>>>>>>>>>>>>>>
>>> some
>>>
>>>>>>> serious
>>>>>>>
>>>>>>>>>>>>>> hallucinations in the past months and imagined all
>>>>>>>>>>>>>>
>>> this...
>>>
>>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
>>>>>>>>>>>>>>
>>>>> martin.marinschek@gmail.com
>>>>>
>>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> well, but this would then be portlet container
>>>>>>>>>>>>>>
>>>>> dependent,
>>>>>
>>>>>>>>> right?
>>>>>>>>>
>>>>>>>>>>>> You'd
>>>>>>>>>>>>
>>>>>>>>>>>>>> effectively need to implement trinidad skinning in
>>>>>>>>>>>>>>
>>>>> every
>>>>>
>>>>>>>>> portlet
>>>>>>>>>
>>>>>>>>>>>>>> container.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
>>>>>>>>>>>>>>
>>> simon.lessard.3@gmail.com
>>>
>>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com>> wrote:
>>>>>>>>>>>>>> > Personally, I don't see why the portal should
>>>>>>>>>>>>>>
>>> not be
>>>
>>>>>>> able to
>>>>>>>
>>>>>>>>>>>>>> provide all
>>>>>>>>>>>>>> > selectors.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > Aren't we just not compressing the selector
>>>>>>>>>>>>>>
>>> names
>>>
>>>>> when
>>>>>
>>>>>>> we
>>>>>>>
>>>>>>>>> detect
>>>>>>>>>
>>>>>>>>>>>>>> a portal
>>>>>>>>>>>>>> > environment or did I miss something? I think
>>>>>>>>>>>>>>
>>> that
>>>
>>>>>>> strategy
>>>>>>>
>>>>>>>>>>>>>> cannot provides
>>>>>>>>>>>>>> > the icons though.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
>>>>>>>>>>>>>>
>>>>>>> martin.marinschek@gmail.com
>>>>>>>
>>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
>>>>>>>>>>>>>> > > Does the portlet container really provide
>>>>>>>>>>>>>>
>>> every
>>>
>>>>>>> styleclass
>>>>>>>
>>>>>>>>> that
>>>>>>>>>
>>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>>>> > > necessary for Trinidad components to look like
>>>>>>>>>>>>>>
>>>>> they
>>>>>
>>>>>>>>> normally
>>>>>>>>>
>>>>>>>>>>>> look?
>>>>>>>>>>>>
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > I'm just thinking that what is currently being
>>>>>>>>>>>>>>
>>>>> done is
>>>>>
>>>>>>> not
>>>>>>>
>>>>>>>>>>>>>> enough to
>>>>>>>>>>>>>> > > have the full skinning features available, and
>>>>>>>>>>>>>>
>>>>> that
>>>>>
>>>>>>> going
>>>>>>>
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>>>>>> > > direction of adding the CSS dynamically would
>>>>>>>>>>>>>>
>>>>> allow to
>>>>>
>>>>>>> do
>>>>>>>
>>>>>>>>> so.
>>>>>>>>>
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > regards,
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > Martin
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
>>>>>>>>>>>>>>
>>> darkarena@gmail.com
>>>
>>>>>>>>>>>>>> <mailto: darkarena@gmail.com>> wrote:
>>>>>>>>>>>>>> > > > Hey Martin,
>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
>>>>>>>>>>>>>>
>>> better?
>>>
>>>>> I
>>>>>
>>>>>>>>> *THINK*
>>>>>>>>>
>>>>>>>>>>>>>> that when
>>>>>>>>>>>>>> > > > running in a portal environment you always
>>>>>>>>>>>>>>
>>> get
>>>
>>>>> the
>>>>>
>>>>>>>>>>>>>> simple-portlet skin
>>>>>>>>>>>>>> > > > unless your portal provides one of the
>>>>>>>>>>>>>>
>>> necessary
>>>
>>>>>>> skin
>>>>>>>
>>>>>>>>>>>>>> extensions which,
>>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
>>>>>>>>>>>>>>
>>> this
>>>
>>>>> is
>>>>>
>>>>>>> just
>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>>>>>>> case of us
>>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>> > > > That article is interesting, but I think
>>>>>>>>>>>>>>
>>> that
>>>
>>>>>>> Trinidad
>>>>>>>
>>>>>>>>> has
>>>>>>>>>
>>>>>>>>>>>>>> attempted to
>>>>>>>>>>>>>> > > > do the same thing only in a different way.
>>>>>>>>>>>>>>
>>>>> Instead
>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>>> using
>>>>>>>>>
>>>>>>>>>>>>>> javascript
>>>>>>>>>>>>>> > > > to copy in the styles, we actually change
>>>>>>>>>>>>>>
>>> the
>>>
>>>>> class
>>>>>
>>>>>>>>> names
>>>>>>>>>
>>>>>>>>>>>>>> that get
>>>>>>>>>>>>>> > > > rendered on the client to use the portal
>>>>>>>>>>>>>>
>>> styles
>>>
>>>>>>> where
>>>>>>>
>>>>>>>>>>>>>> appropriate.
>>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
>>>>>>>>>>>>>>
>>> tested
>>>
>>>>>>>>> extensively
>>>>>>>>>
>>>>>>>>>>>>>> because before
>>>>>>>>>>>>>> > > > we started looking at 301, much of
>>>>>>>>>>>>>>
>>> Trinidad's
>>>
>>>>> portal
>>>>>
>>>>>>>>> work
>>>>>>>>>
>>>>>>>>>>>>>> has been done
>>>>>>>>>>>>>> > > > with a Proof of Concept environment.
>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>> > > > Scott
>>>>>>>>>>>>>> > > >
>>>>>>>>>>>>>> > > > 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
>>>
>>>>>>>>>>>> <
>>>>>>>>>>>>
>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>>
>>>> http://www.irian.at
>>>>
>>>> Your JSF powerhouse -
>>>> JSF Consulting, Development and
>>>> Courses in English and German
>>>>
>>>> Professional Support for Apache MyFaces
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
This won't work in WSRP Portal environments that may use distributed
portlets. This is because the portlets may exist on different servers.
Furthermore different portlets may have different skinning extensions.
This will hose the styling if a portlet with no skinning extensions gets
added before portlets WITH skinning extensions. The skinning extensions
will not be available
Martin Marinschek wrote:
> Sure, this would work.
>
> Everyone agreeing we should do it this way?
>
> regards,
>
> Martin
>
> On 7/28/07, Simon Lessard <si...@gmail.com> wrote:
>
>> Yeah, that would imply every single renderers. In a non-portlet environment
>> the performance hit would not be big though as it would only be on method
>> call and checking if we run in a portlet environment would not be an
>> expensive operation compared to the overall job done by renderers. However
>> in the portlet environment, it would be a tad more...
>>
>> What about a ResponseWriter decorator applied by the renderkit if it get
>> called by a portlet environment? The decorator could inject the JavaScript
>> style copy just before the first non <html>, <head> or <body> element then
>> set a boolean flag to false to inhibit itself. The overhaul would then be a
>> single if evaluation per startElement. It would be called often, but a if
>> with a boolean flag get evaluated in 2 ticks, which is nothing for all
>> practical purposes.
>>
>>
>> On 7/28/07, Martin Marinschek <ma...@gmail.com> wrote:
>>
>>> But you'd need to do this check in every renderer then, right? I
>>> wonder if this is good performance wise.
>>>
>>> regards,
>>>
>>> Martin
>>>
>>> On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
>>>
>>>> One way would be to have something along those line:
>>>>
>>>> CoreRenderer.java
>>>>
>>>> public void encodeBegin(FacesContext context, UIComponent component)
>>>> {
>>>> if (isPortlet(context) && !isXhtmlRootElement() &&
>>>>
>> !isStyleSheetCopied())
>>
>>>> {
>>>> pushStyleSheet(context);
>>>> }
>>>>
>>>> // Do normal processing
>>>> }
>>>>
>>>> protected abstract boolean isXhtmlRootElement();
>>>>
>>>> Then we would simply have to make isXhtmlRootElement() return true for
>>>> document, head and body renderers and false for the others. But it's not
>>>> extremely clean.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> ~ Simon
>>>>
>>>>
>>>> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
>>>>
>>>>> Sure, it would be better for the user if it works out of the box.
>>>>>
>>>>> As much as I think, I don't find a central place where to put it,
>>>>>
>> though.
>>
>>>>> Ideas anyone?
>>>>>
>>>>> regards,
>>>>>
>>>>> Martin
>>>>>
>>>>> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
>>>>>
>>>>>> Hello Martin,
>>>>>>
>>>>>> Yeah I thought about a new component and we actually already have
>>>>>> <trh:styleSheet/> that could be slightly altered to do that work,
>>>>>>
>> but I
>>
>>>>>> would prefer a way not involving any action from users.
>>>>>>
>>>>>>
>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> true. The form-render was good for my nice small example, but is
>>>>>>>
>> no
>>
>>>>>>> general solution of course.
>>>>>>>
>>>>>>> I wonder if this would mandate a special component which does
>>>>>>>
>> nothing
>>
>>>>>>> but adding the stylesheet to the head?
>>>>>>>
>>>>>>> Eventually, the component could be generalized, so that all kinds
>>>>>>>
>> of
>>
>>>>>>> stylesheets can be added, if a link is provided and the stylesheet
>>>>>>> hasn't been added so far - I think this solution might be
>>>>>>>
>> interesting
>>
>>>>>>> for the portlet-developer in general.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Issue with #3 is not very hard, we already have a
>>>>>>>>
>> RenderingContext
>>
>>>> that
>>>>
>>>>>> can
>>>>>>
>>>>>>>> be used for that. We could probably hook that code in
>>>>>>>>
>> CoreRenderer
>>
>>>> or
>>>>
>>>>>>>> XhtmlRenderer. The only issue left then would be to not have
>>>>>>>>
>>>> document,
>>>>
>>>>>> head
>>>>>>
>>>>>>>> and body renderer to execute it. Placing it in FormRenderer only
>>>>>>>>
>>>> does
>>>>
>>>>>> not
>>>>>>
>>>>>>>> seems right in case your page does not contain a form at all or
>>>>>>>>
>> use
>>
>>>> a
>>>>
>>>>>> basic
>>>>>>
>>>>>>>> JSF form (extremely unlikely though).
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
>>>>>>>>
>> wrote:
>>
>>>>>>>>> For the discussion on if and how to integrate this into
>>>>>>>>>
>> Trinidad -
>>
>>>> I
>>>>
>>>>>>>>> see three cases:
>>>>>>>>>
>>>>>>>>> 1) people only want basic skinning, Trinidad uses
>>>>>>>>>
>> simple.portlet,
>>
>>>> and
>>>>
>>>>>>>>> emits portlet-standard compliant skinning hooks
>>>>>>>>>
>>>>>>>>> 2) people want normal Trinidad skinning, portlet container
>>>>>>>>>
>>>> provides
>>>>
>>>>>>>>> CSS file in the head, Trinidad doesn't have to do anything
>>>>>>>>>
>>>> (especially
>>>>
>>>>>>>>> not switch to portlet-standard compliant skinning hooks)
>>>>>>>>>
>>>>>>>>> 3) people want Trinidad skinning, portlet container does not
>>>>>>>>>
>>>> provide
>>>>
>>>>>>>>> the CSS file, Trinidad portlet needs to add the CSS file with
>>>>>>>>> JavaScript itself. Issue to solve: CSS file needs to be added
>>>>>>>>>
>> only
>>
>>>>>>>>> once.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
>>>>>>>>>
>>>> wrote:
>>>>
>>>>>>>>>> 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/26/07, Simon Lessard < simon.lessard.3@gmail.com>
>>>>>>>>>>
>> wrote:
>>
>>>>>>>>>>> Thus linking Portal-Trinidad users to specific portal
>>>>>>>>>>>
>>>> vendor(s)...
>>>>
>>>>>> Ok,
>>>>>>
>>>>>>>> I see
>>>>>>>>
>>>>>>>>>>> the issue now... bleh...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Simon, you are correct. The portal would be able to
>>>>>>>>>>>>
>> push a
>>
>>>>>>>> parameter to
>>>>>>>>
>>>>>>>>>>>> Trinidad. Always in a portal environment the skin is
>>>>>>>>>>>>
>>>>>> uncompressed
>>>>>>
>>>>>>>> so
>>>>>>>>
>>>>>>>>>>>> that is also not an issue. But currently changing the
>>>>>>>>>>>>
>>>>>> stylesheet
>>>>>>
>>>>>>>>>>>> provided by the Portal is a modification that needs to
>>>>>>>>>>>>
>> be
>>
>>>> made
>>>>
>>>>>> to
>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>>>>> portal itself. I think that's where Martin is coming
>>>>>>>>>>>>
>> from.
>>
>>>> An
>>>>
>>>>>>>>>>>> unmodified portal container doesn't look very good when
>>>>>>>>>>>>
>>>>>> displaying
>>>>>>
>>>>>>>> faces
>>>>>>>>
>>>>>>>>>>>> and forcing every portal container to provide a skin
>>>>>>>>>>>>
>> that is
>>
>>>> not
>>>>
>>>>>>>> based
>>>>>>>>
>>>>>>>>>>>> off a standard is not going to be very successful in the
>>>>>>>>>>>>
>>>> general
>>>>
>>>>>>>> case.
>>>>>>>>
>>>>>>>>>>>> I totally agree with this, but we're sort of between a
>>>>>>>>>>>>
>> rock
>>
>>>> and
>>>>
>>>>>> a
>>>>>>
>>>>>>>> hard
>>>>>>>>
>>>>>>>>>>>> place. :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Simon Lessard wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Not really, I think we detect a specific parameter
>>>>>>>>>>>>>
>> pushed
>>
>>>> by
>>>>
>>>>>> the
>>>>>>
>>>>>>>>>>>>> container. So only container supporting skinning would
>>>>>>>>>>>>>
>>>> push
>>>>
>>>>>> it,
>>>>>>
>>>>>>>>>>>>> effectively synchronizing all portlet LaF. For other
>>>>>>>>>>>>>
>>>> container
>>>>
>>>>>> I
>>>>>>
>>>>>>>> think
>>>>>>>>
>>>>>>>>>>>>> we simply use the normal code path... That or I had
>>>>>>>>>>>>>
>> some
>>
>>>>>> serious
>>>>>>
>>>>>>>>>>>>> hallucinations in the past months and imagined all
>>>>>>>>>>>>>
>> this...
>>
>>>>>>>>>>>>> On 7/26/07, *Martin Marinschek* <
>>>>>>>>>>>>>
>>>> martin.marinschek@gmail.com
>>>>
>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>
>>>>>>>>>>>>> well, but this would then be portlet container
>>>>>>>>>>>>>
>>>> dependent,
>>>>
>>>>>>>> right?
>>>>>>>>
>>>>>>>>>>> You'd
>>>>>>>>>>>
>>>>>>>>>>>>> effectively need to implement trinidad skinning in
>>>>>>>>>>>>>
>>>> every
>>>>
>>>>>>>> portlet
>>>>>>>>
>>>>>>>>>>>>> container.
>>>>>>>>>>>>>
>>>>>>>>>>>>> regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/26/07, Simon Lessard <
>>>>>>>>>>>>>
>> simon.lessard.3@gmail.com
>>
>>>>>>>>>>>>> <mailto: simon.lessard.3@gmail.com>> wrote:
>>>>>>>>>>>>> > Personally, I don't see why the portal should
>>>>>>>>>>>>>
>> not be
>>
>>>>>> able to
>>>>>>
>>>>>>>>>>>>> provide all
>>>>>>>>>>>>> > selectors.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Aren't we just not compressing the selector
>>>>>>>>>>>>>
>> names
>>
>>>> when
>>>>
>>>>>> we
>>>>>>
>>>>>>>> detect
>>>>>>>>
>>>>>>>>>>>>> a portal
>>>>>>>>>>>>> > environment or did I miss something? I think
>>>>>>>>>>>>>
>> that
>>
>>>>>> strategy
>>>>>>
>>>>>>>>>>>>> cannot provides
>>>>>>>>>>>>> > the icons though.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > On 7/26/07, Martin Marinschek <
>>>>>>>>>>>>>
>>>>>> martin.marinschek@gmail.com
>>>>>>
>>>>>>>>>>>>> <mailto: martin.marinschek@gmail.com >> wrote:
>>>>>>>>>>>>> > > Does the portlet container really provide
>>>>>>>>>>>>>
>> every
>>
>>>>>> styleclass
>>>>>>
>>>>>>>> that
>>>>>>>>
>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>>>> > > necessary for Trinidad components to look like
>>>>>>>>>>>>>
>>>> they
>>>>
>>>>>>>> normally
>>>>>>>>
>>>>>>>>>>> look?
>>>>>>>>>>>
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > I'm just thinking that what is currently being
>>>>>>>>>>>>>
>>>> done is
>>>>
>>>>>> not
>>>>>>
>>>>>>>>>>>>> enough to
>>>>>>>>>>>>> > > have the full skinning features available, and
>>>>>>>>>>>>>
>>>> that
>>>>
>>>>>> going
>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>>>>>> > > direction of adding the CSS dynamically would
>>>>>>>>>>>>>
>>>> allow to
>>>>
>>>>>> do
>>>>>>
>>>>>>>> so.
>>>>>>>>
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > regards,
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > Martin
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > On 7/26/07, Scott O'Bryan <
>>>>>>>>>>>>>
>> darkarena@gmail.com
>>
>>>>>>>>>>>>> <mailto: darkarena@gmail.com>> wrote:
>>>>>>>>>>>>> > > > Hey Martin,
>>>>>>>>>>>>> > > >
>>>>>>>>>>>>> > > > Does the simple-portlet skin render any
>>>>>>>>>>>>>
>> better?
>>
>>>> I
>>>>
>>>>>>>> *THINK*
>>>>>>>>
>>>>>>>>>>>>> that when
>>>>>>>>>>>>> > > > running in a portal environment you always
>>>>>>>>>>>>>
>> get
>>
>>>> the
>>>>
>>>>>>>>>>>>> simple-portlet skin
>>>>>>>>>>>>> > > > unless your portal provides one of the
>>>>>>>>>>>>>
>> necessary
>>
>>>>>> skin
>>>>>>
>>>>>>>>>>>>> extensions which,
>>>>>>>>>>>>> > > > right now, it trinidad proprietary. Maybe
>>>>>>>>>>>>>
>> this
>>
>>>> is
>>>>
>>>>>> just
>>>>>>
>>>>>>>> a
>>>>>>>>
>>>>>>>>>>>>> case of us
>>>>>>>>>>>>> > > > needing to bug-fix the portlet skin.
>>>>>>>>>>>>> > > >
>>>>>>>>>>>>> > > > That article is interesting, but I think
>>>>>>>>>>>>>
>> that
>>
>>>>>> Trinidad
>>>>>>
>>>>>>>> has
>>>>>>>>
>>>>>>>>>>>>> attempted to
>>>>>>>>>>>>> > > > do the same thing only in a different way.
>>>>>>>>>>>>>
>>>> Instead
>>>>
>>>>>> of
>>>>>>
>>>>>>>> using
>>>>>>>>
>>>>>>>>>>>>> javascript
>>>>>>>>>>>>> > > > to copy in the styles, we actually change
>>>>>>>>>>>>>
>> the
>>
>>>> class
>>>>
>>>>>>>> names
>>>>>>>>
>>>>>>>>>>>>> that get
>>>>>>>>>>>>> > > > rendered on the client to use the portal
>>>>>>>>>>>>>
>> styles
>>
>>>>>> where
>>>>>>
>>>>>>>>>>>>> appropriate.
>>>>>>>>>>>>> > > > Still, I'm not sure that this has been
>>>>>>>>>>>>>
>> tested
>>
>>>>>>>> extensively
>>>>>>>>
>>>>>>>>>>>>> because before
>>>>>>>>>>>>> > > > we started looking at 301, much of
>>>>>>>>>>>>>
>> Trinidad's
>>
>>>> portal
>>>>
>>>>>>>> work
>>>>>>>>
>>>>>>>>>>>>> has been done
>>>>>>>>>>>>> > > > with a Proof of Concept environment.
>>>>>>>>>>>>> > > >
>>>>>>>>>>>>> > > > Scott
>>>>>>>>>>>>> > > >
>>>>>>>>>>>>> > > > 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
>>
>>>>>>>>>>> <
>>>>>>>>>>>
>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>> --
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>>
>>
>
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
Sure, this would work.
Everyone agreeing we should do it this way?
regards,
Martin
On 7/28/07, Simon Lessard <si...@gmail.com> wrote:
> Yeah, that would imply every single renderers. In a non-portlet environment
> the performance hit would not be big though as it would only be on method
> call and checking if we run in a portlet environment would not be an
> expensive operation compared to the overall job done by renderers. However
> in the portlet environment, it would be a tad more...
>
> What about a ResponseWriter decorator applied by the renderkit if it get
> called by a portlet environment? The decorator could inject the JavaScript
> style copy just before the first non <html>, <head> or <body> element then
> set a boolean flag to false to inhibit itself. The overhaul would then be a
> single if evaluation per startElement. It would be called often, but a if
> with a boolean flag get evaluated in 2 ticks, which is nothing for all
> practical purposes.
>
>
> On 7/28/07, Martin Marinschek <ma...@gmail.com> wrote:
> > But you'd need to do this check in every renderer then, right? I
> > wonder if this is good performance wise.
> >
> > regards,
> >
> > Martin
> >
> > On 7/27/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > One way would be to have something along those line:
> > >
> > > CoreRenderer.java
> > >
> > > public void encodeBegin(FacesContext context, UIComponent component)
> > > {
> > > if (isPortlet(context) && !isXhtmlRootElement() &&
> !isStyleSheetCopied())
> > > {
> > > pushStyleSheet(context);
> > > }
> > >
> > > // Do normal processing
> > > }
> > >
> > > protected abstract boolean isXhtmlRootElement();
> > >
> > > Then we would simply have to make isXhtmlRootElement() return true for
> > > document, head and body renderers and false for the others. But it's not
> > > extremely clean.
> > >
> > >
> > > Regards,
> > >
> > > ~ Simon
> > >
> > >
> > > On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > > > Sure, it would be better for the user if it works out of the box.
> > > >
> > > > As much as I think, I don't find a central place where to put it,
> though.
> > > >
> > > > Ideas anyone?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > > > Hello Martin,
> > > > >
> > > > > Yeah I thought about a new component and we actually already have
> > > > > <trh:styleSheet/> that could be slightly altered to do that work,
> but I
> > > > > would prefer a way not involving any action from users.
> > > > >
> > > > >
> > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > > Hi Simon,
> > > > > >
> > > > > > true. The form-render was good for my nice small example, but is
> no
> > > > > > general solution of course.
> > > > > >
> > > > > > I wonder if this would mandate a special component which does
> nothing
> > > > > > but adding the stylesheet to the head?
> > > > > >
> > > > > > Eventually, the component could be generalized, so that all kinds
> of
> > > > > > stylesheets can be added, if a link is provided and the stylesheet
> > > > > > hasn't been added so far - I think this solution might be
> interesting
> > > > > > for the portlet-developer in general.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > > > > > Issue with #3 is not very hard, we already have a
> RenderingContext
> > > that
> > > > > can
> > > > > > > be used for that. We could probably hook that code in
> CoreRenderer
> > > or
> > > > > > > XhtmlRenderer. The only issue left then would be to not have
> > > document,
> > > > > head
> > > > > > > and body renderer to execute it. Placing it in FormRenderer only
> > > does
> > > > > not
> > > > > > > seems right in case your page does not contain a form at all or
> use
> > > a
> > > > > basic
> > > > > > > JSF form (extremely unlikely though).
> > > > > > >
> > > > > > >
> > > > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
> wrote:
> > > > > > > > For the discussion on if and how to integrate this into
> Trinidad -
> > > I
> > > > > > > > see three cases:
> > > > > > > >
> > > > > > > > 1) people only want basic skinning, Trinidad uses
> simple.portlet,
> > > and
> > > > > > > > emits portlet-standard compliant skinning hooks
> > > > > > > >
> > > > > > > > 2) people want normal Trinidad skinning, portlet container
> > > provides
> > > > > > > > CSS file in the head, Trinidad doesn't have to do anything
> > > (especially
> > > > > > > > not switch to portlet-standard compliant skinning hooks)
> > > > > > > >
> > > > > > > > 3) people want Trinidad skinning, portlet container does not
> > > provide
> > > > > > > > the CSS file, Trinidad portlet needs to add the CSS file with
> > > > > > > > JavaScript itself. Issue to solve: CSS file needs to be added
> only
> > > > > > > > once.
> > > > > > > >
> > > > > > > > regards,
> > > > > > > >
> > > > > > > > Martin
> > > > > > > >
> > > > > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
> > > wrote:
> > > > > > > > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com>
> wrote:
> > > > > > > > > > Thus linking Portal-Trinidad users to specific portal
> > > vendor(s)...
> > > > > Ok,
> > > > > > > I see
> > > > > > > > > > the issue now... bleh...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> > > > > > > > > > > Simon, you are correct. The portal would be able to
> push a
> > > > > > > parameter to
> > > > > > > > > > > Trinidad. Always in a portal environment the skin is
> > > > > uncompressed
> > > > > > > so
> > > > > > > > > > > that is also not an issue. But currently changing the
> > > > > stylesheet
> > > > > > > > > > > provided by the Portal is a modification that needs to
> be
> > > made
> > > > > to
> > > > > > > the
> > > > > > > > > > > portal itself. I think that's where Martin is coming
> from.
> > > An
> > > > > > > > > > > unmodified portal container doesn't look very good when
> > > > > displaying
> > > > > > > faces
> > > > > > > > > > > and forcing every portal container to provide a skin
> that is
> > > not
> > > > > > > based
> > > > > > > > > > > off a standard is not going to be very successful in the
> > > general
> > > > > > > case.
> > > > > > > > > > > I totally agree with this, but we're sort of between a
> rock
> > > and
> > > > > a
> > > > > > > hard
> > > > > > > > > > > place. :)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Simon Lessard wrote:
> > > > > > > > > > > > Not really, I think we detect a specific parameter
> pushed
> > > by
> > > > > the
> > > > > > > > > > > > container. So only container supporting skinning would
> > > push
> > > > > it,
> > > > > > > > > > > > effectively synchronizing all portlet LaF. For other
> > > container
> > > > > I
> > > > > > > think
> > > > > > > > > > > > we simply use the normal code path... That or I had
> some
> > > > > serious
> > > > > > > > > > > > hallucinations in the past months and imagined all
> this...
> > > > > > > > > > > >
> > > > > > > > > > > > On 7/26/07, *Martin Marinschek* <
> > > martin.marinschek@gmail.com
> > > > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > well, but this would then be portlet container
> > > dependent,
> > > > > > > right?
> > > > > > > > > > You'd
> > > > > > > > > > > > effectively need to implement trinidad skinning in
> > > every
> > > > > > > portlet
> > > > > > > > > > > > container.
> > > > > > > > > > > >
> > > > > > > > > > > > regards,
> > > > > > > > > > > >
> > > > > > > > > > > > Martin
> > > > > > > > > > > >
> > > > > > > > > > > > On 7/26/07, Simon Lessard <
> simon.lessard.3@gmail.com
> > > > > > > > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > > > > > > > Personally, I don't see why the portal should
> not be
> > > > > able to
> > > > > > > > > > > > provide all
> > > > > > > > > > > > > selectors.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Aren't we just not compressing the selector
> names
> > > when
> > > > > we
> > > > > > > detect
> > > > > > > > > > > > a portal
> > > > > > > > > > > > > environment or did I miss something? I think
> that
> > > > > strategy
> > > > > > > > > > > > cannot provides
> > > > > > > > > > > > > the icons though.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 7/26/07, Martin Marinschek <
> > > > > martin.marinschek@gmail.com
> > > > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > > > > > > Does the portlet container really provide
> every
> > > > > styleclass
> > > > > > > that
> > > > > > > > > > is
> > > > > > > > > > > > > > necessary for Trinidad components to look like
> > > they
> > > > > > > normally
> > > > > > > > > > look?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm just thinking that what is currently being
> > > done is
> > > > > not
> > > > > > > > > > > > enough to
> > > > > > > > > > > > > > have the full skinning features available, and
> > > that
> > > > > going
> > > > > > > the
> > > > > > > > > > > > > > direction of adding the CSS dynamically would
> > > allow to
> > > > > do
> > > > > > > so.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > regards,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Martin
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 7/26/07, Scott O'Bryan <
> darkarena@gmail.com
> > > > > > > > > > > > <mailto: darkarena@gmail.com>> wrote:
> > > > > > > > > > > > > > > Hey Martin,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Does the simple-portlet skin render any
> better?
> > > I
> > > > > > > *THINK*
> > > > > > > > > > > > that when
> > > > > > > > > > > > > > > running in a portal environment you always
> get
> > > the
> > > > > > > > > > > > simple-portlet skin
> > > > > > > > > > > > > > > unless your portal provides one of the
> necessary
> > > > > skin
> > > > > > > > > > > > extensions which,
> > > > > > > > > > > > > > > right now, it trinidad proprietary. Maybe
> this
> > > is
> > > > > just
> > > > > > > a
> > > > > > > > > > > > case of us
> > > > > > > > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > That article is interesting, but I think
> that
> > > > > Trinidad
> > > > > > > has
> > > > > > > > > > > > attempted to
> > > > > > > > > > > > > > > do the same thing only in a different way.
> > > Instead
> > > > > of
> > > > > > > using
> > > > > > > > > > > > javascript
> > > > > > > > > > > > > > > to copy in the styles, we actually change
> the
> > > class
> > > > > > > names
> > > > > > > > > > > > that get
> > > > > > > > > > > > > > > rendered on the client to use the portal
> styles
> > > > > where
> > > > > > > > > > > > appropriate.
> > > > > > > > > > > > > > > Still, I'm not sure that this has been
> tested
> > > > > > > extensively
> > > > > > > > > > > > because before
> > > > > > > > > > > > > > > we started looking at 301, much of
> Trinidad's
> > > portal
> > > > > > > work
> > > > > > > > > > > > has been done
> > > > > > > > > > > > > > > with a Proof of Concept environment.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Scott
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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
> > > > > > > > > > > >
> > > > > > > > > > <
> > > > > > >
> > > > >
> > >
> 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
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > 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
> > > >
> > >
> > >
> >
> >
> > --
> >
> > 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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Yeah, that would imply every single renderers. In a non-portlet environment
the performance hit would not be big though as it would only be on method
call and checking if we run in a portlet environment would not be an
expensive operation compared to the overall job done by renderers. However
in the portlet environment, it would be a tad more...
What about a ResponseWriter decorator applied by the renderkit if it get
called by a portlet environment? The decorator could inject the JavaScript
style copy just before the first non <html>, <head> or <body> element then
set a boolean flag to false to inhibit itself. The overhaul would then be a
single if evaluation per startElement. It would be called often, but a if
with a boolean flag get evaluated in 2 ticks, which is nothing for all
practical purposes.
On 7/28/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> But you'd need to do this check in every renderer then, right? I
> wonder if this is good performance wise.
>
> regards,
>
> Martin
>
> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > One way would be to have something along those line:
> >
> > CoreRenderer.java
> >
> > public void encodeBegin(FacesContext context, UIComponent component)
> > {
> > if (isPortlet(context) && !isXhtmlRootElement() &&
> !isStyleSheetCopied())
> > {
> > pushStyleSheet(context);
> > }
> >
> > // Do normal processing
> > }
> >
> > protected abstract boolean isXhtmlRootElement();
> >
> > Then we would simply have to make isXhtmlRootElement() return true for
> > document, head and body renderers and false for the others. But it's not
> > extremely clean.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> >
> > On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > > Sure, it would be better for the user if it works out of the box.
> > >
> > > As much as I think, I don't find a central place where to put it,
> though.
> > >
> > > Ideas anyone?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > > Hello Martin,
> > > >
> > > > Yeah I thought about a new component and we actually already have
> > > > <trh:styleSheet/> that could be slightly altered to do that work,
> but I
> > > > would prefer a way not involving any action from users.
> > > >
> > > >
> > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > Hi Simon,
> > > > >
> > > > > true. The form-render was good for my nice small example, but is
> no
> > > > > general solution of course.
> > > > >
> > > > > I wonder if this would mandate a special component which does
> nothing
> > > > > but adding the stylesheet to the head?
> > > > >
> > > > > Eventually, the component could be generalized, so that all kinds
> of
> > > > > stylesheets can be added, if a link is provided and the stylesheet
> > > > > hasn't been added so far - I think this solution might be
> interesting
> > > > > for the portlet-developer in general.
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > > > > Issue with #3 is not very hard, we already have a
> RenderingContext
> > that
> > > > can
> > > > > > be used for that. We could probably hook that code in
> CoreRenderer
> > or
> > > > > > XhtmlRenderer. The only issue left then would be to not have
> > document,
> > > > head
> > > > > > and body renderer to execute it. Placing it in FormRenderer only
> > does
> > > > not
> > > > > > seems right in case your page does not contain a form at all or
> use
> > a
> > > > basic
> > > > > > JSF form (extremely unlikely though).
> > > > > >
> > > > > >
> > > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
> wrote:
> > > > > > > For the discussion on if and how to integrate this into
> Trinidad -
> > I
> > > > > > > see three cases:
> > > > > > >
> > > > > > > 1) people only want basic skinning, Trinidad uses
> simple.portlet,
> > and
> > > > > > > emits portlet-standard compliant skinning hooks
> > > > > > >
> > > > > > > 2) people want normal Trinidad skinning, portlet container
> > provides
> > > > > > > CSS file in the head, Trinidad doesn't have to do anything
> > (especially
> > > > > > > not switch to portlet-standard compliant skinning hooks)
> > > > > > >
> > > > > > > 3) people want Trinidad skinning, portlet container does not
> > provide
> > > > > > > the CSS file, Trinidad portlet needs to add the CSS file with
> > > > > > > JavaScript itself. Issue to solve: CSS file needs to be added
> only
> > > > > > > once.
> > > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
> > wrote:
> > > > > > > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com>
> wrote:
> > > > > > > > > Thus linking Portal-Trinidad users to specific portal
> > vendor(s)...
> > > > Ok,
> > > > > > I see
> > > > > > > > > the issue now... bleh...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> > > > > > > > > > Simon, you are correct. The portal would be able to
> push a
> > > > > > parameter to
> > > > > > > > > > Trinidad. Always in a portal environment the skin is
> > > > uncompressed
> > > > > > so
> > > > > > > > > > that is also not an issue. But currently changing the
> > > > stylesheet
> > > > > > > > > > provided by the Portal is a modification that needs to
> be
> > made
> > > > to
> > > > > > the
> > > > > > > > > > portal itself. I think that's where Martin is coming
> from.
> > An
> > > > > > > > > > unmodified portal container doesn't look very good when
> > > > displaying
> > > > > > faces
> > > > > > > > > > and forcing every portal container to provide a skin
> that is
> > not
> > > > > > based
> > > > > > > > > > off a standard is not going to be very successful in the
> > general
> > > > > > case.
> > > > > > > > > > I totally agree with this, but we're sort of between a
> rock
> > and
> > > > a
> > > > > > hard
> > > > > > > > > > place. :)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Simon Lessard wrote:
> > > > > > > > > > > Not really, I think we detect a specific parameter
> pushed
> > by
> > > > the
> > > > > > > > > > > container. So only container supporting skinning would
> > push
> > > > it,
> > > > > > > > > > > effectively synchronizing all portlet LaF. For other
> > container
> > > > I
> > > > > > think
> > > > > > > > > > > we simply use the normal code path... That or I had
> some
> > > > serious
> > > > > > > > > > > hallucinations in the past months and imagined all
> this...
> > > > > > > > > > >
> > > > > > > > > > > On 7/26/07, *Martin Marinschek* <
> > martin.marinschek@gmail.com
> > > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > well, but this would then be portlet container
> > dependent,
> > > > > > right?
> > > > > > > > > You'd
> > > > > > > > > > > effectively need to implement trinidad skinning in
> > every
> > > > > > portlet
> > > > > > > > > > > container.
> > > > > > > > > > >
> > > > > > > > > > > regards,
> > > > > > > > > > >
> > > > > > > > > > > Martin
> > > > > > > > > > >
> > > > > > > > > > > On 7/26/07, Simon Lessard <
> simon.lessard.3@gmail.com
> > > > > > > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > > > > > > Personally, I don't see why the portal should
> not be
> > > > able to
> > > > > > > > > > > provide all
> > > > > > > > > > > > selectors.
> > > > > > > > > > > >
> > > > > > > > > > > > Aren't we just not compressing the selector
> names
> > when
> > > > we
> > > > > > detect
> > > > > > > > > > > a portal
> > > > > > > > > > > > environment or did I miss something? I think
> that
> > > > strategy
> > > > > > > > > > > cannot provides
> > > > > > > > > > > > the icons though.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 7/26/07, Martin Marinschek <
> > > > martin.marinschek@gmail.com
> > > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > > > > > Does the portlet container really provide
> every
> > > > styleclass
> > > > > > that
> > > > > > > > > is
> > > > > > > > > > > > > necessary for Trinidad components to look like
> > they
> > > > > > normally
> > > > > > > > > look?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm just thinking that what is currently being
> > done is
> > > > not
> > > > > > > > > > > enough to
> > > > > > > > > > > > > have the full skinning features available, and
> > that
> > > > going
> > > > > > the
> > > > > > > > > > > > > direction of adding the CSS dynamically would
> > allow to
> > > > do
> > > > > > so.
> > > > > > > > > > > > >
> > > > > > > > > > > > > regards,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Martin
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 7/26/07, Scott O'Bryan <
> darkarena@gmail.com
> > > > > > > > > > > <mailto: darkarena@gmail.com>> wrote:
> > > > > > > > > > > > > > Hey Martin,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Does the simple-portlet skin render any
> better?
> > I
> > > > > > *THINK*
> > > > > > > > > > > that when
> > > > > > > > > > > > > > running in a portal environment you always
> get
> > the
> > > > > > > > > > > simple-portlet skin
> > > > > > > > > > > > > > unless your portal provides one of the
> necessary
> > > > skin
> > > > > > > > > > > extensions which,
> > > > > > > > > > > > > > right now, it trinidad proprietary. Maybe
> this
> > is
> > > > just
> > > > > > a
> > > > > > > > > > > case of us
> > > > > > > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > That article is interesting, but I think
> that
> > > > Trinidad
> > > > > > has
> > > > > > > > > > > attempted to
> > > > > > > > > > > > > > do the same thing only in a different way.
> > Instead
> > > > of
> > > > > > using
> > > > > > > > > > > javascript
> > > > > > > > > > > > > > to copy in the styles, we actually change
> the
> > class
> > > > > > names
> > > > > > > > > > > that get
> > > > > > > > > > > > > > rendered on the client to use the portal
> styles
> > > > where
> > > > > > > > > > > appropriate.
> > > > > > > > > > > > > > Still, I'm not sure that this has been
> tested
> > > > > > extensively
> > > > > > > > > > > because before
> > > > > > > > > > > > > > we started looking at 301, much of
> Trinidad's
> > portal
> > > > > > work
> > > > > > > > > > > has been done
> > > > > > > > > > > > > > with a Proof of Concept environment.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Scott
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > <
> > > > > >
> > > >
> > 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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > 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
> > >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
But you'd need to do this check in every renderer then, right? I
wonder if this is good performance wise.
regards,
Martin
On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> One way would be to have something along those line:
>
> CoreRenderer.java
>
> public void encodeBegin(FacesContext context, UIComponent component)
> {
> if (isPortlet(context) && !isXhtmlRootElement() && !isStyleSheetCopied())
> {
> pushStyleSheet(context);
> }
>
> // Do normal processing
> }
>
> protected abstract boolean isXhtmlRootElement();
>
> Then we would simply have to make isXhtmlRootElement() return true for
> document, head and body renderers and false for the others. But it's not
> extremely clean.
>
>
> Regards,
>
> ~ Simon
>
>
> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > Sure, it would be better for the user if it works out of the box.
> >
> > As much as I think, I don't find a central place where to put it, though.
> >
> > Ideas anyone?
> >
> > regards,
> >
> > Martin
> >
> > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > Hello Martin,
> > >
> > > Yeah I thought about a new component and we actually already have
> > > <trh:styleSheet/> that could be slightly altered to do that work, but I
> > > would prefer a way not involving any action from users.
> > >
> > >
> > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > Hi Simon,
> > > >
> > > > true. The form-render was good for my nice small example, but is no
> > > > general solution of course.
> > > >
> > > > I wonder if this would mandate a special component which does nothing
> > > > but adding the stylesheet to the head?
> > > >
> > > > Eventually, the component could be generalized, so that all kinds of
> > > > stylesheets can be added, if a link is provided and the stylesheet
> > > > hasn't been added so far - I think this solution might be interesting
> > > > for the portlet-developer in general.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > > > Issue with #3 is not very hard, we already have a RenderingContext
> that
> > > can
> > > > > be used for that. We could probably hook that code in CoreRenderer
> or
> > > > > XhtmlRenderer. The only issue left then would be to not have
> document,
> > > head
> > > > > and body renderer to execute it. Placing it in FormRenderer only
> does
> > > not
> > > > > seems right in case your page does not contain a form at all or use
> a
> > > basic
> > > > > JSF form (extremely unlikely though).
> > > > >
> > > > >
> > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > > For the discussion on if and how to integrate this into Trinidad -
> I
> > > > > > see three cases:
> > > > > >
> > > > > > 1) people only want basic skinning, Trinidad uses simple.portlet,
> and
> > > > > > emits portlet-standard compliant skinning hooks
> > > > > >
> > > > > > 2) people want normal Trinidad skinning, portlet container
> provides
> > > > > > CSS file in the head, Trinidad doesn't have to do anything
> (especially
> > > > > > not switch to portlet-standard compliant skinning hooks)
> > > > > >
> > > > > > 3) people want Trinidad skinning, portlet container does not
> provide
> > > > > > the CSS file, Trinidad portlet needs to add the CSS file with
> > > > > > JavaScript itself. Issue to solve: CSS file needs to be added only
> > > > > > once.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
> wrote:
> > > > > > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > > > > > > Thus linking Portal-Trinidad users to specific portal
> vendor(s)...
> > > Ok,
> > > > > I see
> > > > > > > > the issue now... bleh...
> > > > > > > >
> > > > > > > >
> > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> > > > > > > > > Simon, you are correct. The portal would be able to push a
> > > > > parameter to
> > > > > > > > > Trinidad. Always in a portal environment the skin is
> > > uncompressed
> > > > > so
> > > > > > > > > that is also not an issue. But currently changing the
> > > stylesheet
> > > > > > > > > provided by the Portal is a modification that needs to be
> made
> > > to
> > > > > the
> > > > > > > > > portal itself. I think that's where Martin is coming from.
> An
> > > > > > > > > unmodified portal container doesn't look very good when
> > > displaying
> > > > > faces
> > > > > > > > > and forcing every portal container to provide a skin that is
> not
> > > > > based
> > > > > > > > > off a standard is not going to be very successful in the
> general
> > > > > case.
> > > > > > > > > I totally agree with this, but we're sort of between a rock
> and
> > > a
> > > > > hard
> > > > > > > > > place. :)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Simon Lessard wrote:
> > > > > > > > > > Not really, I think we detect a specific parameter pushed
> by
> > > the
> > > > > > > > > > container. So only container supporting skinning would
> push
> > > it,
> > > > > > > > > > effectively synchronizing all portlet LaF. For other
> container
> > > I
> > > > > think
> > > > > > > > > > we simply use the normal code path... That or I had some
> > > serious
> > > > > > > > > > hallucinations in the past months and imagined all this...
> > > > > > > > > >
> > > > > > > > > > On 7/26/07, *Martin Marinschek* <
> martin.marinschek@gmail.com
> > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > well, but this would then be portlet container
> dependent,
> > > > > right?
> > > > > > > > You'd
> > > > > > > > > > effectively need to implement trinidad skinning in
> every
> > > > > portlet
> > > > > > > > > > container.
> > > > > > > > > >
> > > > > > > > > > regards,
> > > > > > > > > >
> > > > > > > > > > Martin
> > > > > > > > > >
> > > > > > > > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > > > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > > > > > Personally, I don't see why the portal should not be
> > > able to
> > > > > > > > > > provide all
> > > > > > > > > > > selectors.
> > > > > > > > > > >
> > > > > > > > > > > Aren't we just not compressing the selector names
> when
> > > we
> > > > > detect
> > > > > > > > > > a portal
> > > > > > > > > > > environment or did I miss something? I think that
> > > strategy
> > > > > > > > > > cannot provides
> > > > > > > > > > > the icons though.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 7/26/07, Martin Marinschek <
> > > martin.marinschek@gmail.com
> > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > > > > Does the portlet container really provide every
> > > styleclass
> > > > > that
> > > > > > > > is
> > > > > > > > > > > > necessary for Trinidad components to look like
> they
> > > > > normally
> > > > > > > > look?
> > > > > > > > > > > >
> > > > > > > > > > > > I'm just thinking that what is currently being
> done is
> > > not
> > > > > > > > > > enough to
> > > > > > > > > > > > have the full skinning features available, and
> that
> > > going
> > > > > the
> > > > > > > > > > > > direction of adding the CSS dynamically would
> allow to
> > > do
> > > > > so.
> > > > > > > > > > > >
> > > > > > > > > > > > regards,
> > > > > > > > > > > >
> > > > > > > > > > > > Martin
> > > > > > > > > > > >
> > > > > > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> > > > > > > > > > <mailto: darkarena@gmail.com>> wrote:
> > > > > > > > > > > > > Hey Martin,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Does the simple-portlet skin render any better?
> I
> > > > > *THINK*
> > > > > > > > > > that when
> > > > > > > > > > > > > running in a portal environment you always get
> the
> > > > > > > > > > simple-portlet skin
> > > > > > > > > > > > > unless your portal provides one of the necessary
> > > skin
> > > > > > > > > > extensions which,
> > > > > > > > > > > > > right now, it trinidad proprietary. Maybe this
> is
> > > just
> > > > > a
> > > > > > > > > > case of us
> > > > > > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That article is interesting, but I think that
> > > Trinidad
> > > > > has
> > > > > > > > > > attempted to
> > > > > > > > > > > > > do the same thing only in a different way.
> Instead
> > > of
> > > > > using
> > > > > > > > > > javascript
> > > > > > > > > > > > > to copy in the styles, we actually change the
> class
> > > > > names
> > > > > > > > > > that get
> > > > > > > > > > > > > rendered on the client to use the portal styles
> > > where
> > > > > > > > > > appropriate.
> > > > > > > > > > > > > Still, I'm not sure that this has been tested
> > > > > extensively
> > > > > > > > > > because before
> > > > > > > > > > > > > we started looking at 301, much of Trinidad's
> portal
> > > > > work
> > > > > > > > > > has been done
> > > > > > > > > > > > > with a Proof of Concept environment.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Scott
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > <
> > > > >
> > >
> 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
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > 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
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Adam Winer <aw...@gmail.com>.
I'm thinking that in Trinidad 1.0.3, we can add a new method
to RenderingContext:
/**
* Initialize the RenderingContext if it has not already been initialized.
* This method is allowed to render HTML, and will typically be first
* called inside of a <head> element, but may be called later if Trinidad
* is not used to render the <head> element.
*/
public void init(FacesContext context, UIComponent component)
so that CoreRenderer.encodeBegin() becomes:
if (!getRendersChildren())
{
RenderingContext arc = RenderingContext.getCurrentInstance();
if (arc == null)
throw new IllegalStateException(_LOG.getMessage(
"NO_RENDERINGCONTEXT"));
arc.init(context, component);
FacesBean bean = getFacesBean(component);
encodeBegin(context, arc, component, bean);
}
+ similar code in encodeEnd() for rendersChildren==true,
and init() is super-cheap if it's already been called. (Minor
wrinkle - we have to block this CoreRenderer code in
DocumentRenderer, so that the init() call can be called exactly
during <head>, and not before we even write out <html>.)
-- Adam
On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> One way would be to have something along those line:
>
> CoreRenderer.java
>
> public void encodeBegin(FacesContext context, UIComponent component)
> {
> if (isPortlet(context) && !isXhtmlRootElement() && !isStyleSheetCopied())
> {
> pushStyleSheet(context);
> }
>
> // Do normal processing
> }
>
> protected abstract boolean isXhtmlRootElement();
>
> Then we would simply have to make isXhtmlRootElement() return true for
> document, head and body renderers and false for the others. But it's not
> extremely clean.
>
>
> Regards,
>
> ~ Simon
>
>
> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > Sure, it would be better for the user if it works out of the box.
> >
> > As much as I think, I don't find a central place where to put it, though.
> >
> > Ideas anyone?
> >
> > regards,
> >
> > Martin
> >
> > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > Hello Martin,
> > >
> > > Yeah I thought about a new component and we actually already have
> > > <trh:styleSheet/> that could be slightly altered to do that work, but I
> > > would prefer a way not involving any action from users.
> > >
> > >
> > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > Hi Simon,
> > > >
> > > > true. The form-render was good for my nice small example, but is no
> > > > general solution of course.
> > > >
> > > > I wonder if this would mandate a special component which does nothing
> > > > but adding the stylesheet to the head?
> > > >
> > > > Eventually, the component could be generalized, so that all kinds of
> > > > stylesheets can be added, if a link is provided and the stylesheet
> > > > hasn't been added so far - I think this solution might be interesting
> > > > for the portlet-developer in general.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > > > Issue with #3 is not very hard, we already have a RenderingContext
> that
> > > can
> > > > > be used for that. We could probably hook that code in CoreRenderer
> or
> > > > > XhtmlRenderer. The only issue left then would be to not have
> document,
> > > head
> > > > > and body renderer to execute it. Placing it in FormRenderer only
> does
> > > not
> > > > > seems right in case your page does not contain a form at all or use
> a
> > > basic
> > > > > JSF form (extremely unlikely though).
> > > > >
> > > > >
> > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > > For the discussion on if and how to integrate this into Trinidad -
> I
> > > > > > see three cases:
> > > > > >
> > > > > > 1) people only want basic skinning, Trinidad uses simple.portlet,
> and
> > > > > > emits portlet-standard compliant skinning hooks
> > > > > >
> > > > > > 2) people want normal Trinidad skinning, portlet container
> provides
> > > > > > CSS file in the head, Trinidad doesn't have to do anything
> (especially
> > > > > > not switch to portlet-standard compliant skinning hooks)
> > > > > >
> > > > > > 3) people want Trinidad skinning, portlet container does not
> provide
> > > > > > the CSS file, Trinidad portlet needs to add the CSS file with
> > > > > > JavaScript itself. Issue to solve: CSS file needs to be added only
> > > > > > once.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com >
> wrote:
> > > > > > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > > > > > > Thus linking Portal-Trinidad users to specific portal
> vendor(s)...
> > > Ok,
> > > > > I see
> > > > > > > > the issue now... bleh...
> > > > > > > >
> > > > > > > >
> > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> > > > > > > > > Simon, you are correct. The portal would be able to push a
> > > > > parameter to
> > > > > > > > > Trinidad. Always in a portal environment the skin is
> > > uncompressed
> > > > > so
> > > > > > > > > that is also not an issue. But currently changing the
> > > stylesheet
> > > > > > > > > provided by the Portal is a modification that needs to be
> made
> > > to
> > > > > the
> > > > > > > > > portal itself. I think that's where Martin is coming
> from. An
> > > > > > > > > unmodified portal container doesn't look very good when
> > > displaying
> > > > > faces
> > > > > > > > > and forcing every portal container to provide a skin that is
> not
> > > > > based
> > > > > > > > > off a standard is not going to be very successful in the
> general
> > > > > case.
> > > > > > > > > I totally agree with this, but we're sort of between a rock
> and
> > > a
> > > > > hard
> > > > > > > > > place. :)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Simon Lessard wrote:
> > > > > > > > > > Not really, I think we detect a specific parameter pushed
> by
> > > the
> > > > > > > > > > container. So only container supporting skinning would
> push
> > > it,
> > > > > > > > > > effectively synchronizing all portlet LaF. For other
> container
> > > I
> > > > > think
> > > > > > > > > > we simply use the normal code path... That or I had some
> > > serious
> > > > > > > > > > hallucinations in the past months and imagined all this...
> > > > > > > > > >
> > > > > > > > > > On 7/26/07, *Martin Marinschek* <
> martin.marinschek@gmail.com
> > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > well, but this would then be portlet container
> dependent,
> > > > > right?
> > > > > > > > You'd
> > > > > > > > > > effectively need to implement trinidad skinning in
> every
> > > > > portlet
> > > > > > > > > > container.
> > > > > > > > > >
> > > > > > > > > > regards,
> > > > > > > > > >
> > > > > > > > > > Martin
> > > > > > > > > >
> > > > > > > > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > > > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > > > > > Personally, I don't see why the portal should not be
> > > able to
> > > > > > > > > > provide all
> > > > > > > > > > > selectors.
> > > > > > > > > > >
> > > > > > > > > > > Aren't we just not compressing the selector names
> when
> > > we
> > > > > detect
> > > > > > > > > > a portal
> > > > > > > > > > > environment or did I miss something? I think that
> > > strategy
> > > > > > > > > > cannot provides
> > > > > > > > > > > the icons though.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 7/26/07, Martin Marinschek <
> > > martin.marinschek@gmail.com
> > > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > > > > > Does the portlet container really provide every
> > > styleclass
> > > > > that
> > > > > > > > is
> > > > > > > > > > > > necessary for Trinidad components to look like
> they
> > > > > normally
> > > > > > > > look?
> > > > > > > > > > > >
> > > > > > > > > > > > I'm just thinking that what is currently being
> done is
> > > not
> > > > > > > > > > enough to
> > > > > > > > > > > > have the full skinning features available, and
> that
> > > going
> > > > > the
> > > > > > > > > > > > direction of adding the CSS dynamically would
> allow to
> > > do
> > > > > so.
> > > > > > > > > > > >
> > > > > > > > > > > > regards,
> > > > > > > > > > > >
> > > > > > > > > > > > Martin
> > > > > > > > > > > >
> > > > > > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> > > > > > > > > > <mailto: darkarena@gmail.com>> wrote:
> > > > > > > > > > > > > Hey Martin,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Does the simple-portlet skin render any
> better? I
> > > > > *THINK*
> > > > > > > > > > that when
> > > > > > > > > > > > > running in a portal environment you always get
> the
> > > > > > > > > > simple-portlet skin
> > > > > > > > > > > > > unless your portal provides one of the necessary
> > > skin
> > > > > > > > > > extensions which,
> > > > > > > > > > > > > right now, it trinidad proprietary. Maybe this
> is
> > > just
> > > > > a
> > > > > > > > > > case of us
> > > > > > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That article is interesting, but I think that
> > > Trinidad
> > > > > has
> > > > > > > > > > attempted to
> > > > > > > > > > > > > do the same thing only in a different
> way. Instead
> > > of
> > > > > using
> > > > > > > > > > javascript
> > > > > > > > > > > > > to copy in the styles, we actually change the
> class
> > > > > names
> > > > > > > > > > that get
> > > > > > > > > > > > > rendered on the client to use the portal styles
> > > where
> > > > > > > > > > appropriate.
> > > > > > > > > > > > > Still, I'm not sure that this has been tested
> > > > > extensively
> > > > > > > > > > because before
> > > > > > > > > > > > > we started looking at 301, much of Trinidad's
> portal
> > > > > work
> > > > > > > > > > has been done
> > > > > > > > > > > > > with a Proof of Concept environment.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Scott
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > <
> > > > >
> > >
> 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
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > 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
> >
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
One way would be to have something along those line:
CoreRenderer.java
public void encodeBegin(FacesContext context, UIComponent component)
{
if (isPortlet(context) && !isXhtmlRootElement() && !isStyleSheetCopied())
{
pushStyleSheet(context);
}
// Do normal processing
}
protected abstract boolean isXhtmlRootElement();
Then we would simply have to make isXhtmlRootElement() return true for
document, head and body renderers and false for the others. But it's not
extremely clean.
Regards,
~ Simon
On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> Sure, it would be better for the user if it works out of the box.
>
> As much as I think, I don't find a central place where to put it, though.
>
> Ideas anyone?
>
> regards,
>
> Martin
>
> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > Hello Martin,
> >
> > Yeah I thought about a new component and we actually already have
> > <trh:styleSheet/> that could be slightly altered to do that work, but I
> > would prefer a way not involving any action from users.
> >
> >
> > On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > > Hi Simon,
> > >
> > > true. The form-render was good for my nice small example, but is no
> > > general solution of course.
> > >
> > > I wonder if this would mandate a special component which does nothing
> > > but adding the stylesheet to the head?
> > >
> > > Eventually, the component could be generalized, so that all kinds of
> > > stylesheets can be added, if a link is provided and the stylesheet
> > > hasn't been added so far - I think this solution might be interesting
> > > for the portlet-developer in general.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > > Issue with #3 is not very hard, we already have a RenderingContext
> that
> > can
> > > > be used for that. We could probably hook that code in CoreRenderer
> or
> > > > XhtmlRenderer. The only issue left then would be to not have
> document,
> > head
> > > > and body renderer to execute it. Placing it in FormRenderer only
> does
> > not
> > > > seems right in case your page does not contain a form at all or use
> a
> > basic
> > > > JSF form (extremely unlikely though).
> > > >
> > > >
> > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > For the discussion on if and how to integrate this into Trinidad -
> I
> > > > > see three cases:
> > > > >
> > > > > 1) people only want basic skinning, Trinidad uses simple.portlet,
> and
> > > > > emits portlet-standard compliant skinning hooks
> > > > >
> > > > > 2) people want normal Trinidad skinning, portlet container
> provides
> > > > > CSS file in the head, Trinidad doesn't have to do anything
> (especially
> > > > > not switch to portlet-standard compliant skinning hooks)
> > > > >
> > > > > 3) people want Trinidad skinning, portlet container does not
> provide
> > > > > the CSS file, Trinidad portlet needs to add the CSS file with
> > > > > JavaScript itself. Issue to solve: CSS file needs to be added only
> > > > > once.
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com>
> wrote:
> > > > > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > > > > > Thus linking Portal-Trinidad users to specific portal
> vendor(s)...
> > Ok,
> > > > I see
> > > > > > > the issue now... bleh...
> > > > > > >
> > > > > > >
> > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> > > > > > > > Simon, you are correct. The portal would be able to push a
> > > > parameter to
> > > > > > > > Trinidad. Always in a portal environment the skin is
> > uncompressed
> > > > so
> > > > > > > > that is also not an issue. But currently changing the
> > stylesheet
> > > > > > > > provided by the Portal is a modification that needs to be
> made
> > to
> > > > the
> > > > > > > > portal itself. I think that's where Martin is coming
> from. An
> > > > > > > > unmodified portal container doesn't look very good when
> > displaying
> > > > faces
> > > > > > > > and forcing every portal container to provide a skin that is
> not
> > > > based
> > > > > > > > off a standard is not going to be very successful in the
> general
> > > > case.
> > > > > > > > I totally agree with this, but we're sort of between a rock
> and
> > a
> > > > hard
> > > > > > > > place. :)
> > > > > > > >
> > > > > > > >
> > > > > > > > Simon Lessard wrote:
> > > > > > > > > Not really, I think we detect a specific parameter pushed
> by
> > the
> > > > > > > > > container. So only container supporting skinning would
> push
> > it,
> > > > > > > > > effectively synchronizing all portlet LaF. For other
> container
> > I
> > > > think
> > > > > > > > > we simply use the normal code path... That or I had some
> > serious
> > > > > > > > > hallucinations in the past months and imagined all this...
> > > > > > > > >
> > > > > > > > > On 7/26/07, *Martin Marinschek* <
> martin.marinschek@gmail.com
> > > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > well, but this would then be portlet container
> dependent,
> > > > right?
> > > > > > > You'd
> > > > > > > > > effectively need to implement trinidad skinning in
> every
> > > > portlet
> > > > > > > > > container.
> > > > > > > > >
> > > > > > > > > regards,
> > > > > > > > >
> > > > > > > > > Martin
> > > > > > > > >
> > > > > > > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > > > > Personally, I don't see why the portal should not be
> > able to
> > > > > > > > > provide all
> > > > > > > > > > selectors.
> > > > > > > > > >
> > > > > > > > > > Aren't we just not compressing the selector names
> when
> > we
> > > > detect
> > > > > > > > > a portal
> > > > > > > > > > environment or did I miss something? I think that
> > strategy
> > > > > > > > > cannot provides
> > > > > > > > > > the icons though.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 7/26/07, Martin Marinschek <
> > martin.marinschek@gmail.com
> > > > > > > > > <mailto: martin.marinschek@gmail.com>> wrote:
> > > > > > > > > > > Does the portlet container really provide every
> > styleclass
> > > > that
> > > > > > > is
> > > > > > > > > > > necessary for Trinidad components to look like
> they
> > > > normally
> > > > > > > look?
> > > > > > > > > > >
> > > > > > > > > > > I'm just thinking that what is currently being
> done is
> > not
> > > > > > > > > enough to
> > > > > > > > > > > have the full skinning features available, and
> that
> > going
> > > > the
> > > > > > > > > > > direction of adding the CSS dynamically would
> allow to
> > do
> > > > so.
> > > > > > > > > > >
> > > > > > > > > > > regards,
> > > > > > > > > > >
> > > > > > > > > > > Martin
> > > > > > > > > > >
> > > > > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> > > > > > > > > <ma...@gmail.com>> wrote:
> > > > > > > > > > > > Hey Martin,
> > > > > > > > > > > >
> > > > > > > > > > > > Does the simple-portlet skin render any
> better? I
> > > > *THINK*
> > > > > > > > > that when
> > > > > > > > > > > > running in a portal environment you always get
> the
> > > > > > > > > simple-portlet skin
> > > > > > > > > > > > unless your portal provides one of the necessary
> > skin
> > > > > > > > > extensions which,
> > > > > > > > > > > > right now, it trinidad proprietary. Maybe this
> is
> > just
> > > > a
> > > > > > > > > case of us
> > > > > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > > > > >
> > > > > > > > > > > > That article is interesting, but I think that
> > Trinidad
> > > > has
> > > > > > > > > attempted to
> > > > > > > > > > > > do the same thing only in a different
> way. Instead
> > of
> > > > using
> > > > > > > > > javascript
> > > > > > > > > > > > to copy in the styles, we actually change the
> class
> > > > names
> > > > > > > > > that get
> > > > > > > > > > > > rendered on the client to use the portal styles
> > where
> > > > > > > > > appropriate.
> > > > > > > > > > > > Still, I'm not sure that this has been tested
> > > > extensively
> > > > > > > > > because before
> > > > > > > > > > > > we started looking at 301, much of Trinidad's
> portal
> > > > work
> > > > > > > > > has been done
> > > > > > > > > > > > with a Proof of Concept environment.
> > > > > > > > > > > >
> > > > > > > > > > > > Scott
> > > > > > > > > > > >
> > > > > > > > > > > > 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
> > > > > > > > >
> > > > > > > <
> > > >
> > 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
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > 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
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
Sure, it would be better for the user if it works out of the box.
As much as I think, I don't find a central place where to put it, though.
Ideas anyone?
regards,
Martin
On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> Hello Martin,
>
> Yeah I thought about a new component and we actually already have
> <trh:styleSheet/> that could be slightly altered to do that work, but I
> would prefer a way not involving any action from users.
>
>
> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > Hi Simon,
> >
> > true. The form-render was good for my nice small example, but is no
> > general solution of course.
> >
> > I wonder if this would mandate a special component which does nothing
> > but adding the stylesheet to the head?
> >
> > Eventually, the component could be generalized, so that all kinds of
> > stylesheets can be added, if a link is provided and the stylesheet
> > hasn't been added so far - I think this solution might be interesting
> > for the portlet-developer in general.
> >
> > regards,
> >
> > Martin
> >
> > On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > > Issue with #3 is not very hard, we already have a RenderingContext that
> can
> > > be used for that. We could probably hook that code in CoreRenderer or
> > > XhtmlRenderer. The only issue left then would be to not have document,
> head
> > > and body renderer to execute it. Placing it in FormRenderer only does
> not
> > > seems right in case your page does not contain a form at all or use a
> basic
> > > JSF form (extremely unlikely though).
> > >
> > >
> > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > For the discussion on if and how to integrate this into Trinidad - I
> > > > see three cases:
> > > >
> > > > 1) people only want basic skinning, Trinidad uses simple.portlet, and
> > > > emits portlet-standard compliant skinning hooks
> > > >
> > > > 2) people want normal Trinidad skinning, portlet container provides
> > > > CSS file in the head, Trinidad doesn't have to do anything (especially
> > > > not switch to portlet-standard compliant skinning hooks)
> > > >
> > > > 3) people want Trinidad skinning, portlet container does not provide
> > > > the CSS file, Trinidad portlet needs to add the CSS file with
> > > > JavaScript itself. Issue to solve: CSS file needs to be added only
> > > > once.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > > > > Thus linking Portal-Trinidad users to specific portal vendor(s)...
> Ok,
> > > I see
> > > > > > the issue now... bleh...
> > > > > >
> > > > > >
> > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com > wrote:
> > > > > > > Simon, you are correct. The portal would be able to push a
> > > parameter to
> > > > > > > Trinidad. Always in a portal environment the skin is
> uncompressed
> > > so
> > > > > > > that is also not an issue. But currently changing the
> stylesheet
> > > > > > > provided by the Portal is a modification that needs to be made
> to
> > > the
> > > > > > > portal itself. I think that's where Martin is coming from. An
> > > > > > > unmodified portal container doesn't look very good when
> displaying
> > > faces
> > > > > > > and forcing every portal container to provide a skin that is not
> > > based
> > > > > > > off a standard is not going to be very successful in the general
> > > case.
> > > > > > > I totally agree with this, but we're sort of between a rock and
> a
> > > hard
> > > > > > > place. :)
> > > > > > >
> > > > > > >
> > > > > > > Simon Lessard wrote:
> > > > > > > > Not really, I think we detect a specific parameter pushed by
> the
> > > > > > > > container. So only container supporting skinning would push
> it,
> > > > > > > > effectively synchronizing all portlet LaF. For other container
> I
> > > think
> > > > > > > > we simply use the normal code path... That or I had some
> serious
> > > > > > > > hallucinations in the past months and imagined all this...
> > > > > > > >
> > > > > > > > On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> > > > > > > > <mailto: martin.marinschek@gmail.com >> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > well, but this would then be portlet container dependent,
> > > right?
> > > > > > You'd
> > > > > > > > effectively need to implement trinidad skinning in every
> > > portlet
> > > > > > > > container.
> > > > > > > >
> > > > > > > > regards,
> > > > > > > >
> > > > > > > > Martin
> > > > > > > >
> > > > > > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > > > Personally, I don't see why the portal should not be
> able to
> > > > > > > > provide all
> > > > > > > > > selectors.
> > > > > > > > >
> > > > > > > > > Aren't we just not compressing the selector names when
> we
> > > detect
> > > > > > > > a portal
> > > > > > > > > environment or did I miss something? I think that
> strategy
> > > > > > > > cannot provides
> > > > > > > > > the icons though.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 7/26/07, Martin Marinschek <
> martin.marinschek@gmail.com
> > > > > > > > <mailto: martin.marinschek@gmail.com>> wrote:
> > > > > > > > > > Does the portlet container really provide every
> styleclass
> > > that
> > > > > > is
> > > > > > > > > > necessary for Trinidad components to look like they
> > > normally
> > > > > > look?
> > > > > > > > > >
> > > > > > > > > > I'm just thinking that what is currently being done is
> not
> > > > > > > > enough to
> > > > > > > > > > have the full skinning features available, and that
> going
> > > the
> > > > > > > > > > direction of adding the CSS dynamically would allow to
> do
> > > so.
> > > > > > > > > >
> > > > > > > > > > regards,
> > > > > > > > > >
> > > > > > > > > > Martin
> > > > > > > > > >
> > > > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> > > > > > > > <ma...@gmail.com>> wrote:
> > > > > > > > > > > Hey Martin,
> > > > > > > > > > >
> > > > > > > > > > > Does the simple-portlet skin render any better? I
> > > *THINK*
> > > > > > > > that when
> > > > > > > > > > > running in a portal environment you always get the
> > > > > > > > simple-portlet skin
> > > > > > > > > > > unless your portal provides one of the necessary
> skin
> > > > > > > > extensions which,
> > > > > > > > > > > right now, it trinidad proprietary. Maybe this is
> just
> > > a
> > > > > > > > case of us
> > > > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > > > >
> > > > > > > > > > > That article is interesting, but I think that
> Trinidad
> > > has
> > > > > > > > attempted to
> > > > > > > > > > > do the same thing only in a different way. Instead
> of
> > > using
> > > > > > > > javascript
> > > > > > > > > > > to copy in the styles, we actually change the class
> > > names
> > > > > > > > that get
> > > > > > > > > > > rendered on the client to use the portal styles
> where
> > > > > > > > appropriate.
> > > > > > > > > > > Still, I'm not sure that this has been tested
> > > extensively
> > > > > > > > because before
> > > > > > > > > > > we started looking at 301, much of Trinidad's portal
> > > work
> > > > > > > > has been done
> > > > > > > > > > > with a Proof of Concept environment.
> > > > > > > > > > >
> > > > > > > > > > > Scott
> > > > > > > > > > >
> > > > > > > > > > > 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
> > > > > > > >
> > > > > > <
> > >
> 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
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > 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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Hello Martin,
Yeah I thought about a new component and we actually already have
<trh:styleSheet/> that could be slightly altered to do that work, but I
would prefer a way not involving any action from users.
On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> Hi Simon,
>
> true. The form-render was good for my nice small example, but is no
> general solution of course.
>
> I wonder if this would mandate a special component which does nothing
> but adding the stylesheet to the head?
>
> Eventually, the component could be generalized, so that all kinds of
> stylesheets can be added, if a link is provided and the stylesheet
> hasn't been added so far - I think this solution might be interesting
> for the portlet-developer in general.
>
> regards,
>
> Martin
>
> On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> > Issue with #3 is not very hard, we already have a RenderingContext that
> can
> > be used for that. We could probably hook that code in CoreRenderer or
> > XhtmlRenderer. The only issue left then would be to not have document,
> head
> > and body renderer to execute it. Placing it in FormRenderer only does
> not
> > seems right in case your page does not contain a form at all or use a
> basic
> > JSF form (extremely unlikely though).
> >
> >
> > On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > > For the discussion on if and how to integrate this into Trinidad - I
> > > see three cases:
> > >
> > > 1) people only want basic skinning, Trinidad uses simple.portlet, and
> > > emits portlet-standard compliant skinning hooks
> > >
> > > 2) people want normal Trinidad skinning, portlet container provides
> > > CSS file in the head, Trinidad doesn't have to do anything (especially
> > > not switch to portlet-standard compliant skinning hooks)
> > >
> > > 3) people want Trinidad skinning, portlet container does not provide
> > > the CSS file, Trinidad portlet needs to add the CSS file with
> > > JavaScript itself. Issue to solve: CSS file needs to be added only
> > > once.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > > > Thus linking Portal-Trinidad users to specific portal vendor(s)...
> Ok,
> > I see
> > > > > the issue now... bleh...
> > > > >
> > > > >
> > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com> wrote:
> > > > > > Simon, you are correct. The portal would be able to push a
> > parameter to
> > > > > > Trinidad. Always in a portal environment the skin is
> uncompressed
> > so
> > > > > > that is also not an issue. But currently changing the
> stylesheet
> > > > > > provided by the Portal is a modification that needs to be made
> to
> > the
> > > > > > portal itself. I think that's where Martin is coming from. An
> > > > > > unmodified portal container doesn't look very good when
> displaying
> > faces
> > > > > > and forcing every portal container to provide a skin that is not
> > based
> > > > > > off a standard is not going to be very successful in the general
> > case.
> > > > > > I totally agree with this, but we're sort of between a rock and
> a
> > hard
> > > > > > place. :)
> > > > > >
> > > > > >
> > > > > > Simon Lessard wrote:
> > > > > > > Not really, I think we detect a specific parameter pushed by
> the
> > > > > > > container. So only container supporting skinning would push
> it,
> > > > > > > effectively synchronizing all portlet LaF. For other container
> I
> > think
> > > > > > > we simply use the normal code path... That or I had some
> serious
> > > > > > > hallucinations in the past months and imagined all this...
> > > > > > >
> > > > > > > On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> > > > > > > <mailto:martin.marinschek@gmail.com >> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > well, but this would then be portlet container dependent,
> > right?
> > > > > You'd
> > > > > > > effectively need to implement trinidad skinning in every
> > portlet
> > > > > > > container.
> > > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > > Personally, I don't see why the portal should not be
> able to
> > > > > > > provide all
> > > > > > > > selectors.
> > > > > > > >
> > > > > > > > Aren't we just not compressing the selector names when
> we
> > detect
> > > > > > > a portal
> > > > > > > > environment or did I miss something? I think that
> strategy
> > > > > > > cannot provides
> > > > > > > > the icons though.
> > > > > > > >
> > > > > > > >
> > > > > > > > On 7/26/07, Martin Marinschek <
> martin.marinschek@gmail.com
> > > > > > > <mailto: martin.marinschek@gmail.com>> wrote:
> > > > > > > > > Does the portlet container really provide every
> styleclass
> > that
> > > > > is
> > > > > > > > > necessary for Trinidad components to look like they
> > normally
> > > > > look?
> > > > > > > > >
> > > > > > > > > I'm just thinking that what is currently being done is
> not
> > > > > > > enough to
> > > > > > > > > have the full skinning features available, and that
> going
> > the
> > > > > > > > > direction of adding the CSS dynamically would allow to
> do
> > so.
> > > > > > > > >
> > > > > > > > > regards,
> > > > > > > > >
> > > > > > > > > Martin
> > > > > > > > >
> > > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> > > > > > > <ma...@gmail.com>> wrote:
> > > > > > > > > > Hey Martin,
> > > > > > > > > >
> > > > > > > > > > Does the simple-portlet skin render any better? I
> > *THINK*
> > > > > > > that when
> > > > > > > > > > running in a portal environment you always get the
> > > > > > > simple-portlet skin
> > > > > > > > > > unless your portal provides one of the necessary
> skin
> > > > > > > extensions which,
> > > > > > > > > > right now, it trinidad proprietary. Maybe this is
> just
> > a
> > > > > > > case of us
> > > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > > >
> > > > > > > > > > That article is interesting, but I think that
> Trinidad
> > has
> > > > > > > attempted to
> > > > > > > > > > do the same thing only in a different way. Instead
> of
> > using
> > > > > > > javascript
> > > > > > > > > > to copy in the styles, we actually change the class
> > names
> > > > > > > that get
> > > > > > > > > > rendered on the client to use the portal styles
> where
> > > > > > > appropriate.
> > > > > > > > > > Still, I'm not sure that this has been tested
> > extensively
> > > > > > > because before
> > > > > > > > > > we started looking at 301, much of Trinidad's portal
> > work
> > > > > > > has been done
> > > > > > > > > > with a Proof of Concept environment.
> > > > > > > > > >
> > > > > > > > > > Scott
> > > > > > > > > >
> > > > > > > > > > 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
> > > > > > >
> > > > > <
> > 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
> > > >
> > >
> > >
> > > --
> > >
> > > 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
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Simon,
true. The form-render was good for my nice small example, but is no
general solution of course.
I wonder if this would mandate a special component which does nothing
but adding the stylesheet to the head?
Eventually, the component could be generalized, so that all kinds of
stylesheets can be added, if a link is provided and the stylesheet
hasn't been added so far - I think this solution might be interesting
for the portlet-developer in general.
regards,
Martin
On 7/27/07, Simon Lessard <si...@gmail.com> wrote:
> Issue with #3 is not very hard, we already have a RenderingContext that can
> be used for that. We could probably hook that code in CoreRenderer or
> XhtmlRenderer. The only issue left then would be to not have document, head
> and body renderer to execute it. Placing it in FormRenderer only does not
> seems right in case your page does not contain a form at all or use a basic
> JSF form (extremely unlikely though).
>
>
> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > For the discussion on if and how to integrate this into Trinidad - I
> > see three cases:
> >
> > 1) people only want basic skinning, Trinidad uses simple.portlet, and
> > emits portlet-standard compliant skinning hooks
> >
> > 2) people want normal Trinidad skinning, portlet container provides
> > CSS file in the head, Trinidad doesn't have to do anything (especially
> > not switch to portlet-standard compliant skinning hooks)
> >
> > 3) people want Trinidad skinning, portlet container does not provide
> > the CSS file, Trinidad portlet needs to add the CSS file with
> > JavaScript itself. Issue to solve: CSS file needs to be added only
> > once.
> >
> > regards,
> >
> > Martin
> >
> > On 7/27/07, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > 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/26/07, Simon Lessard < simon.lessard.3@gmail.com> wrote:
> > > > Thus linking Portal-Trinidad users to specific portal vendor(s)... Ok,
> I see
> > > > the issue now... bleh...
> > > >
> > > >
> > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com> wrote:
> > > > > Simon, you are correct. The portal would be able to push a
> parameter to
> > > > > Trinidad. Always in a portal environment the skin is uncompressed
> so
> > > > > that is also not an issue. But currently changing the stylesheet
> > > > > provided by the Portal is a modification that needs to be made to
> the
> > > > > portal itself. I think that's where Martin is coming from. An
> > > > > unmodified portal container doesn't look very good when displaying
> faces
> > > > > and forcing every portal container to provide a skin that is not
> based
> > > > > off a standard is not going to be very successful in the general
> case.
> > > > > I totally agree with this, but we're sort of between a rock and a
> hard
> > > > > place. :)
> > > > >
> > > > >
> > > > > Simon Lessard wrote:
> > > > > > Not really, I think we detect a specific parameter pushed by the
> > > > > > container. So only container supporting skinning would push it,
> > > > > > effectively synchronizing all portlet LaF. For other container I
> think
> > > > > > we simply use the normal code path... That or I had some serious
> > > > > > hallucinations in the past months and imagined all this...
> > > > > >
> > > > > > On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> > > > > > <mailto:martin.marinschek@gmail.com >> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > well, but this would then be portlet container dependent,
> right?
> > > > You'd
> > > > > > effectively need to implement trinidad skinning in every
> portlet
> > > > > > container.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > > Personally, I don't see why the portal should not be able to
> > > > > > provide all
> > > > > > > selectors.
> > > > > > >
> > > > > > > Aren't we just not compressing the selector names when we
> detect
> > > > > > a portal
> > > > > > > environment or did I miss something? I think that strategy
> > > > > > cannot provides
> > > > > > > the icons though.
> > > > > > >
> > > > > > >
> > > > > > > On 7/26/07, Martin Marinschek < martin.marinschek@gmail.com
> > > > > > <mailto: martin.marinschek@gmail.com>> wrote:
> > > > > > > > Does the portlet container really provide every styleclass
> that
> > > > is
> > > > > > > > necessary for Trinidad components to look like they
> normally
> > > > look?
> > > > > > > >
> > > > > > > > I'm just thinking that what is currently being done is not
> > > > > > enough to
> > > > > > > > have the full skinning features available, and that going
> the
> > > > > > > > direction of adding the CSS dynamically would allow to do
> so.
> > > > > > > >
> > > > > > > > regards,
> > > > > > > >
> > > > > > > > Martin
> > > > > > > >
> > > > > > > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com
> > > > > > <ma...@gmail.com>> wrote:
> > > > > > > > > Hey Martin,
> > > > > > > > >
> > > > > > > > > Does the simple-portlet skin render any better? I
> *THINK*
> > > > > > that when
> > > > > > > > > running in a portal environment you always get the
> > > > > > simple-portlet skin
> > > > > > > > > unless your portal provides one of the necessary skin
> > > > > > extensions which,
> > > > > > > > > right now, it trinidad proprietary. Maybe this is just
> a
> > > > > > case of us
> > > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > > >
> > > > > > > > > That article is interesting, but I think that Trinidad
> has
> > > > > > attempted to
> > > > > > > > > do the same thing only in a different way. Instead of
> using
> > > > > > javascript
> > > > > > > > > to copy in the styles, we actually change the class
> names
> > > > > > that get
> > > > > > > > > rendered on the client to use the portal styles where
> > > > > > appropriate.
> > > > > > > > > Still, I'm not sure that this has been tested
> extensively
> > > > > > because before
> > > > > > > > > we started looking at 301, much of Trinidad's portal
> work
> > > > > > has been done
> > > > > > > > > with a Proof of Concept environment.
> > > > > > > > >
> > > > > > > > > Scott
> > > > > > > > >
> > > > > > > > > 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
> > > > > >
> > > > <
> 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
> > >
> >
> >
> > --
> >
> > 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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Issue with #3 is not very hard, we already have a RenderingContext that can
be used for that. We could probably hook that code in CoreRenderer or
XhtmlRenderer. The only issue left then would be to not have document, head
and body renderer to execute it. Placing it in FormRenderer only does not
seems right in case your page does not contain a form at all or use a basic
JSF form (extremely unlikely though).
On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> For the discussion on if and how to integrate this into Trinidad - I
> see three cases:
>
> 1) people only want basic skinning, Trinidad uses simple.portlet, and
> emits portlet-standard compliant skinning hooks
>
> 2) people want normal Trinidad skinning, portlet container provides
> CSS file in the head, Trinidad doesn't have to do anything (especially
> not switch to portlet-standard compliant skinning hooks)
>
> 3) people want Trinidad skinning, portlet container does not provide
> the CSS file, Trinidad portlet needs to add the CSS file with
> JavaScript itself. Issue to solve: CSS file needs to be added only
> once.
>
> regards,
>
> Martin
>
> On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> > 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/26/07, Simon Lessard <si...@gmail.com> wrote:
> > > Thus linking Portal-Trinidad users to specific portal vendor(s)... Ok,
> I see
> > > the issue now... bleh...
> > >
> > >
> > > On 7/26/07, Scott O'Bryan < darkarena@gmail.com> wrote:
> > > > Simon, you are correct. The portal would be able to push a
> parameter to
> > > > Trinidad. Always in a portal environment the skin is uncompressed
> so
> > > > that is also not an issue. But currently changing the stylesheet
> > > > provided by the Portal is a modification that needs to be made to
> the
> > > > portal itself. I think that's where Martin is coming from. An
> > > > unmodified portal container doesn't look very good when displaying
> faces
> > > > and forcing every portal container to provide a skin that is not
> based
> > > > off a standard is not going to be very successful in the general
> case.
> > > > I totally agree with this, but we're sort of between a rock and a
> hard
> > > > place. :)
> > > >
> > > >
> > > > Simon Lessard wrote:
> > > > > Not really, I think we detect a specific parameter pushed by the
> > > > > container. So only container supporting skinning would push it,
> > > > > effectively synchronizing all portlet LaF. For other container I
> think
> > > > > we simply use the normal code path... That or I had some serious
> > > > > hallucinations in the past months and imagined all this...
> > > > >
> > > > > On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> > > > > <mailto:martin.marinschek@gmail.com >> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > well, but this would then be portlet container dependent,
> right?
> > > You'd
> > > > > effectively need to implement trinidad skinning in every
> portlet
> > > > > container.
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > > Personally, I don't see why the portal should not be able to
> > > > > provide all
> > > > > > selectors.
> > > > > >
> > > > > > Aren't we just not compressing the selector names when we
> detect
> > > > > a portal
> > > > > > environment or did I miss something? I think that strategy
> > > > > cannot provides
> > > > > > the icons though.
> > > > > >
> > > > > >
> > > > > > On 7/26/07, Martin Marinschek <martin.marinschek@gmail.com
> > > > > <mailto: martin.marinschek@gmail.com>> wrote:
> > > > > > > Does the portlet container really provide every styleclass
> that
> > > is
> > > > > > > necessary for Trinidad components to look like they
> normally
> > > look?
> > > > > > >
> > > > > > > I'm just thinking that what is currently being done is not
> > > > > enough to
> > > > > > > have the full skinning features available, and that going
> the
> > > > > > > direction of adding the CSS dynamically would allow to do
> so.
> > > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > On 7/26/07, Scott O'Bryan <darkarena@gmail.com
> > > > > <ma...@gmail.com>> wrote:
> > > > > > > > Hey Martin,
> > > > > > > >
> > > > > > > > Does the simple-portlet skin render any better? I
> *THINK*
> > > > > that when
> > > > > > > > running in a portal environment you always get the
> > > > > simple-portlet skin
> > > > > > > > unless your portal provides one of the necessary skin
> > > > > extensions which,
> > > > > > > > right now, it trinidad proprietary. Maybe this is just
> a
> > > > > case of us
> > > > > > > > needing to bug-fix the portlet skin.
> > > > > > > >
> > > > > > > > That article is interesting, but I think that Trinidad
> has
> > > > > attempted to
> > > > > > > > do the same thing only in a different way. Instead of
> using
> > > > > javascript
> > > > > > > > to copy in the styles, we actually change the class
> names
> > > > > that get
> > > > > > > > rendered on the client to use the portal styles where
> > > > > appropriate.
> > > > > > > > Still, I'm not sure that this has been tested
> extensively
> > > > > because before
> > > > > > > > we started looking at 301, much of Trinidad's portal
> work
> > > > > has been done
> > > > > > > > with a Proof of Concept environment.
> > > > > > > >
> > > > > > > > Scott
> > > > > > > >
> > > > > > > > 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
> > > > >
> > > <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
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
For the discussion on if and how to integrate this into Trinidad - I
see three cases:
1) people only want basic skinning, Trinidad uses simple.portlet, and
emits portlet-standard compliant skinning hooks
2) people want normal Trinidad skinning, portlet container provides
CSS file in the head, Trinidad doesn't have to do anything (especially
not switch to portlet-standard compliant skinning hooks)
3) people want Trinidad skinning, portlet container does not provide
the CSS file, Trinidad portlet needs to add the CSS file with
JavaScript itself. Issue to solve: CSS file needs to be added only
once.
regards,
Martin
On 7/27/07, Martin Marinschek <ma...@gmail.com> wrote:
> 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/26/07, Simon Lessard <si...@gmail.com> wrote:
> > Thus linking Portal-Trinidad users to specific portal vendor(s)... Ok, I see
> > the issue now... bleh...
> >
> >
> > On 7/26/07, Scott O'Bryan < darkarena@gmail.com> wrote:
> > > Simon, you are correct. The portal would be able to push a parameter to
> > > Trinidad. Always in a portal environment the skin is uncompressed so
> > > that is also not an issue. But currently changing the stylesheet
> > > provided by the Portal is a modification that needs to be made to the
> > > portal itself. I think that's where Martin is coming from. An
> > > unmodified portal container doesn't look very good when displaying faces
> > > and forcing every portal container to provide a skin that is not based
> > > off a standard is not going to be very successful in the general case.
> > > I totally agree with this, but we're sort of between a rock and a hard
> > > place. :)
> > >
> > >
> > > Simon Lessard wrote:
> > > > Not really, I think we detect a specific parameter pushed by the
> > > > container. So only container supporting skinning would push it,
> > > > effectively synchronizing all portlet LaF. For other container I think
> > > > we simply use the normal code path... That or I had some serious
> > > > hallucinations in the past months and imagined all this...
> > > >
> > > > On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> > > > <mailto:martin.marinschek@gmail.com >> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > well, but this would then be portlet container dependent, right?
> > You'd
> > > > effectively need to implement trinidad skinning in every portlet
> > > > container.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > > Personally, I don't see why the portal should not be able to
> > > > provide all
> > > > > selectors.
> > > > >
> > > > > Aren't we just not compressing the selector names when we detect
> > > > a portal
> > > > > environment or did I miss something? I think that strategy
> > > > cannot provides
> > > > > the icons though.
> > > > >
> > > > >
> > > > > On 7/26/07, Martin Marinschek <martin.marinschek@gmail.com
> > > > <mailto: martin.marinschek@gmail.com>> wrote:
> > > > > > Does the portlet container really provide every styleclass that
> > is
> > > > > > necessary for Trinidad components to look like they normally
> > look?
> > > > > >
> > > > > > I'm just thinking that what is currently being done is not
> > > > enough to
> > > > > > have the full skinning features available, and that going the
> > > > > > direction of adding the CSS dynamically would allow to do so.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 7/26/07, Scott O'Bryan <darkarena@gmail.com
> > > > <ma...@gmail.com>> wrote:
> > > > > > > Hey Martin,
> > > > > > >
> > > > > > > Does the simple-portlet skin render any better? I *THINK*
> > > > that when
> > > > > > > running in a portal environment you always get the
> > > > simple-portlet skin
> > > > > > > unless your portal provides one of the necessary skin
> > > > extensions which,
> > > > > > > right now, it trinidad proprietary. Maybe this is just a
> > > > case of us
> > > > > > > needing to bug-fix the portlet skin.
> > > > > > >
> > > > > > > That article is interesting, but I think that Trinidad has
> > > > attempted to
> > > > > > > do the same thing only in a different way. Instead of using
> > > > javascript
> > > > > > > to copy in the styles, we actually change the class names
> > > > that get
> > > > > > > rendered on the client to use the portal styles where
> > > > appropriate.
> > > > > > > Still, I'm not sure that this has been tested extensively
> > > > because before
> > > > > > > we started looking at 301, much of Trinidad's portal work
> > > > has been done
> > > > > > > with a Proof of Concept environment.
> > > > > > >
> > > > > > > Scott
> > > > > > >
> > > > > > > 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
> > > >
> > <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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
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/26/07, Simon Lessard <si...@gmail.com> wrote:
> Thus linking Portal-Trinidad users to specific portal vendor(s)... Ok, I see
> the issue now... bleh...
>
>
> On 7/26/07, Scott O'Bryan < darkarena@gmail.com> wrote:
> > Simon, you are correct. The portal would be able to push a parameter to
> > Trinidad. Always in a portal environment the skin is uncompressed so
> > that is also not an issue. But currently changing the stylesheet
> > provided by the Portal is a modification that needs to be made to the
> > portal itself. I think that's where Martin is coming from. An
> > unmodified portal container doesn't look very good when displaying faces
> > and forcing every portal container to provide a skin that is not based
> > off a standard is not going to be very successful in the general case.
> > I totally agree with this, but we're sort of between a rock and a hard
> > place. :)
> >
> >
> > Simon Lessard wrote:
> > > Not really, I think we detect a specific parameter pushed by the
> > > container. So only container supporting skinning would push it,
> > > effectively synchronizing all portlet LaF. For other container I think
> > > we simply use the normal code path... That or I had some serious
> > > hallucinations in the past months and imagined all this...
> > >
> > > On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> > > <mailto:martin.marinschek@gmail.com >> wrote:
> > >
> > > Hi Simon,
> > >
> > > well, but this would then be portlet container dependent, right?
> You'd
> > > effectively need to implement trinidad skinning in every portlet
> > > container.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > > <mailto: simon.lessard.3@gmail.com>> wrote:
> > > > Personally, I don't see why the portal should not be able to
> > > provide all
> > > > selectors.
> > > >
> > > > Aren't we just not compressing the selector names when we detect
> > > a portal
> > > > environment or did I miss something? I think that strategy
> > > cannot provides
> > > > the icons though.
> > > >
> > > >
> > > > On 7/26/07, Martin Marinschek <martin.marinschek@gmail.com
> > > <mailto: martin.marinschek@gmail.com>> wrote:
> > > > > Does the portlet container really provide every styleclass that
> is
> > > > > necessary for Trinidad components to look like they normally
> look?
> > > > >
> > > > > I'm just thinking that what is currently being done is not
> > > enough to
> > > > > have the full skinning features available, and that going the
> > > > > direction of adding the CSS dynamically would allow to do so.
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 7/26/07, Scott O'Bryan <darkarena@gmail.com
> > > <ma...@gmail.com>> wrote:
> > > > > > Hey Martin,
> > > > > >
> > > > > > Does the simple-portlet skin render any better? I *THINK*
> > > that when
> > > > > > running in a portal environment you always get the
> > > simple-portlet skin
> > > > > > unless your portal provides one of the necessary skin
> > > extensions which,
> > > > > > right now, it trinidad proprietary. Maybe this is just a
> > > case of us
> > > > > > needing to bug-fix the portlet skin.
> > > > > >
> > > > > > That article is interesting, but I think that Trinidad has
> > > attempted to
> > > > > > do the same thing only in a different way. Instead of using
> > > javascript
> > > > > > to copy in the styles, we actually change the class names
> > > that get
> > > > > > rendered on the client to use the portal styles where
> > > appropriate.
> > > > > > Still, I'm not sure that this has been tested extensively
> > > because before
> > > > > > we started looking at 301, much of Trinidad's portal work
> > > has been done
> > > > > > with a Proof of Concept environment.
> > > > > >
> > > > > > Scott
> > > > > >
> > > > > > 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
> > >
> <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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Thus linking Portal-Trinidad users to specific portal vendor(s)... Ok, I see
the issue now... bleh...
On 7/26/07, Scott O'Bryan <da...@gmail.com> wrote:
>
> Simon, you are correct. The portal would be able to push a parameter to
> Trinidad. Always in a portal environment the skin is uncompressed so
> that is also not an issue. But currently changing the stylesheet
> provided by the Portal is a modification that needs to be made to the
> portal itself. I think that's where Martin is coming from. An
> unmodified portal container doesn't look very good when displaying faces
> and forcing every portal container to provide a skin that is not based
> off a standard is not going to be very successful in the general case.
> I totally agree with this, but we're sort of between a rock and a hard
> place. :)
>
>
> Simon Lessard wrote:
> > Not really, I think we detect a specific parameter pushed by the
> > container. So only container supporting skinning would push it,
> > effectively synchronizing all portlet LaF. For other container I think
> > we simply use the normal code path... That or I had some serious
> > hallucinations in the past months and imagined all this...
> >
> > On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Hi Simon,
> >
> > well, but this would then be portlet container dependent, right?
> You'd
> > effectively need to implement trinidad skinning in every portlet
> > container.
> >
> > regards,
> >
> > Martin
> >
> > On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> > <ma...@gmail.com>> wrote:
> > > Personally, I don't see why the portal should not be able to
> > provide all
> > > selectors.
> > >
> > > Aren't we just not compressing the selector names when we detect
> > a portal
> > > environment or did I miss something? I think that strategy
> > cannot provides
> > > the icons though.
> > >
> > >
> > > On 7/26/07, Martin Marinschek <martin.marinschek@gmail.com
> > <ma...@gmail.com>> wrote:
> > > > Does the portlet container really provide every styleclass that
> is
> > > > necessary for Trinidad components to look like they normally
> look?
> > > >
> > > > I'm just thinking that what is currently being done is not
> > enough to
> > > > have the full skinning features available, and that going the
> > > > direction of adding the CSS dynamically would allow to do so.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/26/07, Scott O'Bryan <darkarena@gmail.com
> > <ma...@gmail.com>> wrote:
> > > > > Hey Martin,
> > > > >
> > > > > Does the simple-portlet skin render any better? I *THINK*
> > that when
> > > > > running in a portal environment you always get the
> > simple-portlet skin
> > > > > unless your portal provides one of the necessary skin
> > extensions which,
> > > > > right now, it trinidad proprietary. Maybe this is just a
> > case of us
> > > > > needing to bug-fix the portlet skin.
> > > > >
> > > > > That article is interesting, but I think that Trinidad has
> > attempted to
> > > > > do the same thing only in a different way. Instead of using
> > javascript
> > > > > to copy in the styles, we actually change the class names
> > that get
> > > > > rendered on the client to use the portal styles where
> > appropriate.
> > > > > Still, I'm not sure that this has been tested extensively
> > because before
> > > > > we started looking at 301, much of Trinidad's portal work
> > has been done
> > > > > with a Proof of Concept environment.
> > > > >
> > > > > Scott
> > > > >
> > > > > 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
> > <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
> >
> >
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
Simon, you are correct. The portal would be able to push a parameter to
Trinidad. Always in a portal environment the skin is uncompressed so
that is also not an issue. But currently changing the stylesheet
provided by the Portal is a modification that needs to be made to the
portal itself. I think that's where Martin is coming from. An
unmodified portal container doesn't look very good when displaying faces
and forcing every portal container to provide a skin that is not based
off a standard is not going to be very successful in the general case.
I totally agree with this, but we're sort of between a rock and a hard
place. :)
Simon Lessard wrote:
> Not really, I think we detect a specific parameter pushed by the
> container. So only container supporting skinning would push it,
> effectively synchronizing all portlet LaF. For other container I think
> we simply use the normal code path... That or I had some serious
> hallucinations in the past months and imagined all this...
>
> On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi Simon,
>
> well, but this would then be portlet container dependent, right? You'd
> effectively need to implement trinidad skinning in every portlet
> container.
>
> regards,
>
> Martin
>
> On 7/26/07, Simon Lessard < simon.lessard.3@gmail.com
> <ma...@gmail.com>> wrote:
> > Personally, I don't see why the portal should not be able to
> provide all
> > selectors.
> >
> > Aren't we just not compressing the selector names when we detect
> a portal
> > environment or did I miss something? I think that strategy
> cannot provides
> > the icons though.
> >
> >
> > On 7/26/07, Martin Marinschek <martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
> > > Does the portlet container really provide every styleclass that is
> > > necessary for Trinidad components to look like they normally look?
> > >
> > > I'm just thinking that what is currently being done is not
> enough to
> > > have the full skinning features available, and that going the
> > > direction of adding the CSS dynamically would allow to do so.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/26/07, Scott O'Bryan <darkarena@gmail.com
> <ma...@gmail.com>> wrote:
> > > > Hey Martin,
> > > >
> > > > Does the simple-portlet skin render any better? I *THINK*
> that when
> > > > running in a portal environment you always get the
> simple-portlet skin
> > > > unless your portal provides one of the necessary skin
> extensions which,
> > > > right now, it trinidad proprietary. Maybe this is just a
> case of us
> > > > needing to bug-fix the portlet skin.
> > > >
> > > > That article is interesting, but I think that Trinidad has
> attempted to
> > > > do the same thing only in a different way. Instead of using
> javascript
> > > > to copy in the styles, we actually change the class names
> that get
> > > > rendered on the client to use the portal styles where
> appropriate.
> > > > Still, I'm not sure that this has been tested extensively
> because before
> > > > we started looking at 301, much of Trinidad's portal work
> has been done
> > > > with a Proof of Concept environment.
> > > >
> > > > Scott
> > > >
> > > > 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
> <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
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Not really, I think we detect a specific parameter pushed by the container.
So only container supporting skinning would push it, effectively
synchronizing all portlet LaF. For other container I think we simply use the
normal code path... That or I had some serious hallucinations in the past
months and imagined all this...
On 7/26/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> Hi Simon,
>
> well, but this would then be portlet container dependent, right? You'd
> effectively need to implement trinidad skinning in every portlet
> container.
>
> regards,
>
> Martin
>
> On 7/26/07, Simon Lessard <si...@gmail.com> wrote:
> > Personally, I don't see why the portal should not be able to provide all
> > selectors.
> >
> > Aren't we just not compressing the selector names when we detect a
> portal
> > environment or did I miss something? I think that strategy cannot
> provides
> > the icons though.
> >
> >
> > On 7/26/07, Martin Marinschek <ma...@gmail.com> wrote:
> > > Does the portlet container really provide every styleclass that is
> > > necessary for Trinidad components to look like they normally look?
> > >
> > > I'm just thinking that what is currently being done is not enough to
> > > have the full skinning features available, and that going the
> > > direction of adding the CSS dynamically would allow to do so.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/26/07, Scott O'Bryan <da...@gmail.com> wrote:
> > > > Hey Martin,
> > > >
> > > > Does the simple-portlet skin render any better? I *THINK* that when
> > > > running in a portal environment you always get the simple-portlet
> skin
> > > > unless your portal provides one of the necessary skin extensions
> which,
> > > > right now, it trinidad proprietary. Maybe this is just a case of us
> > > > needing to bug-fix the portlet skin.
> > > >
> > > > That article is interesting, but I think that Trinidad has attempted
> to
> > > > do the same thing only in a different way. Instead of using
> javascript
> > > > to copy in the styles, we actually change the class names that get
> > > > rendered on the client to use the portal styles where appropriate.
> > > > Still, I'm not sure that this has been tested extensively because
> before
> > > > we started looking at 301, much of Trinidad's portal work has been
> done
> > > > with a Proof of Concept environment.
> > > >
> > > > Scott
> > > >
> > > > 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
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Simon,
well, but this would then be portlet container dependent, right? You'd
effectively need to implement trinidad skinning in every portlet
container.
regards,
Martin
On 7/26/07, Simon Lessard <si...@gmail.com> wrote:
> Personally, I don't see why the portal should not be able to provide all
> selectors.
>
> Aren't we just not compressing the selector names when we detect a portal
> environment or did I miss something? I think that strategy cannot provides
> the icons though.
>
>
> On 7/26/07, Martin Marinschek <ma...@gmail.com> wrote:
> > Does the portlet container really provide every styleclass that is
> > necessary for Trinidad components to look like they normally look?
> >
> > I'm just thinking that what is currently being done is not enough to
> > have the full skinning features available, and that going the
> > direction of adding the CSS dynamically would allow to do so.
> >
> > regards,
> >
> > Martin
> >
> > On 7/26/07, Scott O'Bryan <da...@gmail.com> wrote:
> > > Hey Martin,
> > >
> > > Does the simple-portlet skin render any better? I *THINK* that when
> > > running in a portal environment you always get the simple-portlet skin
> > > unless your portal provides one of the necessary skin extensions which,
> > > right now, it trinidad proprietary. Maybe this is just a case of us
> > > needing to bug-fix the portlet skin.
> > >
> > > That article is interesting, but I think that Trinidad has attempted to
> > > do the same thing only in a different way. Instead of using javascript
> > > to copy in the styles, we actually change the class names that get
> > > rendered on the client to use the portal styles where appropriate.
> > > Still, I'm not sure that this has been tested extensively because before
> > > we started looking at 301, much of Trinidad's portal work has been done
> > > with a Proof of Concept environment.
> > >
> > > Scott
> > >
> > > 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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
Simon, jsr-168 defines only a handful of styles. Indeed if the portal
wants to provide a full, uncompressed, trinidad skin, there are ways of
turning off our rendering of the stylesheet. There are some additional
complexities we are trying to work out regarding this very usecase, but
one cannot take a stock JSR-168 portal and have it work without the
styling extensions being provided.
Simon Lessard wrote:
> Personally, I don't see why the portal should not be able to provide
> all selectors.
>
> Aren't we just not compressing the selector names when we detect a
> portal environment or did I miss something? I think that strategy
> cannot provides the icons though.
>
> On 7/26/07, *Martin Marinschek* <martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
>
> Does the portlet container really provide every styleclass that is
> necessary for Trinidad components to look like they normally look?
>
> I'm just thinking that what is currently being done is not enough to
> have the full skinning features available, and that going the
> direction of adding the CSS dynamically would allow to do so.
>
> regards,
>
> Martin
>
> On 7/26/07, Scott O'Bryan <darkarena@gmail.com
> <ma...@gmail.com>> wrote:
> > Hey Martin,
> >
> > Does the simple-portlet skin render any better? I *THINK* that when
> > running in a portal environment you always get the
> simple-portlet skin
> > unless your portal provides one of the necessary skin extensions
> which,
> > right now, it trinidad proprietary. Maybe this is just a case of us
> > needing to bug-fix the portlet skin.
> >
> > That article is interesting, but I think that Trinidad has
> attempted to
> > do the same thing only in a different way. Instead of using
> javascript
> > to copy in the styles, we actually change the class names that get
> > rendered on the client to use the portal styles where appropriate.
> > Still, I'm not sure that this has been tested extensively
> because before
> > we started looking at 301, much of Trinidad's portal work has
> been done
> > with a Proof of Concept environment.
> >
> > Scott
> >
> > 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
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Simon Lessard <si...@gmail.com>.
Personally, I don't see why the portal should not be able to provide all
selectors.
Aren't we just not compressing the selector names when we detect a portal
environment or did I miss something? I think that strategy cannot provides
the icons though.
On 7/26/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> Does the portlet container really provide every styleclass that is
> necessary for Trinidad components to look like they normally look?
>
> I'm just thinking that what is currently being done is not enough to
> have the full skinning features available, and that going the
> direction of adding the CSS dynamically would allow to do so.
>
> regards,
>
> Martin
>
> On 7/26/07, Scott O'Bryan <da...@gmail.com> wrote:
> > Hey Martin,
> >
> > Does the simple-portlet skin render any better? I *THINK* that when
> > running in a portal environment you always get the simple-portlet skin
> > unless your portal provides one of the necessary skin extensions which,
> > right now, it trinidad proprietary. Maybe this is just a case of us
> > needing to bug-fix the portlet skin.
> >
> > That article is interesting, but I think that Trinidad has attempted to
> > do the same thing only in a different way. Instead of using javascript
> > to copy in the styles, we actually change the class names that get
> > rendered on the client to use the portal styles where appropriate.
> > Still, I'm not sure that this has been tested extensively because before
> > we started looking at 301, much of Trinidad's portal work has been done
> > with a Proof of Concept environment.
> >
> > Scott
> >
> > 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
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
No it doesn't. There is a simple portal skin that provides the
additional styling needed. But it's made to be very simple.
Martin Marinschek wrote:
> Does the portlet container really provide every styleclass that is
> necessary for Trinidad components to look like they normally look?
>
> I'm just thinking that what is currently being done is not enough to
> have the full skinning features available, and that going the
> direction of adding the CSS dynamically would allow to do so.
>
> regards,
>
> Martin
>
> On 7/26/07, Scott O'Bryan <da...@gmail.com> wrote:
>> Hey Martin,
>>
>> Does the simple-portlet skin render any better? I *THINK* that when
>> running in a portal environment you always get the simple-portlet skin
>> unless your portal provides one of the necessary skin extensions which,
>> right now, it trinidad proprietary. Maybe this is just a case of us
>> needing to bug-fix the portlet skin.
>>
>> That article is interesting, but I think that Trinidad has attempted to
>> do the same thing only in a different way. Instead of using javascript
>> to copy in the styles, we actually change the class names that get
>> rendered on the client to use the portal styles where appropriate.
>> Still, I'm not sure that this has been tested extensively because before
>> we started looking at 301, much of Trinidad's portal work has been done
>> with a Proof of Concept environment.
>>
>> Scott
>>
>> 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
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>> >
>>
>>
>
>
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Martin Marinschek <ma...@gmail.com>.
Does the portlet container really provide every styleclass that is
necessary for Trinidad components to look like they normally look?
I'm just thinking that what is currently being done is not enough to
have the full skinning features available, and that going the
direction of adding the CSS dynamically would allow to do so.
regards,
Martin
On 7/26/07, Scott O'Bryan <da...@gmail.com> wrote:
> Hey Martin,
>
> Does the simple-portlet skin render any better? I *THINK* that when
> running in a portal environment you always get the simple-portlet skin
> unless your portal provides one of the necessary skin extensions which,
> right now, it trinidad proprietary. Maybe this is just a case of us
> needing to bug-fix the portlet skin.
>
> That article is interesting, but I think that Trinidad has attempted to
> do the same thing only in a different way. Instead of using javascript
> to copy in the styles, we actually change the class names that get
> rendered on the client to use the portal styles where appropriate.
> Still, I'm not sure that this has been tested extensively because before
> we started looking at 301, much of Trinidad's portal work has been done
> with a Proof of Concept environment.
>
> Scott
>
> 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
Re: [TRINIDAD] Skinning in a portlet environment
Posted by Scott O'Bryan <da...@gmail.com>.
Hey Martin,
Does the simple-portlet skin render any better? I *THINK* that when
running in a portal environment you always get the simple-portlet skin
unless your portal provides one of the necessary skin extensions which,
right now, it trinidad proprietary. Maybe this is just a case of us
needing to bug-fix the portlet skin.
That article is interesting, but I think that Trinidad has attempted to
do the same thing only in a different way. Instead of using javascript
to copy in the styles, we actually change the class names that get
rendered on the client to use the portal styles where appropriate.
Still, I'm not sure that this has been tested extensively because before
we started looking at 301, much of Trinidad's portal work has been done
with a Proof of Concept environment.
Scott
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
>
>
>
> ------------------------------------------------------------------------
>