FYI ... the JSR 301 -- bridge allows such subsystems to avoid this issue
because it sets a request attribute one can check to determine if you
are running in a portlet environment. The subsystem can check whether
this attribute is set/exists using the ExternalContext prior to making
any
Plus, for containers like Orchestra which are not necessarily tied to a
specific bridge implementation, it would allow them to work in
environments with older bridges.
Scott
Scott O'Bryan wrote:
Mike... True, although I did some timing and instanceof's (at least
in JDK 1.5) seemed to be on
Mike... True, although I did some timing and instanceof's (at least in
JDK 1.5) seemed to be on order of magnitudes faster then pulling a
request attribute off of the attribute map. At least on the server I
was testing. Secondly, Configurators sometimes run prior to the bridge
for servlets
Well, they are and they aren't related. In Trinidad the
ExternalContextUtils were developed as part of the configurator system.
Just turns out that once we had the utility, it had other uses outside
of the configurator framework. Current (with the externalContextUtils
*IN* the configurator
Hi
duplicating code even if just a bare minimum doesn't sound good to me. Even if
option 2 means that 2 jars need to be copied for the configurator subsystem
I think they still belong there. Although probably not very
problematic it would seem
strange to me if components which are not directly
+1 for ExternalContextUtils
Good idea Scott
In this case I wait for those utils before doing the changes in the
PPRPhaseListener
greez
E
On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Take a look at Trinidad's ExternalContextUtils class. It uses
reflection. I'm
On Fri, Mar 28, 2008 at 9:41 AM, Ernst Fastl [EMAIL PROTECTED] wrote:
+1 for ExternalContextUtils
Good idea Scott
In this case I wait for those utils before doing the changes in the
PPRPhaseListener
greez
E
On Fri, Mar 28, 2008 at 1:15 AM, Scott O'Bryan [EMAIL PROTECTED] wrote:
yep, it seems that ExternalContextUtils is already the abstraction on
top of servlet and portlet apis i'm talking about. ;)
And it is using reflection to dispatch the call either to portlet or
servlet api. Using reflection means that ExternalContextUtils has only
an 'implicit' dependency on both
Okay Okay already.. :) I'll work on getting these in the commons
somewhere. The code for the configurators (and my nifty new, much
nicer externalContextUtils) is done but I've been wishy washy about
where things should go so I haven't created the poms yet. Maybe I can
work on that a bit
Hi
I have seen lines like this on the attached files:
//Don't do the rendering twice
if (request instanceof PortletRequest
((PortletRequest)request).getAttribute(PPR_DONE_ATTR) != null) {
return;
}
The problem here is that doing this makes that tomahawk
Take a look at Trinidad's ExternalContextUtils class. It uses
reflection. I'm also going to try to get something like this in the
myfaces commons, probably in the configurator package if I end up
submitting my current code.
If you don't have time to find the ExternalContextUtils on your
hi,
people interested by AJAX enabled JSF portlets in Liferay portal using
tomahawk pprPanelGroup may take a look to this article:
http://newsted1.blogspot.com/2008/03/jsf-ajax-enabled-portlets-for-liferay.html
On Mon, Mar 24, 2008 at 10:23 PM, Ernst Fastl [EMAIL PROTECTED] wrote:
Hi,
I
Cool beans. Be careful though before checking these patches into a mainline
code base (maybe a sandbox or something). This solution probably won't work
for remote WSRP portals. As for your second suggestion, I couldn't agree
more. The Trinidad configurators provide an ExternalContext
Hi,
I just took a quick glance at the changes in the PPRPhaseListener.
What I've seen looks
alright so far and since I'm working on that class at the moment
anyway I'll be happy to
factor in those changes.
As for the DojoUtils, those are as far as I know mainly maintained by werner.
Maybe he
14 matches
Mail list logo
