You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2007/07/31 13:21:32 UTC
[TRINIDAD] and portlets, next issues
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
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
Martin,
So I guess my question is, then, why aren't you using the body renderer?
I suppose that we could switch the partialPageSubmit function itself
based on the capabilities. It's not something I did initially.
Scott
Martin Marinschek wrote:
> Hi Scott,
>
> but essentially, with all these checks in place, still the
> partialPageSubmit function is rendered out in this part of the code.
> Therefore, only client-side code can change something about the
> partial page submit, which it doesn't, if _checkLoadNoPPR is not
> called.
>
> regards,
>
> Martin
>
> On 7/31/07, Scott O'Bryan <da...@gmail.com> wrote:
>
>> The rendering capabilities are set in the CoreRenderingContext in the
>> _initializeAgent method. This is based off of the outputMode which is
>> returned by the RequestContext. Basically the capabilities for
>> TrinidadAgent.CAP_PARTIAL_RENDERING are set to false on the Trinidad
>> agent and there are several functions in CoreRenderUtils,
>> PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
>> this capability.
>>
>> Scott
>>
>> 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
>>> back to you
>>>
>>>
>>> Martin Marinschek wrote:
>>>
>>>> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
>>>>>>> now.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Same goes for sorting columns...
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>>
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
>>>>>>>>>> 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 < martin.marinschek@gmail.com>
>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Scott,
but essentially, with all these checks in place, still the
partialPageSubmit function is rendered out in this part of the code.
Therefore, only client-side code can change something about the
partial page submit, which it doesn't, if _checkLoadNoPPR is not
called.
regards,
Martin
On 7/31/07, Scott O'Bryan <da...@gmail.com> wrote:
> The rendering capabilities are set in the CoreRenderingContext in the
> _initializeAgent method. This is based off of the outputMode which is
> returned by the RequestContext. Basically the capabilities for
> TrinidadAgent.CAP_PARTIAL_RENDERING are set to false on the Trinidad
> agent and there are several functions in CoreRenderUtils,
> PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
> this capability.
>
> Scott
>
> 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
> > back to you
> >
> >
> > Martin Marinschek wrote:
> >> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
> >>>>> now.
> >>>>>
> >>>>> regards,
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Same goes for sorting columns...
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>>
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
> >>>>>>>> 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 < martin.marinschek@gmail.com>
> >>>>>>>>> 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
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
yes, and exactly such a piece of code I must have found - obviously
the client-side switch to full page submit is not fully implemented in
the portlet case.
regards,
Martin
On 7/31/07, Adam Winer <aw...@gmail.com> wrote:
> CAP_PARTIAL_RENDERING is only partly used these days - it
> once was followed religiously, as all Java code rendered both
> PPR and non-PPR versions, but now some code now only renders
> PPR markup and relies on the client code to switch back to
> full page rendering if needed.
>
> -- Adam
>
>
>
> On 7/31/07, Scott O'Bryan <da...@gmail.com> wrote:
> > The rendering capabilities are set in the CoreRenderingContext in the
> > _initializeAgent method. This is based off of the outputMode which is
> > returned by the RequestContext. Basically the capabilities for
> > TrinidadAgent.CAP_PARTIAL_RENDERING are set to false on the Trinidad
> > agent and there are several functions in CoreRenderUtils,
> > PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
> > this capability.
> >
> > Scott
> >
> > 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
> > > back to you
> > >
> > >
> > > Martin Marinschek wrote:
> > >> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
> > >>>>
> > >>>>
> > >>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
> > >>>>> now.
> > >>>>>
> > >>>>> regards,
> > >>>>>
> > >>>>> Martin
> > >>>>>
> > >>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> Same goes for sorting columns...
> > >>>>>>>>
> > >>>>>>>> regards,
> > >>>>>>>>
> > >>>>>>>> Martin
> > >>>>>>>>
> > >>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
> > >>>>>>>> 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 < martin.marinschek@gmail.com>
> > >>>>>>>>> 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
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
Yeah, I would so it doesn't fall through the cracks. There are a number
of JIRA issues logged which I haven't really thought about fixing yet.
I'm not sure it needs to be fixed for the next release (especially
because I'm assuming I'll have some 301 work to do when we get the
bridge checked in), but it should definitely be looked at.
Scott
Martin Marinschek wrote:
> Hi guys,
>
> sure, both propositions will work. For now (and for my purposes, and
> maybe also the one of others who have followed this thread), also my
> workaround does.
>
> However, should I file an issue, so that you have something you can
> rely on if need be?
>
> regards,
>
> Martin
>
> On 8/1/07, Scott O'Bryan <da...@gmail.com> wrote:
>
>> Hey, that's an interesting idea. It's so crazy it just might work.
>>
>> For the short term, I'm sure we can modify the _partialPageSubmit script
>> to just call the full submit script. I looked at doing that when I
>> first added in the portal code, but the current mechanism seemed to work
>> correctly and I was trying to avoid having a PPR and NoPPR set of
>> javascripts.
>>
>> Scott
>>
>> Adam Winer wrote:
>>
>>> True. And "unfortunately", we don't require any special root
>>> component for PPR.
>>>
>>> For 1.0.3, I'd like to look at adding support for booting up
>>> parts of the RenderingContext on the fly, during rendering,
>>> so that we're no longer quite so dependent on having
>>> FormRenderer or BodyRenderer execute for various parts
>>> of functionality.
>>>
>>> -- Adam
>>>
>>>
>>>
>>
>
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
Hi guys,
sure, both propositions will work. For now (and for my purposes, and
maybe also the one of others who have followed this thread), also my
workaround does.
However, should I file an issue, so that you have something you can
rely on if need be?
regards,
Martin
On 8/1/07, Scott O'Bryan <da...@gmail.com> wrote:
> Hey, that's an interesting idea. It's so crazy it just might work.
>
> For the short term, I'm sure we can modify the _partialPageSubmit script
> to just call the full submit script. I looked at doing that when I
> first added in the portal code, but the current mechanism seemed to work
> correctly and I was trying to avoid having a PPR and NoPPR set of
> javascripts.
>
> Scott
>
> Adam Winer wrote:
> > True. And "unfortunately", we don't require any special root
> > component for PPR.
> >
> > For 1.0.3, I'd like to look at adding support for booting up
> > parts of the RenderingContext on the fly, during rendering,
> > so that we're no longer quite so dependent on having
> > FormRenderer or BodyRenderer execute for various parts
> > of functionality.
> >
> > -- Adam
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
Hey, that's an interesting idea. It's so crazy it just might work.
For the short term, I'm sure we can modify the _partialPageSubmit script
to just call the full submit script. I looked at doing that when I
first added in the portal code, but the current mechanism seemed to work
correctly and I was trying to avoid having a PPR and NoPPR set of
javascripts.
Scott
Adam Winer wrote:
> True. And "unfortunately", we don't require any special root
> component for PPR.
>
> For 1.0.3, I'd like to look at adding support for booting up
> parts of the RenderingContext on the fly, during rendering,
> so that we're no longer quite so dependent on having
> FormRenderer or BodyRenderer execute for various parts
> of functionality.
>
> -- Adam
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Adam Winer <aw...@gmail.com>.
True. And "unfortunately", we don't require any special root
component for PPR.
For 1.0.3, I'd like to look at adding support for booting up
parts of the RenderingContext on the fly, during rendering,
so that we're no longer quite so dependent on having
FormRenderer or BodyRenderer execute for various parts
of functionality.
-- Adam
On 7/31/07, Scott O'Bryan <da...@gmail.com> wrote:
> Adam,
>
> I know, but the functionality of the partialSubmit javascript changes
> based on capability. So any renderer using this function will do a full
> page submit instead of a partial one. This means that only when the
> full page submit is unacceptable does a component need to worry about
> having special handling for this capability. Right now a few of them do
> but like 99% of them work as-is.
>
> As Martin pointed out, however, this is only done if the BodyRenderer is
> used.
>
> Scott
>
> Adam Winer wrote:
> > CAP_PARTIAL_RENDERING is only partly used these days - it
> > once was followed religiously, as all Java code rendered both
> > PPR and non-PPR versions, but now some code now only renders
> > PPR markup and relies on the client code to switch back to
> > full page rendering if needed.
> >
> > -- Adam
> >
> >
> >
> > On 7/31/07, Scott O'Bryan <da...@gmail.com> wrote:
> >
> >> The rendering capabilities are set in the CoreRenderingContext in the
> >> _initializeAgent method. This is based off of the outputMode which is
> >> returned by the RequestContext. Basically the capabilities for
> >> TrinidadAgent.CAP_PARTIAL_RENDERING are set to false on the Trinidad
> >> agent and there are several functions in CoreRenderUtils,
> >> PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
> >> this capability.
> >>
> >> Scott
> >>
> >> 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
> >>> back to you
> >>>
> >>>
> >>> Martin Marinschek wrote:
> >>>
> >>>> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
> >>>>>>> now.
> >>>>>>>
> >>>>>>> regards,
> >>>>>>>
> >>>>>>> Martin
> >>>>>>>
> >>>>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Same goes for sorting columns...
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>>
> >>>>>>>>>> Martin
> >>>>>>>>>>
> >>>>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
> >>>>>>>>>> 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 < martin.marinschek@gmail.com>
> >>>>>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
Adam,
I know, but the functionality of the partialSubmit javascript changes
based on capability. So any renderer using this function will do a full
page submit instead of a partial one. This means that only when the
full page submit is unacceptable does a component need to worry about
having special handling for this capability. Right now a few of them do
but like 99% of them work as-is.
As Martin pointed out, however, this is only done if the BodyRenderer is
used.
Scott
Adam Winer wrote:
> CAP_PARTIAL_RENDERING is only partly used these days - it
> once was followed religiously, as all Java code rendered both
> PPR and non-PPR versions, but now some code now only renders
> PPR markup and relies on the client code to switch back to
> full page rendering if needed.
>
> -- Adam
>
>
>
> On 7/31/07, Scott O'Bryan <da...@gmail.com> wrote:
>
>> The rendering capabilities are set in the CoreRenderingContext in the
>> _initializeAgent method. This is based off of the outputMode which is
>> returned by the RequestContext. Basically the capabilities for
>> TrinidadAgent.CAP_PARTIAL_RENDERING are set to false on the Trinidad
>> agent and there are several functions in CoreRenderUtils,
>> PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
>> this capability.
>>
>> Scott
>>
>> 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
>>> back to you
>>>
>>>
>>> Martin Marinschek wrote:
>>>
>>>> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
>>>>>>> now.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Same goes for sorting columns...
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>>
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
>>>>>>>>>> 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 < martin.marinschek@gmail.com>
>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Adam Winer <aw...@gmail.com>.
CAP_PARTIAL_RENDERING is only partly used these days - it
once was followed religiously, as all Java code rendered both
PPR and non-PPR versions, but now some code now only renders
PPR markup and relies on the client code to switch back to
full page rendering if needed.
-- Adam
On 7/31/07, Scott O'Bryan <da...@gmail.com> wrote:
> The rendering capabilities are set in the CoreRenderingContext in the
> _initializeAgent method. This is based off of the outputMode which is
> returned by the RequestContext. Basically the capabilities for
> TrinidadAgent.CAP_PARTIAL_RENDERING are set to false on the Trinidad
> agent and there are several functions in CoreRenderUtils,
> PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
> this capability.
>
> Scott
>
> 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
> > back to you
> >
> >
> > Martin Marinschek wrote:
> >> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
> >>>>> now.
> >>>>>
> >>>>> regards,
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Same goes for sorting columns...
> >>>>>>>>
> >>>>>>>> regards,
> >>>>>>>>
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
> >>>>>>>> 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 < martin.marinschek@gmail.com>
> >>>>>>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
The rendering capabilities are set in the CoreRenderingContext in the
_initializeAgent method. This is based off of the outputMode which is
returned by the RequestContext. Basically the capabilities for
TrinidadAgent.CAP_PARTIAL_RENDERING are set to false on the Trinidad
agent and there are several functions in CoreRenderUtils,
PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
this capability.
Scott
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
> back to you
>
>
> Martin Marinschek wrote:
>> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
>>>>
>>>>
>>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
>>>>> now.
>>>>>
>>>>> regards,
>>>>>
>>>>> Martin
>>>>>
>>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Same goes for sorting columns...
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
>>>>>>>> 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 < martin.marinschek@gmail.com>
>>>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
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
> back to you
>
>
> Martin Marinschek wrote:
>> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
>>>>
>>>>
>>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper
>>>>> now.
>>>>>
>>>>> regards,
>>>>>
>>>>> Martin
>>>>>
>>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Same goes for sorting columns...
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com>
>>>>>>>> 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 < martin.marinschek@gmail.com>
>>>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
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 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
>>>
>>>
>>>> ExternalContextUtils.isPortal is working, I am about to dig deeper now.
>>>>
>>>> regards,
>>>>
>>>> Martin
>>>>
>>>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> Same goes for sorting columns...
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com> 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 < martin.marinschek@gmail.com> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
> >
> >> ExternalContextUtils.isPortal is working, I am about to dig deeper now.
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
> >>>>
> >>>>> Same goes for sorting columns...
> >>>>>
> >>>>> regards,
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com> 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 < martin.marinschek@gmail.com> 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
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
>> ExternalContextUtils.isPortal is working, I am about to dig deeper now.
>>
>> regards,
>>
>> Martin
>>
>> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
>>>>
>>>>> Same goes for sorting columns...
>>>>>
>>>>> regards,
>>>>>
>>>>> Martin
>>>>>
>>>>> On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com> 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 < martin.marinschek@gmail.com> 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
>>
>>
>
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ma...@gmail.com> wrote:
> ExternalContextUtils.isPortal is working, I am about to dig deeper now.
>
> regards,
>
> Martin
>
> On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
> > > > Same goes for sorting columns...
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com> 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 < martin.marinschek@gmail.com> 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
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
ExternalContextUtils.isPortal is working, I am about to dig deeper now.
regards,
Martin
On 7/31/07, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 < martin.marinschek@gmail.com> wrote:
> > > Same goes for sorting columns...
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/31/07, Martin Marinschek < martin.marinschek@gmail.com> 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 < martin.marinschek@gmail.com> 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
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
> >
> > Same goes for sorting columns...
> >
> > regards,
> >
> > Martin
> >
> > On 7/31/07, Martin Marinschek <ma...@gmail.com> 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 <ma...@gmail.com> 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
> >
>
>
Re: [TRINIDAD] and portlets, next issues
Posted by Scott O'Bryan <da...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> Same goes for sorting columns...
>
> regards,
>
> Martin
>
> On 7/31/07, Martin Marinschek <ma...@gmail.com> 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 <ma...@gmail.com> 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
>
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
Same goes for sorting columns...
regards,
Martin
On 7/31/07, Martin Marinschek <ma...@gmail.com> 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 <ma...@gmail.com> 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
Re: [TRINIDAD] and portlets, next issues
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ma...@gmail.com> 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