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 <html>, <head> or <body> element then
set a boolean flag to false to inhibit itself. The overhaul would then be a
single if evaluation per startElement. It would be called often, but a if
with a boolean flag get evaluated in 2 ticks, which is nothing for all
practical purposes.
On 7/28/07, Martin Marinschek <[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
<trh:styleSheet/> that could be slightly altered to do that work,
but I
would prefer a way not involving any action from users.
On 7/27/07, Martin Marinschek < [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:
<tr:form id="helloForm" binding="#{ personPage.form}">
provide a getter for this form in your backing-bean:
public CoreForm getForm() {
CoreForm coreForm = new MyCoreForm();
return coreForm;
}
write the class MyCoreForm, extending Trinidad's CoreForm -
with
that,
you should be good.
public static class MyCoreForm extends CoreForm {
@Override
public void encodeBegin(FacesContext context) throws
IOException
{
StyleContext styleContext =
((CoreRenderingContext)
RenderingContext.getCurrentInstance
()).getStyleContext();
String uri =
styleContext.getStyleProvider
().getStyleSheetURI(styleContext);
String contextUri =
context.getExternalContext ().getRequestContextPath();
String baseURL = contextUri +
XhtmlConstants.STYLES_CACHE_DIRECTORY;
String finalUri = context.getExternalContext
().encodeResourceURL(baseURL+uri);
StringBuffer buf = new StringBuffer();
buf.append("<script type=\"text/javascript\">\n"
+
"\n" +
"//<![CDATA[\n" +
"\n" +
"if( document.createStyleSheet) {\n" +
"\n" +
"
document.createStyleSheet('"+finalUri+"');\n"
+
"\n" +
"}\n" +
"\n" +
"else {\n" +
"\n" +
"var styles = \"@import
url('"+finalUri+"');\";\n" +
"\n" +
"var newSS= document.createElement
('link');\n" +
"\n" +
" newSS.rel='stylesheet' ;\n" +
"\n" +
" newSS.href='"+finalUri+"';\n" +
"\n" +
"document.getElementsByTagName(\"head\")[0].appendChild(newSS);\n"
+
"\n" +
"}\n" +
"\n" +
"//]]>\n" +
"\n" +
"</script>");
context.getResponseWriter().write(buf.toString());
super.encodeBegin(context);
}
}
On 7/26/07, Simon Lessard < [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]
<mailto: [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]
<mailto: [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]
<mailto: [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]
<mailto: [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:
> > > >
> > > >
<skin-family>simple</skin-family>
> > > >
> > > > in the trinidad-config.xml I got skinning
to
run
in
the
portlet
> > > > environment. In the end, I'm not very
happy
with
what
I
see, though.
> > > >
> > > > I'm attaching a screenshot - basically,
not
much
change
happens by
> > > > applying skinning - obviously due to the
fact
that
the
portlet
> > > > containers don't offer many default
style-class
hooks.
> > > > Have I been getting this wrong or does it
really
look
like
this?
> > > >
> > > > If I have been doing the right thing,
wouldn't
it
be
nice
to have a
> > > > way of adding the stylesheet with
javascript
dynamically
in the body?
> > > >
> > > > Something like this:
> > > >
> > > >
>
http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
<
http://cse-mjmcl.cse.bris.ac.uk/blog/2005/08/18/1124396539593.html
> > > >
> > > > might be in order to have full skinning
available,
and
still be
> > > > standards compliant.
> > > >
> > > > I'd implement this in a component, if
nobody
has
better
ideas...
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > >
> > > >
> > > >
>
------------------------------------------------------------------------
> > > >
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
