You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Martin Maidhof <ma...@wemove.com> on 2006/01/27 19:59:29 UTC
How to clear RenderParameters set in action ?
Hi,
is there a way to clear the render parameters (set in the action
method) in the RENDER method of the portlet ?
Scenario:
- the action method sets render parameters for all sub-sequent
render calls (ActionResponse.setRenderParameter() )
- the doView() method receives this parameters and renders the
right state, so far so good
- but now the portlet gets a message in its RENDER method
(via portlet messaging -> see AbstractVelocityMessagingPortlet)
that it should clear its state (meaning clear the RenderParameters)
How to do that if the action method isn't called ???
I can't find this in the spec ! (it would be nice if you could clear
the parameters in the RenderResponse BUT THIS FUNCTIONALITY IS
MISSING ... or am i missing something ?)
thx for every reply,
Martin
--
. frankfurt am main, -5°c, die gefühlte temperatur
liegt bei -11°c. zur zeit keine wolken unter 1500 m
und keine kumulunimbus oder gewitterwolken. die
sichtweite reicht weiter als 10 km.
< martin maidhof
martin@wemove.com
t +49 69 759003 14
wemove digital solutions GmbH
www.wemove.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clear RenderParameters set in action ?
Posted by David Sean Taylor <da...@bluesunrise.com>.
Martin Maidhof wrote:
> Hi,
>
> is there a way to clear the render parameters (set in the action
> method) in the RENDER method of the portlet ?
>
> Scenario:
> - the action method sets render parameters for all sub-sequent
> render calls (ActionResponse.setRenderParameter() )
> - the doView() method receives this parameters and renders the
> right state, so far so good
> - but now the portlet gets a message in its RENDER method
> (via portlet messaging -> see AbstractVelocityMessagingPortlet)
> that it should clear its state (meaning clear the RenderParameters)
>
> How to do that if the action method isn't called ???
> I can't find this in the spec ! (it would be nice if you could clear
> the parameters in the RenderResponse BUT THIS FUNCTIONALITY IS
> MISSING ... or am i missing something ?)
>
> thx for every reply,
> Martin
You can't clear the parameters in the render phase, only in the action
phase. In fact the portlet-container must not propagate parameters
received in an action request to subsequent render requests of he
portlet. If a portlet wants to do that, it must set those in the
ActionResponse.
Our portlet messaging implementation is not standardized, so there is no
direct interaction between the two. Hopefully the next standard will
address these kind of issues
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: How to clear RenderParameters set in action ?
Posted by Frank Villarreal <f_...@tetco.com>.
Ate/David:
1) Thanks David ... for putting up with me ;-)
2) Thank you Ate ... for your "multi-purpose" navigational state
implementations
... and finally ...
3) Thanks Aaron, for pointing out the spec's mandate on this subject.
However, I must say that I do not agree with its verbiage. I think it makes
for some awkward site navigation, especially when dealing with complex
portlet user interfaces. One has but to have read this thread to see that
I'm certainly not alone in this opinion.
Anyways, thanks again to all and have a good day gentlemen (or night
depending on where you are)!
- Frank
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Sunday, January 29, 2006 05:15 PM
> To: Jetspeed Users List
> Subject: Re: How to clear RenderParameters set in action ?
>
>
> Hi all,
>
> Sorry for being a little too late for this thread to clear up
> matters quickly, but luckily David
> has already given the configuration examples to enable or disable
> session storage of render parameters.
>
> To summarize: Jetspeed currently provides three implementations
> for encoding and storing portletwindow
> state and parameters:
> a) fully encoded on the url (like for instance Pluto does):
> use class
> org.apache.jetspeed.container.state.impl.PathNavigationalState
> b) only portletwindow state (window state and portlet mode) are
> saved in the session, parameters
> are encoded on the url:
> use class
> org.apache.jetspeed.container.state.impl.SessionNavigationalState
> c) state and parameters are saved in the session (the default):
> use class
> org.apache.jetspeed.container.state.impl.SessionFullNavigationalState
>
> Franks's patch should not be needed if you change the assembly
> portal-url-generation.xml to use
> implementation class a) or b).
>
> I do share Aaron Evans's interpretation of PLT.12.2.3 which he
> provided very clearly in an earlier response.
> But, I also agree this might not be what everyone expects or
> wants, and the foremost reason I created
> three different implementations to choose from in the first place ;)
>
> Regards, Ate
>
> David Sean Taylor wrote:
> >
> > I think I see the issue here.
> >
> > I was looking at the URL, when I should have been looking at the result
> > of the API calls. The default configuration stores render parameters
> > state in the session. See portal-url-generation.xml.
> >
> > <!-- Navigation state we are currently using -->
> > <bean id="NavigationalState"
> >
> >
> class="org.apache.jetspeed.container.state.impl.SessionFullNavigat
> ionalState"
> >
> > singleton="false"
> > >
> > <constructor-arg><ref
> > bean="NavigationalStateCodec"/></constructor-arg>
> > </bean>
> >
> > If you don't want to make render parameters stateful, use
> > SessionNavigationalState instead:
> >
> > <!-- Navigation state we are currently using -->
> > <bean id="NavigationalState"
> >
> >
> class="org.apache.jetspeed.container.state.impl.SessionNavigationalState"
> > singleton="false"
> > >
> > <constructor-arg><ref
> > bean="NavigationalStateCodec"/></constructor-arg>
> > </bean>
> >
> >
> > IF you want to store navigational state in the URL, change your spring
> > configuration to:
> >
> > <!-- Navigation state we are currently using -->
> > <bean id="NavigationalState"
> >
> > class="org.apache.jetspeed.container.state.impl.PathNavigationalState"
> > singleton="false"
> > >
> > <constructor-arg><ref
> > bean="NavigationalStateCodec"/></constructor-arg>
> > </bean>
> >
> >
> > finally, another Nav state impl available:
> > PortletWindowRequestNavigationalState which also stores state in the
> > server side and allows for optionally render parameters when
> > synchronizes state
> >
> > /**
> > * true if for a targeted PortletWindow using StateFullParameters
> > the saved (in the session) render parameters
> > * must be cleared when synchronizing the states.
> > * Prevents the default behavior when using StateFullParameters to
> > copy the parameters from the session
> > * when no parameters are specified in the PortletURL.
> > * Used if for the targeted PortletWindow no render parameters are
> > specified.
> > */
> > private boolean clearParameters;
> >
> > public void setClearParameters(boolean ignoreParameters)
> > {
> > this.clearParameters = ignoreParameters;
> > }
> >
> > My apologies for not understanding this the first time.
> > Looks like you were getting the low wage support guy here
> instead of one
> > of the experts!
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: SEVERE ERROR: RenderRequest Parameters
Posted by Aaron Evans <aa...@gmail.com>.
Hey Frank,
yes, I realize it is a violation of the spec, I believe I am the one
who pointed it out in the first place way back when (or at the very
least, I was part of that conversation).
My environment is very controlled, so it is not a problem for me, but
I understand why this is a problem and I'm sure they'll get addressed
at some point.
-aaron
On 1/24/07, Frank Villarreal <f_...@tetco.com> wrote:
> Hi Aaron,
>
> I read the posted JIRA issue (http://issues.apache.org/jira/browse/JS2-605),
> I believe my problem is the exact one described .. however, I think it's a
> really, really bad idea to rely on the incorrect behaviour established by
> this "feature/bug". Sure, it works great when you're linking between PSML
> pages and want to pass some parameters to a single portlet-page ... but
> think about when you have "multiple" portlets on that PSML page that are
> dependant on like-named variables. You can get some pretty unpredicable
> results when there are "unexpected" request variables/values coming through
> in a request! I mean this bug really breaks the spec badly ... almost
> making it impossible to easily plug-in third party portlets without a lot of
> headaches ... as I'm finding out. From reading his JIRA comments, sounds
> like Ate is already aware of this.
>
> Ate:: Any idea or update on how you are going to make this behaviour
> "configurable"?
>
> - Frank
>
> > -----Original Message-----
> > From: Aaron Evans [mailto:aaronmevans@gmail.com]
> > Sent: Wednesday, January 24, 2007 12:33 PM
> > To: Jetspeed Users List
> > Subject: Re: SEVERE ERROR: RenderRequest Parameters
> >
> >
> > Hmmm, interesting...
> >
> > Note that if you append parameter name value pairs to the query string
> > of the URL for a jetspeed PSML URL, then you get the same behaviour.
> > I guess that makes sense in a way...
> >
> > This is a "feature" (as Ate mentions in that bug report) that I
> > exploit quite frequently with my application.
> >
> > -aaron
> >
> > On 1/24/07, Frank Villarreal <f_...@tetco.com> wrote:
> > > Ate,
> > >
> > > I ran some more tests (not yet on the latest trunk), but I
> > thought it might
> > > be useful and explain why you haven't been able to replicate
> > the error ...
> > >
> > > Only parameters that have NOT been encoded using the PortletURL
> > class are
> > > duplicated across portlet instances. So for example, if you
> > have an html
> > > form page that contains 50 fields that you are not able to encode using
> > > PortletURL, then when the form is submitted, every portlet in the same
> > > application on the same PSML page will also see those
> > parameters in their
> > > next doView request ...
> > >
> > > - Frank
> > >
> > > > -----Original Message-----
> > > > From: Ate Douma [mailto:ate@douma.nu]
> > > >
> > > > I've just tested with a 2.1-dev trunk snapshot of beginning this
> > > > month and can't reproduce the problem, using 2 portlets of the
> > > > same portlet applications on the
> > > > same page.>
> > >
> > >
> > >
> > >
> > > The information contained in this e-mail is confidential and is
> > intended only for the use of the individual
> > > or entity to which it is addressed. Dissemination,
> > distribution, copying or use of this e-mail is strictly prohibited.
> > > If you have received this message in error, please immediately
> > notify the sender and delete the message from your system.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
> >
>
>
>
>
> The information contained in this e-mail is confidential and is intended only for the use of the individual
> or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
> If you have received this message in error, please immediately notify the sender and delete the message from your system.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: SEVERE ERROR: RenderRequest Parameters
Posted by Aaron Evans <aa...@gmail.com>.
Right, it's request parameters from form values sent as part of an
HTTP POST that are problematic.
On 1/24/07, Frank Villarreal <f_...@tetco.com> wrote:
> Hello David,
>
> Yes I do encode my uris with the <portlet:actionURL> tag or with the
> PortletURL class (one and the same I believe). But that's not the issue.
> The uris work fine. It's the "other" fields on a page that are
> "unencodable" that are the problem ... for instance user-input in HTML
> <input> fields. I came across this error once I started coding some
> heavy-duty data collection applications ... and noticed that the wrong
> portlets were seeing the submitted data!
>
> - Frank
>
> > -----Original Message-----
> > From: David Sean Taylor [mailto:david@bluesunrise.com]
> > Sent: Wednesday, January 24, 2007 02:08 PM
> > To: Jetspeed Users List
> > Subject: Re: SEVERE ERROR: RenderRequest Parameters
> >
> >
> >
> > Have you considered the standard way to encode render parameters with
> > action or render URLs
> >
> > <portlet:actionURL var="nodeLink" >
> > <portlet:param name="node" value="${name}" />
> > </portlet:actionURL>
>
>
>
>
> The information contained in this e-mail is confidential and is intended only for the use of the individual
> or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
> If you have received this message in error, please immediately notify the sender and delete the message from your system.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: SEVERE ERROR: RenderRequest Parameters
Posted by Frank Villarreal <f_...@tetco.com>.
Hello David,
Yes I do encode my uris with the <portlet:actionURL> tag or with the
PortletURL class (one and the same I believe). But that's not the issue.
The uris work fine. It's the "other" fields on a page that are
"unencodable" that are the problem ... for instance user-input in HTML
<input> fields. I came across this error once I started coding some
heavy-duty data collection applications ... and noticed that the wrong
portlets were seeing the submitted data!
- Frank
> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Wednesday, January 24, 2007 02:08 PM
> To: Jetspeed Users List
> Subject: Re: SEVERE ERROR: RenderRequest Parameters
>
>
>
> Have you considered the standard way to encode render parameters with
> action or render URLs
>
> <portlet:actionURL var="nodeLink" >
> <portlet:param name="node" value="${name}" />
> </portlet:actionURL>
The information contained in this e-mail is confidential and is intended only for the use of the individual
or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
If you have received this message in error, please immediately notify the sender and delete the message from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: SEVERE ERROR: RenderRequest Parameters
Posted by David Sean Taylor <da...@bluesunrise.com>.
Frank Villarreal wrote:
> Hi Aaron,
>
> I read the posted JIRA issue (http://issues.apache.org/jira/browse/JS2-605),
> I believe my problem is the exact one described .. however, I think it's a
> really, really bad idea to rely on the incorrect behaviour established by
> this "feature/bug". Sure, it works great when you're linking between PSML
> pages and want to pass some parameters to a single portlet-page ... but
> think about when you have "multiple" portlets on that PSML page that are
> dependant on like-named variables. You can get some pretty unpredicable
> results when there are "unexpected" request variables/values coming through
> in a request! I mean this bug really breaks the spec badly ... almost
> making it impossible to easily plug-in third party portlets without a lot of
> headaches ... as I'm finding out. From reading his JIRA comments, sounds
> like Ate is already aware of this.
>
> Ate:: Any idea or update on how you are going to make this behaviour
> "configurable"?
>
Have you considered the standard way to encode render parameters with
action or render URLs
<portlet:actionURL var="nodeLink" >
<portlet:param name="node" value="${name}" />
</portlet:actionURL>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: SEVERE ERROR: RenderRequest Parameters
Posted by Frank Villarreal <f_...@tetco.com>.
Hi Aaron,
I read the posted JIRA issue (http://issues.apache.org/jira/browse/JS2-605),
I believe my problem is the exact one described .. however, I think it's a
really, really bad idea to rely on the incorrect behaviour established by
this "feature/bug". Sure, it works great when you're linking between PSML
pages and want to pass some parameters to a single portlet-page ... but
think about when you have "multiple" portlets on that PSML page that are
dependant on like-named variables. You can get some pretty unpredicable
results when there are "unexpected" request variables/values coming through
in a request! I mean this bug really breaks the spec badly ... almost
making it impossible to easily plug-in third party portlets without a lot of
headaches ... as I'm finding out. From reading his JIRA comments, sounds
like Ate is already aware of this.
Ate:: Any idea or update on how you are going to make this behaviour
"configurable"?
- Frank
> -----Original Message-----
> From: Aaron Evans [mailto:aaronmevans@gmail.com]
> Sent: Wednesday, January 24, 2007 12:33 PM
> To: Jetspeed Users List
> Subject: Re: SEVERE ERROR: RenderRequest Parameters
>
>
> Hmmm, interesting...
>
> Note that if you append parameter name value pairs to the query string
> of the URL for a jetspeed PSML URL, then you get the same behaviour.
> I guess that makes sense in a way...
>
> This is a "feature" (as Ate mentions in that bug report) that I
> exploit quite frequently with my application.
>
> -aaron
>
> On 1/24/07, Frank Villarreal <f_...@tetco.com> wrote:
> > Ate,
> >
> > I ran some more tests (not yet on the latest trunk), but I
> thought it might
> > be useful and explain why you haven't been able to replicate
> the error ...
> >
> > Only parameters that have NOT been encoded using the PortletURL
> class are
> > duplicated across portlet instances. So for example, if you
> have an html
> > form page that contains 50 fields that you are not able to encode using
> > PortletURL, then when the form is submitted, every portlet in the same
> > application on the same PSML page will also see those
> parameters in their
> > next doView request ...
> >
> > - Frank
> >
> > > -----Original Message-----
> > > From: Ate Douma [mailto:ate@douma.nu]
> > >
> > > I've just tested with a 2.1-dev trunk snapshot of beginning this
> > > month and can't reproduce the problem, using 2 portlets of the
> > > same portlet applications on the
> > > same page.>
> >
> >
> >
> >
> > The information contained in this e-mail is confidential and is
> intended only for the use of the individual
> > or entity to which it is addressed. Dissemination,
> distribution, copying or use of this e-mail is strictly prohibited.
> > If you have received this message in error, please immediately
> notify the sender and delete the message from your system.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
The information contained in this e-mail is confidential and is intended only for the use of the individual
or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
If you have received this message in error, please immediately notify the sender and delete the message from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: SEVERE ERROR: RenderRequest Parameters
Posted by Aaron Evans <aa...@gmail.com>.
Hmmm, interesting...
Note that if you append parameter name value pairs to the query string
of the URL for a jetspeed PSML URL, then you get the same behaviour.
I guess that makes sense in a way...
This is a "feature" (as Ate mentions in that bug report) that I
exploit quite frequently with my application.
-aaron
On 1/24/07, Frank Villarreal <f_...@tetco.com> wrote:
> Ate,
>
> I ran some more tests (not yet on the latest trunk), but I thought it might
> be useful and explain why you haven't been able to replicate the error ...
>
> Only parameters that have NOT been encoded using the PortletURL class are
> duplicated across portlet instances. So for example, if you have an html
> form page that contains 50 fields that you are not able to encode using
> PortletURL, then when the form is submitted, every portlet in the same
> application on the same PSML page will also see those parameters in their
> next doView request ...
>
> - Frank
>
> > -----Original Message-----
> > From: Ate Douma [mailto:ate@douma.nu]
> >
> > I've just tested with a 2.1-dev trunk snapshot of beginning this
> > month and can't reproduce the problem, using 2 portlets of the
> > same portlet applications on the
> > same page.>
>
>
>
>
> The information contained in this e-mail is confidential and is intended only for the use of the individual
> or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
> If you have received this message in error, please immediately notify the sender and delete the message from your system.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: SEVERE ERROR: RenderRequest Parameters
Posted by Frank Villarreal <f_...@tetco.com>.
Ate,
I ran some more tests (not yet on the latest trunk), but I thought it might
be useful and explain why you haven't been able to replicate the error ...
Only parameters that have NOT been encoded using the PortletURL class are
duplicated across portlet instances. So for example, if you have an html
form page that contains 50 fields that you are not able to encode using
PortletURL, then when the form is submitted, every portlet in the same
application on the same PSML page will also see those parameters in their
next doView request ...
- Frank
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
>
> I've just tested with a 2.1-dev trunk snapshot of beginning this
> month and can't reproduce the problem, using 2 portlets of the
> same portlet applications on the
> same page.>
The information contained in this e-mail is confidential and is intended only for the use of the individual
or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
If you have received this message in error, please immediately notify the sender and delete the message from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: SEVERE ERROR: RenderRequest Parameters
Posted by Frank Villarreal <f_...@tetco.com>.
Hi Ate,
Sorry for any misunderstanding ... when I said that the bug goes back to the
release candidates, I meant that I've been able to reproduce the error on my
own ( I haven't checked the JIRA list ). I'm currently using the 2.0 final
release. My tests are actually quite simple ... I wrote 2 distinct
portlets, in the same portlet-application, that each submit a simple request
containing a few render parameters ... then in the doView method of the
portlet, I simply iterate the parameter map from the RenderRequest and
output the values in the request to the console (System.out.println). What
I've noticed is that I'm seeing the parameters for my request in BOTH doView
methods of each portlet, which as far as I'm aware is incorrect behaviour
according to the JSR-168 spec. Now, like I mentioned in my previous post
... this only occurs when the portlets are displayed on the same PSML page
and are in the same portlet-application.
Per your request, I will download the latest "trunk" version and attempt to
reproduce. I will report back my results to this list as soon as I'm
finished.
- Frank
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Wednesday, January 24, 2007 07:48 AM
> To: Jetspeed Users List
> Subject: Re: SEVERE ERROR: RenderRequest Parameters
>
>
> Frank Villarreal wrote:
> > I'm not sure if this has been identified in JIRA or not ... but
> I've noticed
> > this error goes back to the Jetspeed 2 release candidate days ...
> Which version of Jetspeed-2 are you using?
> I've just tested with a 2.1-dev trunk snapshot of beginning this
> month and can't reproduce the problem, using 2 portlets of the
> same portlet applications on the
> same page.
> I also don't recall this specific problem from the list, can you
> point us to the earlier message(s) you are referring to?
> If you are currently not using an recent 2.1-dev trunk snapshot,
> can you retest with one and see if it has been "fixed" already?
>
> Also note, there is another "issue" related to query-string
> provided parameters: http://issues.apache.org/jira/browse/JS2-605
> But, reading your problem description you seem to have "shared"
> *render* parameters which is a different use case.
>
> Regards,
>
> Ate
>
> >
> > Whenever there are at least 2 portlets from the same portlet application
> > sharing a single PSML page, RenderRequest parameters submitted by one
> > portlet instance are visible to BOTH portlets (even though they are
> > completely different portlets) on each request. However, if the both
> > portlets happen to be from DIFFERENT portlet-apps, then the
> error appears to
> > not occur. I suppose this is some type of namespacing issue in the
> > underlying architecture ... not sure if this is a Jetspeed or
> Pluto issue.
> > Any ideas? This, at least for me is a show stopper b/c I have
> many portlets
> > I'd like to display side-by-side and am unable to do due to this error.
> > Kind of defeats the purpose of using a portal in the first place ...
> >
> > - Frank
> >
> >
> >
> >
> > The information contained in this e-mail is confidential and is
> intended only for the use of the individual
> > or entity to which it is addressed. Dissemination,
> distribution, copying or use of this e-mail is strictly prohibited.
> > If you have received this message in error, please immediately
> notify the sender and delete the message from your system.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
The information contained in this e-mail is confidential and is intended only for the use of the individual
or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
If you have received this message in error, please immediately notify the sender and delete the message from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: SEVERE ERROR: RenderRequest Parameters
Posted by Ate Douma <at...@douma.nu>.
Frank Villarreal wrote:
> I'm not sure if this has been identified in JIRA or not ... but I've noticed
> this error goes back to the Jetspeed 2 release candidate days ...
Which version of Jetspeed-2 are you using?
I've just tested with a 2.1-dev trunk snapshot of beginning this month and can't reproduce the problem, using 2 portlets of the same portlet applications on the
same page.
I also don't recall this specific problem from the list, can you point us to the earlier message(s) you are referring to?
If you are currently not using an recent 2.1-dev trunk snapshot, can you retest with one and see if it has been "fixed" already?
Also note, there is another "issue" related to query-string provided parameters: http://issues.apache.org/jira/browse/JS2-605
But, reading your problem description you seem to have "shared" *render* parameters which is a different use case.
Regards,
Ate
>
> Whenever there are at least 2 portlets from the same portlet application
> sharing a single PSML page, RenderRequest parameters submitted by one
> portlet instance are visible to BOTH portlets (even though they are
> completely different portlets) on each request. However, if the both
> portlets happen to be from DIFFERENT portlet-apps, then the error appears to
> not occur. I suppose this is some type of namespacing issue in the
> underlying architecture ... not sure if this is a Jetspeed or Pluto issue.
> Any ideas? This, at least for me is a show stopper b/c I have many portlets
> I'd like to display side-by-side and am unable to do due to this error.
> Kind of defeats the purpose of using a portal in the first place ...
>
> - Frank
>
>
>
>
> The information contained in this e-mail is confidential and is intended only for the use of the individual
> or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
> If you have received this message in error, please immediately notify the sender and delete the message from your system.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: SEVERE ERROR: RenderRequest Parameters
Posted by "J.Enrique Ruiz-Valenciano" <je...@gmail.com>.
Hi Michael,
By using the tag <portlet:namespace />, you can bypass the problem, but
I agree with Frank, it is a severe bug because the specification JSR-168
is very clear in this aspect:
PLT.11.1.1 Request Parameters
...
A portlet must not see any parameter targeted to other portlets.
...
>
>
>> I'm not sure if this has been identified in JIRA or not ... but I've
>> noticed
>> this error goes back to the Jetspeed 2 release candidate days ...
>>
>> Whenever there are at least 2 portlets from the same portlet application
>> sharing a single PSML page, RenderRequest parameters submitted by one
>> portlet instance are visible to BOTH portlets (even though they are
>> completely different portlets) on each request. However, if the both
>> portlets happen to be from DIFFERENT portlet-apps, then the error
>> appears to
>> not occur. I suppose this is some type of namespacing issue in the
>> underlying architecture ... not sure if this is a Jetspeed or Pluto
>> issue.
>> Any ideas? This, at least for me is a show stopper b/c I have many
>> portlets
>> I'd like to display side-by-side and am unable to do due to this error.
>> Kind of defeats the purpose of using a portal in the first place ...
>>
>> - Frank
>>
>>
>
> I'm guessing this is why the <portlet:namespace/> JSP tag exists.
>
> Everything (variables, functions, etc.) in every portlet we develop,
> has this prefix, to ensure it never happens.
> If it is actually incorrect behaviour, you'll then need functionality
> to allow portlets to share the render request parameters.
>
> Just ensure you have safe namespacing throughout (which is always a
> good idea for web/XML development) and there'll be no problems.
>
> Michael.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: SEVERE ERROR: RenderRequest Parameters
Posted by Frank Villarreal <f_...@tetco.com>.
Hi Michael,
Thanks for the suggestion! But, I think <portlet:namespace/> is intended
more for avoiding intra-page html/javascript naming conflicts, rather than
for the bug I'm experiencing. Besides, I'm installing portlets that I
didn't write, so I have no control over how their code was written and
whether or not they used the <portlet:namespace/> to prefix every single one
of their render parameters.
- Frank
> -----Original Message-----
> From: Michael Kearns [mailto:michael.kearns@saaconsultants.com]
> Sent: Wednesday, January 24, 2007 03:53 AM
> To: Jetspeed Users List
> Subject: Re: SEVERE ERROR: RenderRequest Parameters
>
>
> Frank Villarreal wrote:
>
> >I'm not sure if this has been identified in JIRA or not ... but
> I've noticed
> >this error goes back to the Jetspeed 2 release candidate days ...
> >
> >Whenever there are at least 2 portlets from the same portlet application
> >sharing a single PSML page, RenderRequest parameters submitted by one
> >portlet instance are visible to BOTH portlets (even though they are
> >completely different portlets) on each request. However, if the both
> >portlets happen to be from DIFFERENT portlet-apps, then the
> error appears to
> >not occur. I suppose this is some type of namespacing issue in the
> >underlying architecture ... not sure if this is a Jetspeed or
> Pluto issue.
> >Any ideas? This, at least for me is a show stopper b/c I have
> many portlets
> >I'd like to display side-by-side and am unable to do due to this error.
> >Kind of defeats the purpose of using a portal in the first place ...
> >
> >- Frank
> >
> >
>
> I'm guessing this is why the <portlet:namespace/> JSP tag exists.
>
> Everything (variables, functions, etc.) in every portlet we develop, has
> this prefix, to ensure it never happens.
> If it is actually incorrect behaviour, you'll then need functionality to
> allow portlets to share the render request parameters.
>
> Just ensure you have safe namespacing throughout (which is always a good
> idea for web/XML development) and there'll be no problems.
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
The information contained in this e-mail is confidential and is intended only for the use of the individual
or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
If you have received this message in error, please immediately notify the sender and delete the message from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: SEVERE ERROR: RenderRequest Parameters
Posted by Michael Kearns <mi...@saaconsultants.com>.
Frank Villarreal wrote:
>I'm not sure if this has been identified in JIRA or not ... but I've noticed
>this error goes back to the Jetspeed 2 release candidate days ...
>
>Whenever there are at least 2 portlets from the same portlet application
>sharing a single PSML page, RenderRequest parameters submitted by one
>portlet instance are visible to BOTH portlets (even though they are
>completely different portlets) on each request. However, if the both
>portlets happen to be from DIFFERENT portlet-apps, then the error appears to
>not occur. I suppose this is some type of namespacing issue in the
>underlying architecture ... not sure if this is a Jetspeed or Pluto issue.
>Any ideas? This, at least for me is a show stopper b/c I have many portlets
>I'd like to display side-by-side and am unable to do due to this error.
>Kind of defeats the purpose of using a portal in the first place ...
>
>- Frank
>
>
I'm guessing this is why the <portlet:namespace/> JSP tag exists.
Everything (variables, functions, etc.) in every portlet we develop, has
this prefix, to ensure it never happens.
If it is actually incorrect behaviour, you'll then need functionality to
allow portlets to share the render request parameters.
Just ensure you have safe namespacing throughout (which is always a good
idea for web/XML development) and there'll be no problems.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
SEVERE ERROR: RenderRequest Parameters
Posted by Frank Villarreal <f_...@tetco.com>.
I'm not sure if this has been identified in JIRA or not ... but I've noticed
this error goes back to the Jetspeed 2 release candidate days ...
Whenever there are at least 2 portlets from the same portlet application
sharing a single PSML page, RenderRequest parameters submitted by one
portlet instance are visible to BOTH portlets (even though they are
completely different portlets) on each request. However, if the both
portlets happen to be from DIFFERENT portlet-apps, then the error appears to
not occur. I suppose this is some type of namespacing issue in the
underlying architecture ... not sure if this is a Jetspeed or Pluto issue.
Any ideas? This, at least for me is a show stopper b/c I have many portlets
I'd like to display side-by-side and am unable to do due to this error.
Kind of defeats the purpose of using a portal in the first place ...
- Frank
The information contained in this e-mail is confidential and is intended only for the use of the individual
or entity to which it is addressed. Dissemination, distribution, copying or use of this e-mail is strictly prohibited.
If you have received this message in error, please immediately notify the sender and delete the message from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clear RenderParameters set in action ?
Posted by Ate Douma <at...@douma.nu>.
Hi all,
Sorry for being a little too late for this thread to clear up matters quickly, but luckily David
has already given the configuration examples to enable or disable session storage of render parameters.
To summarize: Jetspeed currently provides three implementations for encoding and storing portletwindow
state and parameters:
a) fully encoded on the url (like for instance Pluto does):
use class org.apache.jetspeed.container.state.impl.PathNavigationalState
b) only portletwindow state (window state and portlet mode) are saved in the session, parameters
are encoded on the url:
use class org.apache.jetspeed.container.state.impl.SessionNavigationalState
c) state and parameters are saved in the session (the default):
use class org.apache.jetspeed.container.state.impl.SessionFullNavigationalState
Franks's patch should not be needed if you change the assembly portal-url-generation.xml to use
implementation class a) or b).
I do share Aaron Evans's interpretation of PLT.12.2.3 which he provided very clearly in an earlier response.
But, I also agree this might not be what everyone expects or wants, and the foremost reason I created
three different implementations to choose from in the first place ;)
Regards, Ate
David Sean Taylor wrote:
>
> I think I see the issue here.
>
> I was looking at the URL, when I should have been looking at the result
> of the API calls. The default configuration stores render parameters
> state in the session. See portal-url-generation.xml.
>
> <!-- Navigation state we are currently using -->
> <bean id="NavigationalState"
>
> class="org.apache.jetspeed.container.state.impl.SessionFullNavigationalState"
>
> singleton="false"
> >
> <constructor-arg><ref
> bean="NavigationalStateCodec"/></constructor-arg>
> </bean>
>
> If you don't want to make render parameters stateful, use
> SessionNavigationalState instead:
>
> <!-- Navigation state we are currently using -->
> <bean id="NavigationalState"
>
> class="org.apache.jetspeed.container.state.impl.SessionNavigationalState"
> singleton="false"
> >
> <constructor-arg><ref
> bean="NavigationalStateCodec"/></constructor-arg>
> </bean>
>
>
> IF you want to store navigational state in the URL, change your spring
> configuration to:
>
> <!-- Navigation state we are currently using -->
> <bean id="NavigationalState"
>
> class="org.apache.jetspeed.container.state.impl.PathNavigationalState"
> singleton="false"
> >
> <constructor-arg><ref
> bean="NavigationalStateCodec"/></constructor-arg>
> </bean>
>
>
> finally, another Nav state impl available:
> PortletWindowRequestNavigationalState which also stores state in the
> server side and allows for optionally render parameters when
> synchronizes state
>
> /**
> * true if for a targeted PortletWindow using StateFullParameters
> the saved (in the session) render parameters
> * must be cleared when synchronizing the states.
> * Prevents the default behavior when using StateFullParameters to
> copy the parameters from the session
> * when no parameters are specified in the PortletURL.
> * Used if for the targeted PortletWindow no render parameters are
> specified.
> */
> private boolean clearParameters;
>
> public void setClearParameters(boolean ignoreParameters)
> {
> this.clearParameters = ignoreParameters;
> }
>
> My apologies for not understanding this the first time.
> Looks like you were getting the low wage support guy here instead of one
> of the experts!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clear RenderParameters set in action ?
Posted by David Sean Taylor <da...@bluesunrise.com>.
I think I see the issue here.
I was looking at the URL, when I should have been looking at the result
of the API calls. The default configuration stores render parameters
state in the session. See portal-url-generation.xml.
<!-- Navigation state we are currently using -->
<bean id="NavigationalState"
class="org.apache.jetspeed.container.state.impl.SessionFullNavigationalState"
singleton="false"
>
<constructor-arg><ref
bean="NavigationalStateCodec"/></constructor-arg>
</bean>
If you don't want to make render parameters stateful, use
SessionNavigationalState instead:
<!-- Navigation state we are currently using -->
<bean id="NavigationalState"
class="org.apache.jetspeed.container.state.impl.SessionNavigationalState"
singleton="false"
>
<constructor-arg><ref
bean="NavigationalStateCodec"/></constructor-arg>
</bean>
IF you want to store navigational state in the URL, change your spring
configuration to:
<!-- Navigation state we are currently using -->
<bean id="NavigationalState"
class="org.apache.jetspeed.container.state.impl.PathNavigationalState"
singleton="false"
>
<constructor-arg><ref
bean="NavigationalStateCodec"/></constructor-arg>
</bean>
finally, another Nav state impl available:
PortletWindowRequestNavigationalState which also stores state in the
server side and allows for optionally render parameters when
synchronizes state
/**
* true if for a targeted PortletWindow using StateFullParameters
the saved (in the session) render parameters
* must be cleared when synchronizing the states.
* Prevents the default behavior when using StateFullParameters to
copy the parameters from the session
* when no parameters are specified in the PortletURL.
* Used if for the targeted PortletWindow no render parameters are
specified.
*/
private boolean clearParameters;
public void setClearParameters(boolean ignoreParameters)
{
this.clearParameters = ignoreParameters;
}
My apologies for not understanding this the first time.
Looks like you were getting the low wage support guy here instead of one
of the experts!
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clear RenderParameters set in action ?
Posted by Aaron Evans <aa...@yahoo.ca>.
David Sean Taylor <david <at> bluesunrise.com> writes:
>
> Frank Villarreal wrote:
>
> >>We correctly keep the render parameters *until* an action on the
> >>targeted portlet is invoked. At that point the render parameters are
> >>cleared for the targeted portlet (only).
> >
> >
> > Ahhh, so it is by design (of the portlet spec). Hmmm ... am I alone in the
> > "portal/portlet" community in feeling that this behaviour seems
> > counter-intuitive for a web site?!? By "storing" the render parameters
> > until another action is called, you're basically duplicating the
> > functionallity of session variables, no? IMHO navigating off a page should
> > be another use-case where render-parameters should be cleared. This IS how
> > most well-designed web sites behave anyway ... at least in my experience.
> > How else would a user "get back" to the "top" of a portlet that is
> > multi-layered (many views) without being able to click the portal menu that
> > got them to the portlet in the first place? Just my 2 cents.
> >
>
> The parameters are lost if you navigate to another page
> But as long as you stay on the same page, they are posted back to your
> portlet. It gives you more possibilities for keeping state in the URL
> instead of using the session
>
An excerpt from the portal spec:
------------------------------------------------------
PLT.12.2.3 Render Parameters
Using the setRenderParameter and setRenderParameters methods of the
ActionResponse interface portlets may set render parameters during an action
request. A call to any of the setRenderParameter methods must replace any
parameter with the same name previously set. These parameters will be used in
all subsequent render requests until a new client request targets the portlet.
If no render parameters are setduring the processAction invocation, the render
request must not contain any request parameters.
------------------------------------------------------
I guess the question is does the re-calling of a portal page (HTTP GET to
a PSML page) constitute a client request targeting a portlet within it. My
interpretation would be no. Only portal links that directly target a portlet
would qualify. Thus, I would think that the correct behaviour would be to
*keep* the render parameters even if you navigate away from the page and
then back again.
I suppose it may seem somewhat redundant with session attributes, but these
are parameters that apply strictly to the render phase of a given portlet
instance for a given user/client. These are the parameters that allow a
client to put a portlet into a given state and be assured that it stays that
way until the user does something to alter it's state.
I think that the portal/portlet model is a bit of a paradigm shift when
compared to the traditional servlet model. It is necessary because of the
nature of a portal page in terms of aggregation and the sharing of a single
request/response for multiple applications. I think that this is what is
perhaps throwing some developers off as they get used to the new model.
Anyway, just my opinion, but I think that some clarification is needed around
when render parameters should indeed be cleared.
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: How to clear RenderParameters set in action ?
Posted by Frank Villarreal <f_...@tetco.com>.
OKAY,
Here we go. My test consisted of a portlet and 2 JSP views. The views are
both located in a folder named "jsp" which is directly under the "jetspeed"
folder. The first time I visit the page/psml housing this portlet, I see
the view named "page#1". The first thing I do is click the link that reads
"Go to page#2". This effectivley sets a render parameter named "v". At
this point I am looking at the view named "page#2" as expected. Now, I then
click any random menu tab in the jetspeed portal to go to a different
page/psml. Works fine. Then, I click the tab/menu corresponding to my
page/psml housing the TestPortlet and there she is ... the view named
"page#2" remains in sight! If the render parameters were indeed cleared on
page/psml-level requests, then I SHOULD be looking at a view that reads
"Viewing PAGE#1".
- Frank
Here is the code for the test I ran ...
1) THE PORTLET (TestPortlet.java)
package com.test.portlets;
import java.io.IOException;
import javax.portlet.*;
public class TestPortlet extends GenericPortlet {
public void init(PortletConfig config) throws PortletException {
super.init(config);
}
public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
PortletContext context = getPortletContext();
response.setContentType("text/html");
String strView = (request.getParameter("v") != null) ?
request.getParameter("v") : "page1.jsp";
PortletRequestDispatcher rd = context.getRequestDispatcher("/jsp/" +
strView);
rd.include(request, response);
}
public void processAction(ActionRequest request, ActionResponse
response) throws PortletException, IOException {
//NOT IMPLEMENTED
}
}
2) FIRST VIEW (page1.jsp)
<%@ page language="java" %>
<%@ page import="java.util.*" %>
<%@ page import="javax.portlet.*" %>
<%@ taglib uri='/WEB-INF/portlet.tld' prefix='portlet'%>
<portlet:defineObjects/>
<b>VIEWING PAGE#1</b><br>
<%
PortletURL renderUrl = renderResponse.createRenderURL();
Map mParams = new HashMap();
mParams.add("v", "page2.jsp");
renderUrl.setParameters(mParams);
%>
<a href="<%=renderUrl.toString()%>">Go to Page#2</a>
3) SECOND VIEW (page2.jsp)
<%@ page language="java" %>
<%@ page import="java.util.*" %>
<%@ page import="javax.portlet.*" %>
<%@ taglib uri='/WEB-INF/portlet.tld' prefix='portlet'%>
<portlet:defineObjects/>
<b>VIEWING PAGE#2</b><br>
<%
PortletURL renderUrl = renderResponse.createRenderURL();
Map mParams = new HashMap();
mParams.add("v", "page1.jsp");
renderUrl.setParameters(mParams);
%>
<a href="<%=renderUrl.toString()%>">Go to Page#1</a>
> David,
>
> I'll have to report back to you on this tomorrow. I have a
> J2-final installation running at home and I'll post the exact
> code I tested. I fairly certain your reported behaviour was not
> working in my use-case.
>
> - Frank
>
> > -----Original Message-----
> > From: David Sean Taylor [mailto:david@bluesunrise.com]
> > Sent: Friday, January 27, 2006 04:23 PM
> > To: Jetspeed Users List
> > Subject: Re: How to clear RenderParameters set in action ?
> > >>David Said:
> > >>The parameters are lost if you navigate to another page
> > >>But as long as you stay on the same page, they are posted back to your
> > >>portlet. It gives you more possibilities for keeping state in the URL
> > >>instead of using the session
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: How to clear RenderParameters set in action ?
Posted by Frank Villarreal <f_...@tetco.com>.
David,
I'll have to report back to you on this tomorrow. I have a J2-final
installation running at home and I'll post the exact code I tested. I
fairly certain your reported behaviour was not working in my use-case.
- Frank
> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Friday, January 27, 2006 04:23 PM
> To: Jetspeed Users List
> Subject: Re: How to clear RenderParameters set in action ?
>
>
> Frank Villarreal wrote:
> >>David Said:
> >>The parameters are lost if you navigate to another page
> >>But as long as you stay on the same page, they are posted back to your
> >>portlet. It gives you more possibilities for keeping state in the URL
> >>instead of using the session
> >
> >
> > David,
> >
> > I'm not seeing that behaviour ... I tried this with the J2 final version
> > recently. My render parameters remained even after I navigated
> to another
> > page in the portal and then came back to the original page where the
> > parameters were set.
> >
> Before sending the last email, I quickly tested on a live M3
> installation assuming that it would work the same way in 2.0.
> Let me test against 2.1-dev....
>
> Ok, so I go to the main page, maximize or switch to edit mode, and move
> from the Root Folder to DB Browser Demo to Public Content and back, the
> encoded portlet render parameters are lost when I come back to a page.
> Isn't this the behavior you required?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clear RenderParameters set in action ?
Posted by David Sean Taylor <da...@bluesunrise.com>.
Frank Villarreal wrote:
>>David Said:
>>The parameters are lost if you navigate to another page
>>But as long as you stay on the same page, they are posted back to your
>>portlet. It gives you more possibilities for keeping state in the URL
>>instead of using the session
>
>
> David,
>
> I'm not seeing that behaviour ... I tried this with the J2 final version
> recently. My render parameters remained even after I navigated to another
> page in the portal and then came back to the original page where the
> parameters were set.
>
Before sending the last email, I quickly tested on a live M3
installation assuming that it would work the same way in 2.0.
Let me test against 2.1-dev....
Ok, so I go to the main page, maximize or switch to edit mode, and move
from the Root Folder to DB Browser Demo to Public Content and back, the
encoded portlet render parameters are lost when I come back to a page.
Isn't this the behavior you required?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: How to clear RenderParameters set in action ?
Posted by Frank Villarreal <f_...@tetco.com>.
>David Said:
> The parameters are lost if you navigate to another page
> But as long as you stay on the same page, they are posted back to your
> portlet. It gives you more possibilities for keeping state in the URL
> instead of using the session
David,
I'm not seeing that behaviour ... I tried this with the J2 final version
recently. My render parameters remained even after I navigated to another
page in the portal and then came back to the original page where the
parameters were set.
- Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clear RenderParameters set in action ?
Posted by David Sean Taylor <da...@bluesunrise.com>.
Frank Villarreal wrote:
>>We correctly keep the render parameters *until* an action on the
>>targeted portlet is invoked. At that point the render parameters are
>>cleared for the targeted portlet (only).
>
>
> Ahhh, so it is by design (of the portlet spec). Hmmm ... am I alone in the
> "portal/portlet" community in feeling that this behaviour seems
> counter-intuitive for a web site?!? By "storing" the render parameters
> until another action is called, you're basically duplicating the
> functionallity of session variables, no? IMHO navigating off a page should
> be another use-case where render-parameters should be cleared. This IS how
> most well-designed web sites behave anyway ... at least in my experience.
> How else would a user "get back" to the "top" of a portlet that is
> multi-layered (many views) without being able to click the portal menu that
> got them to the portlet in the first place? Just my 2 cents.
>
The parameters are lost if you navigate to another page
But as long as you stay on the same page, they are posted back to your
portlet. It gives you more possibilities for keeping state in the URL
instead of using the session
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: How to clear RenderParameters set in action ?
Posted by Frank Villarreal <f_...@tetco.com>.
> David Sean Taylor wrote:
> We correctly keep the render parameters *until* an action on the
> targeted portlet is invoked. At that point the render parameters are
> cleared for the targeted portlet (only).
Ahhh, so it is by design (of the portlet spec). Hmmm ... am I alone in the
"portal/portlet" community in feeling that this behaviour seems
counter-intuitive for a web site?!? By "storing" the render parameters
until another action is called, you're basically duplicating the
functionallity of session variables, no? IMHO navigating off a page should
be another use-case where render-parameters should be cleared. This IS how
most well-designed web sites behave anyway ... at least in my experience.
How else would a user "get back" to the "top" of a portlet that is
multi-layered (many views) without being able to click the portal menu that
got them to the portlet in the first place? Just my 2 cents.
- Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clear RenderParameters set in action ?
Posted by David Sean Taylor <da...@bluesunrise.com>.
Frank Villarreal wrote:
> The idea of the portlet spec is for the doView (Render) method to strictly
> just render the view ... NOT change the state of the view as you are
> suggesting. Best bet is for you to change the parameters in the Action as
> the portlet spec intended. However, I have noticed that J2 still does not
> clear render parameters when navigating between pages. J2 (the latest
> version) seems to treat render parameters like session variables ... even
> after you navigate away from a page and come back to it ... something about
> that seems screwy to me. Can a J2 developer comment on this behaviour? Is
> this by design or a bug? Either way I applied my own patch to bypass this
> quirk.
>
We correctly keep the render parameters *until* an action on the
targeted portlet is invoked. At that point the render parameters are
cleared for the targeted portlet (only).
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: How to clear RenderParameters set in action ?
Posted by Frank Villarreal <f_...@tetco.com>.
The idea of the portlet spec is for the doView (Render) method to strictly
just render the view ... NOT change the state of the view as you are
suggesting. Best bet is for you to change the parameters in the Action as
the portlet spec intended. However, I have noticed that J2 still does not
clear render parameters when navigating between pages. J2 (the latest
version) seems to treat render parameters like session variables ... even
after you navigate away from a page and come back to it ... something about
that seems screwy to me. Can a J2 developer comment on this behaviour? Is
this by design or a bug? Either way I applied my own patch to bypass this
quirk.
- Frank
> -----Original Message-----
> From: Martin Maidhof [mailto:martin@wemove.com]
> Sent: Friday, January 27, 2006 12:59 PM
> To: Jetspeed Users List
> Subject: How to clear RenderParameters set in action ?
>
>
> Hi,
>
> is there a way to clear the render parameters (set in the action
> method) in the RENDER method of the portlet ?
>
> Scenario:
> - the action method sets render parameters for all sub-sequent
> render calls (ActionResponse.setRenderParameter() )
> - the doView() method receives this parameters and renders the
> right state, so far so good
> - but now the portlet gets a message in its RENDER method
> (via portlet messaging -> see AbstractVelocityMessagingPortlet)
> that it should clear its state (meaning clear the RenderParameters)
>
> How to do that if the action method isn't called ???
> I can't find this in the spec ! (it would be nice if you could clear
> the parameters in the RenderResponse BUT THIS FUNCTIONALITY IS
> MISSING ... or am i missing something ?)
>
> thx for every reply,
> Martin
> --
>
> . frankfurt am main, -5°c, die gefühlte temperatur
> liegt bei -11°c. zur zeit keine wolken unter 1500 m
> und keine kumulunimbus oder gewitterwolken. die
> sichtweite reicht weiter als 10 km.
>
> < martin maidhof
> martin@wemove.com
> t +49 69 759003 14
>
> wemove digital solutions GmbH
> www.wemove.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org