[TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

After playing around for a while and finally finding out that it was
as easy as setting:

 simple

in the trinidad-config.xml I got skinning to run in the portlet
environment. In the end, I'm not very happy with what I see, though.

I'm attaching a screenshot - basically, not much change happens by
applying skinning - obviously due to the fact that the portlet
containers don't offer many default style-class hooks.
Have I been getting this wrong or does it really look like this?

If I have been doing the right thing, wouldn't it be nice to have a
way of adding the stylesheet with javascript dynamically in the body?

Something like this:

http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html

might be in order to have full skinning available, and still be
standards compliant.

I'd implement this in a component, if nobody has better ideas...

regards,

Martin


--

http://www.irian.at

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

Professional Support for Apache MyFaces
<>

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:
> >
> >  simple
> >
> > in the trinidad-config.xml I got skinning to run in the portlet
> > environment. In the end, I'm not very happy with what I see, though.
> >
> > I'm attaching a screenshot - basically, not much change happens by
> > applying skinning - obviously due to the fact that the portlet
> > containers don't offer many default style-class hooks.
> > Have I been getting this wrong or does it really look like this?
> >
> > If I have been doing the right thing, wouldn't it be nice to have a
> > way of adding the stylesheet with javascript dynamically in the body?
> >
> > Something like this:
> >
> > http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> >
> > might be in order to have full skinning available, and still be
> > standards compliant.
> >
> > I'd implement this in a component, if nobody has better ideas...
> >
> > regards,
> >
> > Martin
> >
> >
> >
> >

> >
>
>


--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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:
> > > > >
> > > > >  simple
> > > > >
> > > > > in the trinidad-config.xml I got skinning to run in the portlet
> > > > > environment. In the end, I'm not very happy with what I see,
though.
> > > > >
> > > > > I'm attaching a screenshot - basically, not much change happens by
> > > > > applying skinning - obviously due to the fact that the portlet
> > > > > containers don't offer many default style-class hooks.
> > > > > Have I been getting this wrong or does it really look like this?
> > > > >
> > > > > If I have been doing the right thing, wouldn't it be nice to have
a
> > > > > way of adding the stylesheet with javascript dynamically in the
body?
> > > > >
> > > > > Something like this:
> > > > >
> > > > >
> >
http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> > > > >
> > > > > might be in order to have full skinning available, and still be
> > > > > standards compliant.
> > > > >
> > > > > I'd implement this in a component, if nobody has better ideas...
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > >
> > > > >
> > > > >
> >

> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>





--

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

[Scott O'Bryan]

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* <[EMAIL PROTECTED] 
> 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 <[EMAIL PROTECTED]
> 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:
> >
> >  simple
> >
> > in the trinidad-config.xml I got skinning to run in the portlet
> > environment. In the end, I'm not very happy with what I see,
though.
> >
> > I'm attaching a screenshot - basically, not much change happens by
> > applying skinning - obviously due to the fact that the portlet
> > containers don't offer many default style-class hooks.
> > Have I been getting this wrong or does it really look like this?
> >
> > If I have been doing the right thing, wouldn't it be nice to
have a
> > way of adding the stylesheet with javascript dynamically in
the body?
> >
> > Something like this:
> >
> >
http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> >
> > might be in order to have full skinning available, and still be
> > standards compliant.
> >
> > I'd implement this in a component, if nobody has better ideas...
> >
> > regards,
> >
> > Martin
> >
> >
> >
> >

> >
>
>


--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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* <[EMAIL PROTECTED] 
> 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 < [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]
> 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:
> > > >
> > > >  simple
> > > >
> > > > in the trinidad-config.xml I got skinning to run in the
portlet
> > > > environment. In the end, I'm not very happy with what I
see, though.
> > > >
> > > > I'm attaching a screenshot - basically, not much change
happens by
> > > > applying skinning - obviously due to the fact that the portlet
> > > > containers don't offer many default style-class hooks.
> > > > Have I been getting this wrong or does it really look like
this?
> > > >
> > > > If I have been doing the right thing, wouldn't it be nice
to have a
> > > > way of adding the stylesheet with javascript dynamically
in the body?
> > > >
> > > > Something like this:
> > > >
> > > >
>
http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html

> > > >
> > > > might be in order to have full skinning available, and
still be
> > > > standards compliant.
> > > >
> > > > I'd implement this in a component, if nobody has better
ideas...
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > >
> > > >
> > > >
>


> > > >
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
 

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:
> > >
> > >  simple
> > >
> > > in the trinidad-config.xml I got skinning to run in the portlet
> > > environment. In the end, I'm not very happy with what I see, though.
> > >
> > > I'm attaching a screenshot - basically, not much change happens by
> > > applying skinning - obviously due to the fact that the portlet
> > > containers don't offer many default style-class hooks.
> > > Have I been getting this wrong or does it really look like this?
> > >
> > > If I have been doing the right thing, wouldn't it be nice to have a
> > > way of adding the stylesheet with javascript dynamically in the body?
> > >
> > > Something like this:
> > >
> > >
http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> > >
> > > might be in order to have full skinning available, and still be
> > > standards compliant.
> > >
> > > I'd implement this in a component, if nobody has better ideas...
> > >
> > > regards,
> > >
> > > Martin
> > >
> > >
> > >
> > >

> > >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>





--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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 <[EMAIL PROTECTED]> 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:
>
>  simple
>
> in the trinidad-config.xml I got skinning to run in the portlet
> environment. In the end, I'm not very happy with what I see, though.
>
> I'm attaching a screenshot - basically, not much change happens by
> applying skinning - obviously due to the fact that the portlet
> containers don't offer many default style-class hooks.
> Have I been getting this wrong or does it really look like this?
>
> If I have been doing the right thing, wouldn't it be nice to have a
> way of adding the stylesheet with javascript dynamically in the body?
>
> Something like this:
>
> http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
>
> might be in order to have full skinning available, and still be
> standards compliant.
>
> I'd implement this in a component, if nobody has better ideas...
>
> regards,
>
> Martin
>
>
>
> 


>

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

Thus linking Portal-Trinidad users to specific portal vendor(s)... Ok, I see
the issue now... bleh...

On 7/26/07, Scott O'Bryan <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
> > 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 < [EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]
> > 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:
> > > > >
> > > > >  simple
> > > > >
> > > > > in the trinidad-config.xml I got skinning to run in the
> portlet
> > > > > environment. In the end, I'm not very happy with what I
> see, though.
> > > > >
> > > > > I'm attaching a screenshot - basically, not much change
> happens by
> > > > > applying skinning - obviously due to the fact that the
portlet
> > > > > containers don't offer many default style-class hooks.
> > > > > Have I been getting this wrong or does it really look like
> this?
> > > > >
> > > > > If I have been doing the right thing, wouldn't it be nice
> to have a
> > > > > way of adding the stylesheet with javascript dynamically
> in the body?
> > > > >
> > > > > Something like this:
> > > > >
> > > > >
> >
> http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> 
> > > > >
> > > > > might be in order to have full skinning available, and
> still be
> > > > > standards compliant.
> > > > >
> > > > > I'd implement this in a component, if nobody has better
> ideas...
> > >

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:
> > > >
> > > >  simple
> > > >
> > > > in the trinidad-config.xml I got skinning to run in the portlet
> > > > environment. In the end, I'm not very happy with what I see,
though.
> > > >
> > > > I'm attaching a screenshot - basically, not much change happens by
> > > > applying skinning - obviously due to the fact that the portlet
> > > > containers don't offer many default style-class hooks.
> > > > Have I been getting this wrong or does it really look like this?
> > > >
> > > > If I have been doing the right thing, wouldn't it be nice to have
a
> > > > way of adding the stylesheet with javascript dynamically in the
body?
> > > >
> > > > Something like this:
> > > >
> > > >
> http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> > > >
> > > > might be in order to have full skinning available, and still be
> > > > standards compliant.
> > > >
> > > > I'd implement this in a component, if nobody has better ideas...
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > >
> > > >
> > > >
> 
> > > >
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>


--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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:

 simple

in the trinidad-config.xml I got skinning to run in the portlet
environment. In the end, I'm not very happy with what I see, though.

I'm attaching a screenshot - basically, not much change happens by
applying skinning - obviously due to the fact that the portlet
containers don't offer many default style-class hooks.
Have I been getting this wrong or does it really look like this?

If I have been doing the right thing, wouldn't it be nice to have a
way of adding the stylesheet with javascript dynamically in the body?

Something like this:

http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html

might be in order to have full skinning available, and still be
standards compliant.

I'd implement this in a component, if nobody has better ideas...

regards,

Martin

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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:
>
>  simple
>
> in the trinidad-config.xml I got skinning to run in the portlet
> environment. In the end, I'm not very happy with what I see, though.
>
> I'm attaching a screenshot - basically, not much change happens by
> applying skinning - obviously due to the fact that the portlet
> containers don't offer many default style-class hooks.
> Have I been getting this wrong or does it really look like this?
>
> If I have been doing the right thing, wouldn't it be nice to have a
> way of adding the stylesheet with javascript dynamically in the body?
>
> Something like this:
>
> http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
>
> might be in order to have full skinning available, and still be
> standards compliant.
>
> I'd implement this in a component, if nobody has better ideas...
>
> regards,
>
> Martin
>
>
>
> 
>





--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:
> >
> > 
> >
> > 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("\n" +
> > "\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" +
> > "");
> > context.getResponseWriter().write(buf.toString());
> >
> > super.encodeBegin(context);
> > }
> > }
> >
> > On 7/26/07, Simon Lessard <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

Hi Simon, Scott,

I've made skinning work now in any container - this is the code that
I've used, for other users as a reference. We should carry on the
discussion if and how to integrate this into Trinidad itself, though.

regards,

Martin



use a binding attribute on your tr:form:



provide a getter for this form in your backing-bean:

public CoreForm getForm() {
CoreForm coreForm =  new MyCoreForm();
return coreForm;
}

write the class MyCoreForm, extending Trinidad's CoreForm - with that,
you should be good.

public static class MyCoreForm extends CoreForm {
@Override
public void encodeBegin(FacesContext context) throws IOException {

StyleContext styleContext = ((CoreRenderingContext)
RenderingContext.getCurrentInstance()).getStyleContext();
String uri =
styleContext.getStyleProvider().getStyleSheetURI(styleContext);

String contextUri =
context.getExternalContext().getRequestContextPath();
String baseURL = contextUri + XhtmlConstants.STYLES_CACHE_DIRECTORY;

String finalUri = context.getExternalContext
().encodeResourceURL(baseURL+uri);

StringBuffer buf = new StringBuffer();

buf.append("\n" +
"\n" +
"//\n" +
"\n" +
"");
context.getResponseWriter().write(buf.toString());

super.encodeBegin(context);
}
}

On 7/26/07, Simon Lessard <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
> > > > 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 < [EMAIL PROTECTED]
> > > > 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 <[EMAIL PROTECTED]
> > > > 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.
> > > > >
> > >  

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > Hello Martin,
> >
> > Yeah I thought about a new component and we actually already have
> >  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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>
> 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:
> > > > > >
> > > > > > 
> > > > > >
> > > > > > 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();
> > > > > >

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

Hello Martin,

Yeah I thought about a new component and we actually already have
 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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:
> > > >
> > > > 
> > > >
> > > > 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("\n" +
> > > > "\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" +
> > > > "");
> > > > context.getResp

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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:
> > >
> > > 
> > >
> > > 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("\n" +
> > > "\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" +
> > > "");
> > > context.getResponseWriter().write(buf.toString());
> > >
> > > super.encodeBegin(context);
> > > }
> > > }
> > >
> > > On 7/26/07, Simon Lessard < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> wrote:
> > > > > Simon, you are correct.  The portal would be able to push a
> parameter to
> > > > > Trinidad.  Always in a portal environme

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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:
>
> 
>
> 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("\n" +
> "\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" +
> "");
> context.getResponseWriter().write(buf.toString());
>
> super.encodeBegin(context);
> }
> }
>
> On 7/26/07, Simon Lessard <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
> > > > > 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 < [EMAIL PROTECTED]
> > > > > wrot

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> wrote:
> Hello Martin,
>
> Yeah I thought about a new component and we actually already have
>  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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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:
> > > > >
> > > > > 
> > > > >
> > > > > 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("\n" +
> > > > > "\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" +
> >

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > Hello Martin,
> > >
> > > Yeah I thought about a new component and we actually already have
> > >  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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED] >
> 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:
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > 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

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

Sure, this would work.

Everyone agreeing we should do it this way?

regards,

Martin

On 7/28/07, Simon Lessard <[EMAIL PROTECTED]> 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 ,  or  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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > > > Hello Martin,
> > > > >
> > > > > Yeah I thought about a new component and we actually already have
> > > > >  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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>
> 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
> > > > > > > >
> >

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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 <[EMAIL PROTECTED]> 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 ,  or  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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
  

Hello Martin,

Yeah I thought about a new component and we actually already have
 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>


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 < [EMAIL PROTECTED] >
  

wrote:
 

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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 <[EMAIL PROTECTED]> 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 ,  or  
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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
 

Hello Martin,

Yeah I thought about a new component and we actually already have
 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>


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
  

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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* <[EMAIL PROTECTED] 
> 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* < [EMAIL PROTECTED]
> 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 < [EMAIL PROTECTED]
> 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 ,  or 
>>> 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 <[EMAIL PROTECTED]
> 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 < [EMAIL PROTECTED]
> 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

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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* <[EMAIL PROTECTED] 
> 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 < [EMAIL PROTECTED]
> 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 ,  or 
>>> 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 <[EMAIL PROTECTED]
> 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 < [EMAIL PROTECTED]
> 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 < [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]
> wrote:
>>
>>> Hello Martin,

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
> > > 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 < [EMAIL PROTECTED]
> > > 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 ,  or 
> > >>> 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 <[EMAIL PROTECTED]
> > > 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 < [EMAIL PROTECTED]
> > > 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
> > >

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

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 <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
> 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 < [EMAIL PROTECTED]
> 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 ,  or 
>>> 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 <[EMAIL PROTECTED]
> 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 < [EMAIL PROTECTED]
> 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.
>

Re: [TRINIDAD] Skinning in a portlet environment

[Jeanne Waldman]

When you are in a portlet environment, we render the 'portlet' skin.
If your skin is set to simple (which is the default), then you'll get the
simple.portlet skin instead of the simple.desktop skin that you would
normally get if you are not in a portlet.

If your skin is set to 'foo', you'll get the 'foo.portlet' skin. If the 
app hasn't

defined a 'foo.portlet' skin, you'll get the default 'simple.portlet' skin.

The SimplePortlet skin maps (see getStyleClassMap in the 
SimplePortletSkin.java code)

Trinidad selectors to Portlet selectors where applicable.
For example, we map af|inputText::label to portlet-form-label.

You can see what we are doing by using Firebug and looking at the 
generated html and the

css selectors.

We are expecting a stylesheet on the page where the portlet styles
(e.g., portlet-form-label {font-family: Tahoma; font-size: 11px} are 
defined.

Otherwise it will look like your picture - no styling.

Now if you have a usecase where you want to use a skin like 
'purple.desktop' EVEN if you
are in a portlet environment, then you can send request parameters to 
let us know.


See StyleSheetRenderer for this. Here is the comment:

 // If the requestMap has a skin-id, a skin's stylesheet's id and 
suppressStylesheet
 // is true, and the skin information matches our current skin, 
then it is safe
 // to not write out the css. This means that it will be written 
out by the external

 // source, like the portal container.

This is from CoreRenderingContext.java:

 /**
  * Returns the skin that is requested on the request map if the exact 
skin exists.

  * 
  * If we are in a portlet, then we might need to recalculate the skin.
  * The portal container might have its own skin that it wants us to 
use instead

  * of what we picked based on the skin-family and render-kit-id.
  * If it does, it will send the skin-id and the skin's 
styleSheetDocument id

  * in the request map.
  * 
  * 
  * If we have the skin with that id and the stylesheetdocument's id match,
  * then we return that skin; else we return null, indicating that 
there is no

  * requestMap skin.
  * 
  * @return null if there is no local skin that matches the requestMap 
skin, if any.
  * skin that is requested to be used on the requestMap if we 
can find that

  * exact skin with the same stylesheetdocument id locally.
  */
 public Skin getRequestMapSkin()


Note that we will not use the skin requested if it doesn't match exactly 
the portlet container's skin,

otherwise there will be conflicts in the css and weird things could happen.

Hope this helps,

Jeanne

Martin Marinschek wrote:

After playing around for a while and finally finding out that it was
as easy as setting:

 simple

in the trinidad-config.xml I got skinning to run in the portlet
environment. In the end, I'm not very happy with what I see, though.

I'm attaching a screenshot - basically, not much change happens by
applying skinning - obviously due to the fact that the portlet
containers don't offer many default style-class hooks.
Have I been getting this wrong or does it really look like this?

If I have been doing the right thing, wouldn't it be nice to have a
way of adding the stylesheet with javascript dynamically in the body?

Something like this:

http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html

might be in order to have full skinning available, and still be
standards compliant.

I'd implement this in a component, if nobody has better ideas...

regards,

Martin

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

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 <[EMAIL PROTECTED]> wrote:
> When you are in a portlet environment, we render the 'portlet' skin.
> If your skin is set to simple (which is the default), then you'll get the
> simple.portlet skin instead of the simple.desktop skin that you would
> normally get if you are not in a portlet.
>
> If your skin is set to 'foo', you'll get the 'foo.portlet' skin. If the
> app hasn't
> defined a 'foo.portlet' skin, you'll get the default 'simple.portlet' skin.
>
> The SimplePortlet skin maps (see getStyleClassMap in the
> SimplePortletSkin.java code)
> Trinidad selectors to Portlet selectors where applicable.
> For example, we map af|inputText::label to portlet-form-label.
>
> You can see what we are doing by using Firebug and looking at the
> generated html and the
> css selectors.
>
> We are expecting a stylesheet on the page where the portlet styles
> (e.g., portlet-form-label {font-family: Tahoma; font-size: 11px} are
> defined.
> Otherwise it will look like your picture - no styling.
>
> Now if you have a usecase where you want to use a skin like
> 'purple.desktop' EVEN if you
> are in a portlet environment, then you can send request parameters to
> let us know.
>
> See StyleSheetRenderer for this. Here is the comment:
>
>   // If the requestMap has a skin-id, a skin's stylesheet's id and
> suppressStylesheet
>   // is true, and the skin information matches our current skin,
> then it is safe
>   // to not write out the css. This means that it will be written
> out by the external
>   // source, like the portal container.
>
> This is from CoreRenderingContext.java:
>
>   /**
>* Returns the skin that is requested on the request map if the exact
> skin exists.
>* 
>* If we are in a portlet, then we might need to recalculate the skin.
>* The portal container might have its own skin that it wants us to
> use instead
>* of what we picked based on the skin-family and render-kit-id.
>* If it does, it will send the skin-id and the skin's
> styleSheetDocument id
>* in the request map.
>* 
>* 
>* If we have the skin with that id and the stylesheetdocument's id match,
>* then we return that skin; else we return null, indicating that
> there is no
>* requestMap skin.
>* 
>* @return null if there is no local skin that matches the requestMap
> skin, if any.
>* skin that is requested to be used on the requestMap if we
> can find that
>* exact skin with the same stylesheetdocument id locally.
>*/
>   public Skin getRequestMapSkin()
>
>
> Note that we will not use the skin requested if it doesn't match exactly
> the portlet container's skin,
> otherwise there will be conflicts in the css and weird things could happen.
>
> Hope this helps,
>
> Jeanne
>
> Martin Marinschek wrote:
> > After playing around for a while and finally finding out that it was
> > as easy as setting:
> >
> >  simple
> >
> > in the trinidad-config.xml I got skinning to run in the portlet
> > environment. In the end, I'm not very happy with what I see, though.
> >
> > I'm attaching a screenshot - basically, not much change happens by
> > applying skinning - obviously due to the fact that the portlet
> > containers don't offer many default style-class hooks.
> > Have I been getting this wrong or does it really look like this?
> >
> > If I have been doing the right thing, wouldn't it be nice to have a
> > way of adding the stylesheet with javascript dynamically in the body?
> >
> > Something like this:
> >
> > http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> >
> > might be in order to have full skinning available, and still be
> > standards compliant.
> >
> > I'd implement this in a component, if nobody has better ideas...
> >
> > regards,
> >
> > Martin
> >
> >
> >
> > 
> >
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses

Re: [TRINIDAD] Skinning in a portlet environment

[Jeanne Waldman]

Martin Marinschek wrote:

Hi Jeanne,

@reusing basic portlet-stylesheet: ok, but my assumption holds true
that this will only do the most basic styling, as there are not many
styles defined in the portlet spec? In any case, I must have done
something wrong - cause I never got 'portlet_form_label' to show up -
it was always Trinidad-styleClass-names, I'll check again.
  
Yes. this will be the most basic styling. You will see 
trinidad-style-names also in some cases,
but in the portlet skin, the css properties for the trinidad-style-names 
are purely for layout reasons.
They have no font/color information. This is supposed to be picked up by 
the portlet-font or other

portlet styles.
But, that said, you can extend the simple.portlet skin and create your 
own portlet skin, like 'purple.portlet' skin
that adds the colors back, for example. Then, you'd say skin-family is 
purple, and the purple.portlet skin

will get chosen if you are in a portlet.

@passing down renderer-parameters: this will only work if the portlet
container supports the Trinidad-stylesheet. Realistically, this will
only be implemented in one or two portlet container implementations
anytime soon.
  
yes. The portlet container needs to have Trinidad and a Trinidad skin so 
it can pass the skin id and the

id of the skin's stylesheet document to tell the portlet to use that.

@dynamically adding trinidad stylesheet: you have a good point with
interfering style-classes. I'd still say this is the only route I can
go as for the above reasons, I'll need to edit the portlet-container
stylesheet (or reconfigure it) so that no conflicts occur. Anyways,
with this point you're right that this is not a generally useful
solution, so I'll keep the hack I have right now and be happy with it.
What is your problem exactly and how are you working around it? I gather 
that you are writing the
a new css to the page in addition to the portlet's css file?? What is in 
the new css document?



regards,

Martin

On 7/30/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
  

When you are in a portlet environment, we render the 'portlet' skin.
If your skin is set to simple (which is the default), then you'll get the
simple.portlet skin instead of the simple.desktop skin that you would
normally get if you are not in a portlet.

If your skin is set to 'foo', you'll get the 'foo.portlet' skin. If the
app hasn't
defined a 'foo.portlet' skin, you'll get the default 'simple.portlet' skin.

The SimplePortlet skin maps (see getStyleClassMap in the
SimplePortletSkin.java code)
Trinidad selectors to Portlet selectors where applicable.
For example, we map af|inputText::label to portlet-form-label.

You can see what we are doing by using Firebug and looking at the
generated html and the
css selectors.

We are expecting a stylesheet on the page where the portlet styles
(e.g., portlet-form-label {font-family: Tahoma; font-size: 11px} are
defined.
Otherwise it will look like your picture - no styling.

Now if you have a usecase where you want to use a skin like
'purple.desktop' EVEN if you
are in a portlet environment, then you can send request parameters to
let us know.

See StyleSheetRenderer for this. Here is the comment:

  // If the requestMap has a skin-id, a skin's stylesheet's id and
suppressStylesheet
  // is true, and the skin information matches our current skin,
then it is safe
  // to not write out the css. This means that it will be written
out by the external
  // source, like the portal container.

This is from CoreRenderingContext.java:

  /**
   * Returns the skin that is requested on the request map if the exact
skin exists.
   * 
   * If we are in a portlet, then we might need to recalculate the skin.
   * The portal container might have its own skin that it wants us to
use instead
   * of what we picked based on the skin-family and render-kit-id.
   * If it does, it will send the skin-id and the skin's
styleSheetDocument id
   * in the request map.
   * 
   * 
   * If we have the skin with that id and the stylesheetdocument's id match,
   * then we return that skin; else we return null, indicating that
there is no
   * requestMap skin.
   * 
   * @return null if there is no local skin that matches the requestMap
skin, if any.
   * skin that is requested to be used on the requestMap if we
can find that
   * exact skin with the same stylesheetdocument id locally.
   */
  public Skin getRequestMapSkin()


Note that we will not use the skin requested if it doesn't match exactly
the portlet container's skin,
otherwise there will be conflicts in the css and weird things could happen.

Hope this helps,

Jeanne

Martin Marinschek wrote:


After playing around for a while and finally finding out that it was
as easy as setting:

 simple

in the trinidad-config.xml I got skinning to run in the portlet
environment. In the end, I'm not very happy with what I see, though.

I'm attaching a screenshot - basically, not much change happens by
a

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

Hi Jeanne,

I repost what I have been doing - essentially, I have been including
the full Trinidad-CSS-file with JavaScript - as a fallback for the
case that the container doesn't include it. In this case, I'll need to
strip the portlet-css file to the bare minimum, that's clear. In the
case of the project I'm doing this for this is ok, as only Trinidad
portlets will be included on the portal-page.

regards,

Martin

-

Hi Simon, Scott,

I've made skinning work now in any container - this is the code that
I've used, for other users as a reference. We should carry on the
discussion if and how to integrate this into Trinidad itself, though.

regards,

Martin



use a binding attribute on your tr:form:



provide a getter for this form in your backing-bean:

   public CoreForm getForm() {
   CoreForm coreForm =  new MyCoreForm();
   return coreForm;
   }

write the class MyCoreForm, extending Trinidad's CoreForm - with that,
you should be good.

   public static class MyCoreForm extends CoreForm {
   @Override
   public void encodeBegin(FacesContext context) throws IOException {

   StyleContext styleContext = ((CoreRenderingContext)
RenderingContext.getCurrentInstance()).getStyleContext();
   String uri =
styleContext.getStyleProvider().getStyleSheetURI(styleContext);

   String contextUri =
context.getExternalContext().getRequestContextPath();
   String baseURL = contextUri + XhtmlConstants.STYLES_CACHE_DIRECTORY;

   String finalUri = context.getExternalContext
().encodeResourceURL(baseURL+uri);

   StringBuffer buf = new StringBuffer();

   buf.append("\n" +
   "\n" +
   "//\n" +
   "\n" +
   "");
   context.getResponseWriter().write(buf.toString());

   super.encodeBegin(context);
   }
   }

On 7/31/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>
>
> Martin Marinschek wrote:
> > Hi Jeanne,
> >
> > @reusing basic portlet-stylesheet: ok, but my assumption holds true
> > that this will only do the most basic styling, as there are not many
> > styles defined in the portlet spec? In any case, I must have done
> > something wrong - cause I never got 'portlet_form_label' to show up -
> > it was always Trinidad-styleClass-names, I'll check again.
> >
> Yes. this will be the most basic styling. You will see
> trinidad-style-names also in some cases,
> but in the portlet skin, the css properties for the trinidad-style-names
> are purely for layout reasons.
> They have no font/color information. This is supposed to be picked up by
> the portlet-font or other
> portlet styles.
> But, that said, you can extend the simple.portlet skin and create your
> own portlet skin, like 'purple.portlet' skin
> that adds the colors back, for example. Then, you'd say skin-family is
> purple, and the purple.portlet skin
> will get chosen if you are in a portlet.
> > @passing down renderer-parameters: this will only work if the portlet
> > container supports the Trinidad-stylesheet. Realistically, this will
> > only be implemented in one or two portlet container implementations
> > anytime soon.
> >
> yes. The portlet container needs to have Trinidad and a Trinidad skin so
> it can pass the skin id and the
> id of the skin's stylesheet document to tell the portlet to use that.
> > @dynamically adding trinidad stylesheet: you have a good point with
> > interfering style-classes. I'd still say this is the only route I can
> > go as for the above reasons, I'll need to edit the portlet-container
> > stylesheet (or reconfigure it) so that no conflicts occur. Anyways,
> > with this point you're right that this is not a generally useful
> > solution, so I'll keep the hack I have right now and be happy with it.
> What is your problem exactly and how are you working around it? I gather
> that you are writing the
> a new css to the page in addition to the portlet's css file?? What is in
> the new css document?
>
> > regards,
> >
> > Martin
> >
> > On 7/30/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
> >
> >> When you ar

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

Hello all,

I thought about the name clashes yesterday and maybe we could namespace the
selectors and the stylesheet if we decide to JavaScript push the skin?
RenderingContext.getStyleClass could be in charge of adding the prefix when
it detect a portlet environment that didn't include the special render
parameter and the application requires a more complex skin. The only hard
part here would be what to use as a prefix, maybe something like
t where someTimeStamp is the last 4 digits of a
System.getCurrentTimeMillis() call made by the stylesheet generation code.
That way all portlets in the portal would be able to have a distinct skin
without any chance of name clashes and without any special action from the
user or the portlet container.

However, since it's going to include the CSS everytime, this strategy
greatly increase the response size thus increasing the latency.

Does that make any sense?


~ Simon

On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
>
> Hi Jeanne,
>
> I repost what I have been doing - essentially, I have been including
> the full Trinidad-CSS-file with JavaScript - as a fallback for the
> case that the container doesn't include it. In this case, I'll need to
> strip the portlet-css file to the bare minimum, that's clear. In the
> case of the project I'm doing this for this is ok, as only Trinidad
> portlets will be included on the portal-page.
>
> regards,
>
> Martin
>
> -
>
> Hi Simon, Scott,
>
> I've made skinning work now in any container - this is the code that
> I've used, for other users as a reference. We should carry on the
> discussion if and how to integrate this into Trinidad itself, though.
>
> regards,
>
> Martin
>
> 
>
> use a binding attribute on your tr:form:
>
> 
>
> 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("\n" +
>"\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" +
>"");
>context.getResponseWriter().write(buf.toString());
>
>super.encodeBegin(context);
>}
>}
>
> On 7/31/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
> >
> >
> > Martin Marinschek wrote:
> > > Hi Jeanne,
> > >
> > > @reusing basic portlet-stylesheet: ok, but my assumption holds true
> > > that this will only do the most basic styling, as there are not many
> > > styles defined in the portlet spec? In any case, I must have done
> > > something wrong - cause I never got 'portlet_form_label' to show up -
> > > it was always Trinidad-styleClass-names, I'll check again.
> > >
> > Yes. this will be the most basic styling. You will see
> > trinidad-style-names also in some cases,
> > but in the portlet skin, the css properties for the trinidad-style-names
> > are purely for layout reasons.
> > They have no font/color information. This is supposed to be picked up by
> > the portlet-font or other
> > portlet styles.
> > But, that said, you can extend the simple.portlet skin and create your
> > own portlet skin, like 'purple.portlet' skin
> > that adds the colors back, for example. Then, you'd say skin-family is
> > purple, and the purple.portlet skin
> > will get chosen if

Re: [TRINIDAD] Skinning in a portlet environment

[Martin Marinschek]

Hi Simon,

yes, that makes sense - but the issue is before this, that the
Portlet-Container itself emits a style-sheet - and that instructions
in this stylesheet might conflict with the skinning instructions in
the page.

regards,

Martin

On 7/31/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I thought about the name clashes yesterday and maybe we could namespace the
> selectors and the stylesheet if we decide to JavaScript push the skin?
> RenderingContext.getStyleClass could be in charge of adding the prefix when
> it detect a portlet environment that didn't include the special render
> parameter and the application requires a more complex skin. The only hard
> part here would be what to use as a prefix, maybe something like
> t where someTimeStamp is the last 4 digits of a
> System.getCurrentTimeMillis() call made by the stylesheet generation code.
> That way all portlets in the portal would be able to have a distinct skin
> without any chance of name clashes and without any special action from the
> user or the portlet container.
>
> However, since it's going to include the CSS everytime, this strategy
> greatly increase the response size thus increasing the latency.
>
> Does that make any sense?
>
>
> ~ Simon
>
>
>  On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Hi Jeanne,
> >
> > I repost what I have been doing - essentially, I have been including
> > the full Trinidad-CSS-file with JavaScript - as a fallback for the
> > case that the container doesn't include it. In this case, I'll need to
> > strip the portlet-css file to the bare minimum, that's clear. In the
> > case of the project I'm doing this for this is ok, as only Trinidad
> > portlets will be included on the portal-page.
> >
> > regards,
> >
> > Martin
> >
> > -
> >
> > Hi Simon, Scott,
> >
> > I've made skinning work now in any container - this is the code that
> > I've used, for other users as a reference. We should carry on the
> > discussion if and how to integrate this into Trinidad itself, though.
> >
> > regards,
> >
> > Martin
> >
> > 
> >
> > use a binding attribute on your tr:form:
> >
> > 
> >
> > 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("\n" +
> >"\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" +
> >"");
> >context.getResponseWriter().write(buf.toString());
> >
> >super.encodeBegin(context);
> >}
> >}
> >
> > On 7/31/07, Jeanne Waldman <[EMAIL PROTECTED] > wrote:
> > >
> > >
> > > Martin Marinschek wrote:
> > > > Hi Jeanne,
> > > >
> > > > @reusing basic portlet-stylesheet: ok, but my assumption holds true
> > > > that this will only do the most basic styling, as there are not many
> > > > styles defined in the portlet spec? In any case, I must have done
> > > > something wrong - cause I never got 'portlet_form_label' to show up -
> > > > it was always Trinidad-styleClass-names, I'll check again.
> > > >
> > > Yes. this will be the most basic styling. You

Re: [TRINIDAD] Skinning in a portlet environment

[Simon Lessard]

Hmmm, I really don't see how that could happen if we namespace every single
selectors and ignore portal ones. I worked a bit with portal, but not that
much so I'm kind of a newbie and you may need a hard stick to strike the
thing in my head. Do you have any example of a kind of instructions that
would create conflicts?


Regards,

~ Simon

On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> yes, that makes sense - but the issue is before this, that the
> Portlet-Container itself emits a style-sheet - and that instructions
> in this stylesheet might conflict with the skinning instructions in
> the page.
>
> regards,
>
> Martin
>
> On 7/31/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > I thought about the name clashes yesterday and maybe we could namespace
> the
> > selectors and the stylesheet if we decide to JavaScript push the skin?
> > RenderingContext.getStyleClass could be in charge of adding the prefix
> when
> > it detect a portlet environment that didn't include the special render
> > parameter and the application requires a more complex skin. The only
> hard
> > part here would be what to use as a prefix, maybe something like
> > t where someTimeStamp is the last 4 digits of a
> > System.getCurrentTimeMillis() call made by the stylesheet generation
> code.
> > That way all portlets in the portal would be able to have a distinct
> skin
> > without any chance of name clashes and without any special action from
> the
> > user or the portlet container.
> >
> > However, since it's going to include the CSS everytime, this strategy
> > greatly increase the response size thus increasing the latency.
> >
> > Does that make any sense?
> >
> >
> > ~ Simon
> >
> >
> >  On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > Hi Jeanne,
> > >
> > > I repost what I have been doing - essentially, I have been including
> > > the full Trinidad-CSS-file with JavaScript - as a fallback for the
> > > case that the container doesn't include it. In this case, I'll need to
> > > strip the portlet-css file to the bare minimum, that's clear. In the
> > > case of the project I'm doing this for this is ok, as only Trinidad
> > > portlets will be included on the portal-page.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > -
> > >
> > > Hi Simon, Scott,
> > >
> > > I've made skinning work now in any container - this is the code that
> > > I've used, for other users as a reference. We should carry on the
> > > discussion if and how to integrate this into Trinidad itself, though.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > 
> > >
> > > use a binding attribute on your tr:form:
> > >
> > > 
> > >
> > > 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("\n" +
> > >"\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" +
> > >"");
> > >context.getResp

Re: [TRINIDAD] Skinning in a portlet environment

[Scott O'Bryan]

Yeah, plus shared styles are a good thing.  If you don't want shared 
styles there is nothing to say you can't have your own portal skin that 
overrides the styles using the skinning keys.


Martin Marinschek wrote:

Hi Simon,

See attached a screenshot what the page I'm working on currently looks
like - the input fields are somewhat off. I'd say this is the
conflicts which Jeanne is talking about in action ;)

regards,

Martin



On 7/31/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
  

Hmmm, I really don't see how that could happen if we namespace every single
selectors and ignore portal ones. I worked a bit with portal, but not that
much so I'm kind of a newbie and you may need a hard stick to strike the
thing in my head. Do you have any example of a kind of instructions that
would create conflicts?


Regards,


~ Simon

On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:


Hi Simon,

yes, that makes sense - but the issue is before this, that the
Portlet-Container itself emits a style-sheet - and that instructions
in this stylesheet might conflict with the skinning instructions in
the page.

regards,

Martin

On 7/31/07, Simon Lessard <[EMAIL PROTECTED] > wrote:
  

Hello all,

I thought about the name clashes yesterday and maybe we could namespace


the


selectors and the stylesheet if we decide to JavaScript push the skin?
RenderingContext.getStyleClass could be in charge of adding the prefix


when


it detect a portlet environment that didn't include the special render
parameter and the application requires a more complex skin. The only


hard


part here would be what to use as a prefix, maybe something like
t where someTimeStamp is the last 4 digits of a
System.getCurrentTimeMillis() call made by the stylesheet generation


code.


That way all portlets in the portal would be able to have a distinct


skin


without any chance of name clashes and without any special action from


the


user or the portlet container.

However, since it's going to include the CSS everytime, this strategy
greatly increase the response size thus increasing the latency.

Does that make any sense?


~ Simon


 On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:


Hi Jeanne,

I repost what I have been doing - essentially, I have been including
the full Trinidad-CSS-file with JavaScript - as a fallback for the
case that the container doesn't include it. In this case, I'll need to
strip the portlet-css file to the bare minimum, that's clear. In the
case of the project I'm doing this for this is ok, as only Trinidad
portlets will be included on the portal-page.

regards,

Martin

-

Hi Simon, Scott,

I've made skinning work now in any container - this is the code that
I've used, for other users as a reference. We should carry on the
discussion if and how to integrate this into Trinidad itself, though.

regards,

Martin



use a binding attribute on your tr:form:



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("\n" +
   "\n" +
   "//