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
available here.
regards,
Martin
On 7/31/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> 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 context. I think the code might be in
> RenderingContext for this.
>
> Scott
>
> Martin Marinschek wrote:
> > 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 anywhere else. Hrmmpf...
> >
> > So what I did now to work around this, is:
> >
> > <body onload="_checkLoadNoPPR();">
> >
> > in my template.xhtml. I'll note down "ugly hacks for 400 - what is
> > disabling PPR in the portlet container?" for this ;)
> >
> > regards,
> >
> > Martin
> >
> > On 7/31/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> >
> >> 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
> >>> failing the ExternalContextUtils.isPortal check using your bridge?
> >>>
> >>> Scott
> >>>
> >>>
> >>> On 7/31/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> 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, Martin Marinschek < [EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> 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
> >>>
> >>>>>> :
> >>>>>> ProcessUtils.renderNavSubmitScript(context,
> >>>>>>
> >>> arc);
> >>>
> >>>>>> in renderNavSubmitScript, the scriptlet:
> >>>>>>
> >>>>>> static private final String _NAV_SUBMIT_SCRIPT =
> >>>>>> "function _navSubmit(formName, event, id, vld, val)"
> >>>>>> +"{"
> >>>>>> + "return _submitPartialChange("
> >>>>>> + "formName,"
> >>>>>> + "vld,"
> >>>>>> + "{"
> >>>>>> + "event:event,"
> >>>>>> + "source:id,"
> >>>>>> + "value:val});}";
> >>>>>>
> >>>>>> is rendered, and that's obviously ppr-code - I don't find the call to:
> >>>>>>
> >>>>>> PartialPageUtils.isPPRActive(context)
> >>>>>>
> >>>>>> anywhere through to this line, so obviously this is rendered even if
> >>>>>> PPR is not active :(
> >>>>>>
> >>>>>> regards,
> >>>>>>
> >>>>>> Martin
> >>>>>>
> >>>>>> On 7/31/07, Martin Marinschek < [EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>> 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 pager component, I
> >>>>>>> get the following JavaScript-error:
> >>>>>>>
> >>>>>>> ["Invalid PPR response. The response-headers were:\nServer:
> >>>>>>> Apache-Coyote/1.1\nPragma: No-cache\nCache-Co..."]
> >>>>>>>
> >>>>>>> Looks like the switching doesn't work...
> >>>>>>>
> >>>>>>> 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
