Hi *,
I'm having another issue with Trinidad running in a portal enviroment
- I originally thought that Trinidad would automatically switch PPR
off, when running a portal environment.
I'm using a table with 100 rows on my page, and do see the
pager-component due to this. When I click on the
Hi *,
dialog handling makes of course problems as well in a portal environment ;).
Here the exception I get when clicking on the icon of an inputDate
component - shouldn't the icon be disabled instead of rendering it,
and then getting an exception?
regards,
Martin
Here is the code I'm stepping through currently:
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectRangeChoiceBarRenderer
:
ProcessUtils.renderNavSubmitScript(context, arc);
in renderNavSubmitScript, the scriptlet:
static private final String _NAV_SUBMIT_SCRIPT =
Same goes for sorting columns...
regards,
Martin
On 7/31/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Here is the code I'm stepping through currently:
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SelectRangeChoiceBarRenderer
:
Martin,
I havn't done any testing of the dialogs in Trinidad because of issue
TRINIDAD-55 https://issues.apache.org/jira/browse/TRINIDAD-55.
That said, I think this may be an issue with your bridge. The
org.apache.portals.bridges.jsf.PortletViewHandlerImpl.getActionURL is
throwing a
Trinidad does turn off PPR, but it's possible that this does not follow the
normal ppr route (although I don't know why). You may wish to file a Jira
ticket so we can keep track of it. I probably won't be able to take a look
at it myself until this weekend or next week.
Scott
On 7/31/07,
One more thing, the _submitPartialChange is supposed to actually do a full
page submit when in a portal environment. Is it possible that Trinidad is
failing the ExternalContextUtils.isPortal check using your bridge?
Scott
On 7/31/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Trinidad does turn
ExternalContextUtils.isPortal is working, I am about to dig deeper now.
regards,
Martin
On 7/31/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
One more thing, the _submitPartialChange is supposed to actually do a full
page submit when in a portal environment. Is it possible that Trinidad is
Hi again,
I digged deeper, and don't see where the distinction with regards to
portal servers is made. _partialPageSubmit does a full submit only if
_pprUnsupported is set. _pprUnsupported is only set if
_checkLoadNoPPR(); is called. _checkLoadNoPPR is only called in the
BodyRenderer, not
Hey Martin,
I think this actually exists on the client side if I'm not mistaken.
What I do know is that this used to work. Sigh.
I don't think you're correct though about the _checkLoadNoPPR. The
capabilities for the portlet should be loaded if the external context is
a portlet external
Hi Scott,
I didn't find the code you are referring to in the CoreRenderingContext.
The question - just like with the skinning - is when you'd render this
little piece of JavaScript. There is no root-element you can rely on
in the portlet-case... The Body-Renderer can render it, but it's not
Let me see if I can find it.. I know that the _partialPageSubmit does a
full page submit when inside of a portal and that the portal environment
is initialized based on capability settings... I'll get back to you
Martin Marinschek wrote:
Hi Scott,
I didn't find the code you are referring
I'll be replying to the dev list since we're getting into code :)
Scott O'Bryan wrote:
Let me see if I can find it.. I know that the _partialPageSubmit does
a full page submit when inside of a portal and that the portal
environment is initialized based on capability settings... I'll get
Martin,
PPR in Portlets CAN be implemented using certain portlet
implementations. But it cannot be done with generic JSR-168. Here are
a number of problems although I'm sure there are more:
1. Action Requests have portal artifacts. This means that a portal can
append content to a
Hi Scott,
interesting, thanks for the further clarification. I see the problems
very clearly now. Well then - let's start off this portlet bridge, and
see where it brings us to!
regards,
Martin
On 6/11/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Martin,
PPR in Portlets CAN be implemented
meaning two trinidad
portlets on the screen at the same time may conflict. Again, I
had a
JIRA ticket on this and I'll check the current status.
3. PPR in Trinidad has been disabled in a portal environment.
Things
that would normally do a ppr, will do a full-page submit
of the popup support does not work. I had a JIRA ticket
on this
when Trinidad was in incubator but I haven't checked to see if it's
still there. I'll check it out.
2. The javascript libraries are not namespaced meaning two trinidad
portlets on the screen at the same time may conflict. Again
had a JIRA ticket
on this
when Trinidad was in incubator but I haven't checked to see if it's
still there. I'll check it out.
2. The javascript libraries are not namespaced meaning two trinidad
portlets on the screen at the same time may conflict. Again, I
had a
JIRA ticket
of the popup support does not work. I had a JIRA ticket on this
when Trinidad was in incubator but I haven't checked to see if it's
still there. I'll check it out.
2. The javascript libraries are not namespaced meaning two trinidad
portlets on the screen at the same time may conflict. Again, I
not work. I had a JIRA ticket
on this
when Trinidad was in incubator but I haven't checked to see if it's
still there. I'll check it out.
2. The javascript libraries are not namespaced meaning two trinidad
portlets on the screen at the same time may conflict. Again, I had a
JIRA ticket
trinidad
portlets on the screen at the same time may conflict. Again, I
had a
JIRA ticket on this and I'll check the current status.
3. PPR in Trinidad has been disabled in a portal environment.
Things
that would normally do a ppr, will do a full-page submit instead
Other
haven't checked to see if it's
still there. I'll check it out.
2. The javascript libraries are not namespaced meaning two trinidad
portlets on the screen at the same time may conflict. Again, I had a
JIRA ticket on this and I'll check the current status.
3. PPR in Trinidad has been disabled
works with the following limitations:
1. Some of the popup support does not work. I had a JIRA ticket on this
when Trinidad was in incubator but I haven't checked to see if it's
still there. I'll check it out.
2. The javascript libraries are not namespaced meaning two trinidad
portlets
are not namespaced meaning two trinidad
portlets on the screen at the same time may conflict. Again, I had a
JIRA ticket on this and I'll check the current status.
3. PPR in Trinidad has been disabled in a portal environment. Things
that would normally do a ppr, will do a full-page submit instead
Other
PROTECTED]
Betreff: Re: trinidad and portlets
can you post trinidad questions on the trinidad list?
AFAIK it *should* run inside a portlet container
On 8/8/06, Rogerio Pereira [EMAIL PROTECTED] wrote:
I'm not sure if the same hack exists for HttpServletResponse (in Pluto)
http
hi there,
does anyone know if jsr168 portlets can handle trinidad(ADF Faces) elements? so
far i wasnŽt sucessfull trying to integrate them into portlets because of
problems with the render kit (faces renderer).
regards
_
Der
the cast from PortletResponse to ServletResponse is possible.
2006/8/8, Nicolas Kalkhof [EMAIL PROTECTED]:
hi there,does anyone know if jsr168 portlets can handle trinidad(ADF Faces) elements? so far i wasnŽt sucessfull trying to integrate them into portlets because of problems with the render kit
ok, iŽll do that tonight. currently iŽm using pluto 1.1.
regards
-Ursprüngliche Nachricht-
Von: MyFaces Discussion users@myfaces.apache.org
Gesendet: 08.08.06 13:15:39
An: MyFaces Discussion users@myfaces.apache.org
Betreff: Re: trinidad and portlets
Please post the stacktrace
portlets can handle trinidad(ADF Faces) elements? so far i wasnt sucessfull trying to integrate them into portlets because of problems with the render kit (faces renderer).
regards _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer
29 matches
Mail list logo
