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 Edmund Urbani <em...@liland.org> on 2005/06/14 11:48:38 UTC
how do i get the User-Agent info?
I'm trying to find out the browser issuing the request in my portlet.
Looks like the portlet API provides no way to access the "User-Agent"
HTTP header info. At least, I found none. Is there some way to access
the servlet request? ...or some jetspeed-2 specific (non-JSR168) way to
get this HTTP header?
if all else fails, I'll probably have to solve this with javascript and
that would be... plain ugly.
cheers,
Edmund
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: J1.6 Add User (Oracle 9i)
Posted by Jonathan Hawkins <jo...@hawkinsweb.co.uk>.
Is there anyway to find out what sequence is trying to be used.
Thanks
Jon
jonathan.hawkins@hawkinsweb.co.uk wrote:
>I have J1.6 running on Orion against an Oracle 9i Database.
>
>When I try to add a user I get the following :-
>
>Caused by: java.sql.SQLException: ORA-02289: sequence does not exist
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:579)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1894)
> at
> oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:831)
> at
> oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2496)
> at
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2840)
> at
> oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:
>
>
>
>The following sequqnces exist in the database :-
>
>COFFEES_SEQ
>EMAIL_INBOX_SEQ
>JETSPEED_GROUP_PROFILE_SEQ
>JETSPEED_ROLE_PROFILE_SEQ
>JETSPEED_USER_PROFILE_SEQ
>PORTLET_CATEGORY_SEQ
>PORTLET_MEDIATYPE_SEQ
>PORTLET_PARAMETER_SEQ
>PORTLET_SEQ
>SECURITY_ACCESS_SEQ
>SECURITY_ALLOW_SEQ
>SECURITY_ENTRY_SEQ
>TURBINE_GROUP_SEQ
>TURBINE_PERMISSION_SEQ
>TURBINE_ROLE_PERMISSION_SEQ
>TURBINE_ROLE_SEQ
>TURBINE_USER_GROUP_ROLE_SEQ
>TURBINE_USER_SEQ
>
>I have populated the database using the supplied scripts and I tool the
>jetspeed-torque-om-1.6.jar from www.bluesunrise.com distribution for Oracle.
>
>I have looked at http://issues.apache.org/jira/browse/JS1-183 but code
>appears to be ok.
>
>Any Ideas,
>
>Jon
>
>
>
>
>
>---------------------------------------------------------------------
>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
J1.6 Add User (Oracle 9i)
Posted by jo...@hawkinsweb.co.uk.
I have J1.6 running on Orion against an Oracle 9i Database.
When I try to add a user I get the following :-
Caused by: java.sql.SQLException: ORA-02289: sequence does not exist
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:579)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1894)
at
oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:831)
at
oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2496)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2840)
at
oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:
The following sequqnces exist in the database :-
COFFEES_SEQ
EMAIL_INBOX_SEQ
JETSPEED_GROUP_PROFILE_SEQ
JETSPEED_ROLE_PROFILE_SEQ
JETSPEED_USER_PROFILE_SEQ
PORTLET_CATEGORY_SEQ
PORTLET_MEDIATYPE_SEQ
PORTLET_PARAMETER_SEQ
PORTLET_SEQ
SECURITY_ACCESS_SEQ
SECURITY_ALLOW_SEQ
SECURITY_ENTRY_SEQ
TURBINE_GROUP_SEQ
TURBINE_PERMISSION_SEQ
TURBINE_ROLE_PERMISSION_SEQ
TURBINE_ROLE_SEQ
TURBINE_USER_GROUP_ROLE_SEQ
TURBINE_USER_SEQ
I have populated the database using the supplied scripts and I tool the
jetspeed-torque-om-1.6.jar from www.bluesunrise.com distribution for Oracle.
I have looked at http://issues.apache.org/jira/browse/JS1-183 but code
appears to be ok.
Any Ideas,
Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Clearing render parameters?
Posted by Santiago Urrizola <ch...@yahoo.com.ar>.
Hi, i have the same problem to you, and i still try to fix it but dont have
it.
I want the psml paints the view page of my porlets every time i call it,
not the previous context.
Its posible to do that ?
----- Original Message -----
From: "Raphaël Luta" <ra...@apache.org>
To: "Jetspeed Users List" <je...@portals.apache.org>
Sent: Thursday, June 16, 2005 6:49 AM
Subject: Re: Clearing render parameters?
> Frank Villarreal wrote:
> > <snip>
>>
>> If you have a Menu link that reads "Home" and represents the "default"
>> page
>> for portal, is it not logical that the user should be taken "back" to
>> what
>> they first "saw" when they logged-in to the portal instead of the
>> "current
>> state" of that default page??? Reason being: the "current state" could be
>> several state changes deep into a "maximized" portlet that no longer
>> resembles what the user first saw ... therefore they become confused and
>> wonder what happened to the "home" page!
>>
>> It just seems to me that the spec is lacking in this regard.
>> Unfortunately,
>> I can't wait around for the spec to change (if it ever does), so I need
>> to
>> customize this ASAP in order to make my site intuitive for my users.
>>
>> - Frank
>>
>
> First, what version of Jetspeed are you using ? There was a bug in
> the render parameters were handled in Jetspeed M2 that should be
> fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>
> Second, if your portlets use URL parameters to keep their render state, as
> they
> should, simply using a default URL in the portal menu should get you where
> you
> want (ie http://myhost/myportal)
>
> Now, if your portlets also depend on session-bound parameters for your
> state,
> this is going to be trickier. AFAIK, J2 cannot access the sessions of the
> portlets themselves since they are in a different webapp and the Servlet
> API
> nor the Portlet API allows us to do this, so you'll need to customize J2
> itself to do it.
>
> Possible strategy:
> - Subclass the org.apache.jetspeed.commons.JetspeedContainerServlet and
> modify
> the doGet() to check for a CLEAR_SESSION request attribute. If this
> attribute
> is in the request, invalidate() the current session and create it anew
> (or
> manually clear all bound objects).
> (You'll need to patch
> org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter to
> automatically
> deploy with your new servlet and possibly manually patch the web.xml of
> already deployed portlet apps to use your customized container servlet)
>
> - Now, you simply need to set the CLEAR_SESSION request attribute by any
> mean
> (like a Portal level application or any portlet) to be able to
> automatically
> reset the sessions and thus the state of all your portlets.
>
> Let us know if this works for you and as always patches are welcome ;)
>
> --
> Raphaël Luta - raphael@apache.org
> Apache Portals - Enterprise Portal in Java
> http://portals.apache.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
___________________________________
A tu celular ¿no le falta algo?
Usá Yahoo! Messenger y Correo Yahoo! en tu teléfono celular.
Más información en http://movil.yahoo.com.ar
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Struts bridge problem - Code fragment
Posted by Santiago Urrizola <ch...@yahoo.com.ar>.
Hi to all, i see this fragment of code in the StrutsPorlet class of the
struts bridge M3 Version
String path = null;
String pageURL = request.getParameter(StrutsPortletURL.PAGE);
if (pageURL == null)
I think there ir the problem, becasuse when i link a psml (containing an
struts porlet) from the menu, the variable pageURL still have data, form a
previous call to this portlet... making that the porlet render the same
previous context when they must have render the content for de default page,
(ViewPage, defined in the portlet.xml)
Is this correct or is a bug ?
Is there anybody who see that ??
Thanks a lot
----- Original Message -----
From: "Raphaël Luta" <ra...@apache.org>
To: "Jetspeed Users List" <je...@portals.apache.org>
Sent: Tuesday, June 21, 2005 4:38 PM
Subject: Re: Clearing render parameters?
> If you access a portal by typing a straight URL and not using any
> session bound render parameters:
> - yes, you should have a "clean" state for your portal without any
> attached render parameters
> - yes, there was a bug in M2 that is fixed in M3 that could cause
> incorrect render parameters to be included.
>
> Frank Villarreal wrote:
>> Raphael,
>>
>> first off, thanks for the response. Second, are you saying that the
>> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
>> should clear the render parameters if I where to for instance, navigate
>> to
>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
>> build
>> ... the previous state (meaning the previous render parameters) are
>> somehow
>> persisted when I try that. Was that a bug or was that by design? I'm
>> now
>> confused.
>>
>> - Frank
>>
>>
>>>-----Original Message-----
>>>From: Raphaël Luta [mailto:raphael@apache.org]
>>>Sent: Thursday, June 16, 2005 04:49 AM
>>>To: Jetspeed Users List
>>>Subject: Re: Clearing render parameters?
>>>
>>>
>>>Frank Villarreal wrote:
>>> > <snip>
>>>
>>>>If you have a Menu link that reads "Home" and represents the
>>>
>>>"default" page
>>>
>>>>for portal, is it not logical that the user should be taken
>>>
>>>"back" to what
>>>
>>>>they first "saw" when they logged-in to the portal instead of
>>>
>>>the "current
>>>
>>>>state" of that default page??? Reason being: the "current
>>>
>>>state" could be
>>>
>>>>several state changes deep into a "maximized" portlet that no longer
>>>>resembles what the user first saw ... therefore they become confused and
>>>>wonder what happened to the "home" page!
>>>>
>>>>It just seems to me that the spec is lacking in this regard.
>>>
>>>Unfortunately,
>>>
>>>>I can't wait around for the spec to change (if it ever does),
>>>
>>>so I need to
>>>
>>>>customize this ASAP in order to make my site intuitive for my users.
>>>>
>>>>- Frank
>>>>
>>>
>>>First, what version of Jetspeed are you using ? There was a bug in
>>>the render parameters were handled in Jetspeed M2 that should be
>>>fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>>>
>>>Second, if your portlets use URL parameters to keep their render
>>>state, as they
>>>should, simply using a default URL in the portal menu should get
>>>you where you
>>>want (ie http://myhost/myportal)
>>>
>>>Now, if your portlets also depend on session-bound parameters for
>>>your state,
>>>this is going to be trickier. AFAIK, J2 cannot access the sessions of the
>>>portlets themselves since they are in a different webapp and the
>>>Servlet API
>>>nor the Portlet API allows us to do this, so you'll need to
>>>customize J2 itself
>>>to do it.
>>>
>>>Possible strategy:
>>>- Subclass the
>>>org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>>> the doGet() to check for a CLEAR_SESSION request attribute. If
>>>this attribute
>>> is in the request, invalidate() the current session and create
>>>it anew (or
>>> manually clear all bound objects).
>>> (You'll need to patch
>>>org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>>>to automatically
>>> deploy with your new servlet and possibly manually patch the
>>>web.xml of
>>>already deployed portlet apps to use your customized container servlet)
>>>
>>>- Now, you simply need to set the CLEAR_SESSION request attribute
>>>by any mean
>>> (like a Portal level application or any portlet) to be able to
>>>automatically
>>> reset the sessions and thus the state of all your portlets.
>>>
>>>Let us know if this works for you and as always patches are welcome ;)
>>>
>>>--
>>>Raphaël Luta - raphael@apache.org
>>>Apache Portals - Enterprise Portal in Java
>>>http://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
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Struts bridge problem - Code fragment
Posted by Santiago Urrizola <ch...@yahoo.com.ar>.
Hi to all, i see this fragment of code in the StrutsPorlet class of the
struts bridge M3 Version
String path = null;
String pageURL = request.getParameter(StrutsPortletURL.PAGE);
if (pageURL == null)
I think there ir the problem, becasuse when i link a psml (containing an
struts porlet) from the menu, the variable pageURL still have data, form a
previous call to this portlet... making that the porlet render the same
previous context when they must have render the content for de default page,
(ViewPage, defined in the portlet.xml)
Is this correct or is a bug ?
Is there anybody who see that ??
Thanks a lot
----- Original Message -----
From: "Raphaël Luta" <ra...@apache.org>
To: "Jetspeed Users List" <je...@portals.apache.org>
Sent: Tuesday, June 21, 2005 4:38 PM
Subject: Re: Clearing render parameters?
> If you access a portal by typing a straight URL and not using any
> session bound render parameters:
> - yes, you should have a "clean" state for your portal without any
> attached render parameters
> - yes, there was a bug in M2 that is fixed in M3 that could cause
> incorrect render parameters to be included.
>
> Frank Villarreal wrote:
>> Raphael,
>>
>> first off, thanks for the response. Second, are you saying that the
>> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
>> should clear the render parameters if I where to for instance, navigate
>> to
>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
>> build
>> ... the previous state (meaning the previous render parameters) are
>> somehow
>> persisted when I try that. Was that a bug or was that by design? I'm
>> now
>> confused.
>>
>> - Frank
>>
>>
>>>-----Original Message-----
>>>From: Raphaël Luta [mailto:raphael@apache.org]
>>>Sent: Thursday, June 16, 2005 04:49 AM
>>>To: Jetspeed Users List
>>>Subject: Re: Clearing render parameters?
>>>
>>>
>>>Frank Villarreal wrote:
>>> > <snip>
>>>
>>>>If you have a Menu link that reads "Home" and represents the
>>>
>>>"default" page
>>>
>>>>for portal, is it not logical that the user should be taken
>>>
>>>"back" to what
>>>
>>>>they first "saw" when they logged-in to the portal instead of
>>>
>>>the "current
>>>
>>>>state" of that default page??? Reason being: the "current
>>>
>>>state" could be
>>>
>>>>several state changes deep into a "maximized" portlet that no longer
>>>>resembles what the user first saw ... therefore they become confused and
>>>>wonder what happened to the "home" page!
>>>>
>>>>It just seems to me that the spec is lacking in this regard.
>>>
>>>Unfortunately,
>>>
>>>>I can't wait around for the spec to change (if it ever does),
>>>
>>>so I need to
>>>
>>>>customize this ASAP in order to make my site intuitive for my users.
>>>>
>>>>- Frank
>>>>
>>>
>>>First, what version of Jetspeed are you using ? There was a bug in
>>>the render parameters were handled in Jetspeed M2 that should be
>>>fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>>>
>>>Second, if your portlets use URL parameters to keep their render
>>>state, as they
>>>should, simply using a default URL in the portal menu should get
>>>you where you
>>>want (ie http://myhost/myportal)
>>>
>>>Now, if your portlets also depend on session-bound parameters for
>>>your state,
>>>this is going to be trickier. AFAIK, J2 cannot access the sessions of the
>>>portlets themselves since they are in a different webapp and the
>>>Servlet API
>>>nor the Portlet API allows us to do this, so you'll need to
>>>customize J2 itself
>>>to do it.
>>>
>>>Possible strategy:
>>>- Subclass the
>>>org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>>> the doGet() to check for a CLEAR_SESSION request attribute. If
>>>this attribute
>>> is in the request, invalidate() the current session and create
>>>it anew (or
>>> manually clear all bound objects).
>>> (You'll need to patch
>>>org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>>>to automatically
>>> deploy with your new servlet and possibly manually patch the
>>>web.xml of
>>>already deployed portlet apps to use your customized container servlet)
>>>
>>>- Now, you simply need to set the CLEAR_SESSION request attribute
>>>by any mean
>>> (like a Portal level application or any portlet) to be able to
>>>automatically
>>> reset the sessions and thus the state of all your portlets.
>>>
>>>Let us know if this works for you and as always patches are welcome ;)
>>>
>>>--
>>>Raphaël Luta - raphael@apache.org
>>>Apache Portals - Enterprise Portal in Java
>>>http://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
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Clearing render parameters?
Posted by Raphaël Luta <ra...@apache.org>.
If you access a portal by typing a straight URL and not using any
session bound render parameters:
- yes, you should have a "clean" state for your portal without any
attached render parameters
- yes, there was a bug in M2 that is fixed in M3 that could cause
incorrect render parameters to be included.
Frank Villarreal wrote:
> Raphael,
>
> first off, thanks for the response. Second, are you saying that the
> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
> should clear the render parameters if I where to for instance, navigate to
> "http://myhost/jetspeed/portal"??? This does not happen with the M2 build
> ... the previous state (meaning the previous render parameters) are somehow
> persisted when I try that. Was that a bug or was that by design? I'm now
> confused.
>
> - Frank
>
>
>>-----Original Message-----
>>From: Raphaël Luta [mailto:raphael@apache.org]
>>Sent: Thursday, June 16, 2005 04:49 AM
>>To: Jetspeed Users List
>>Subject: Re: Clearing render parameters?
>>
>>
>>Frank Villarreal wrote:
>> > <snip>
>>
>>>If you have a Menu link that reads "Home" and represents the
>>
>>"default" page
>>
>>>for portal, is it not logical that the user should be taken
>>
>>"back" to what
>>
>>>they first "saw" when they logged-in to the portal instead of
>>
>>the "current
>>
>>>state" of that default page??? Reason being: the "current
>>
>>state" could be
>>
>>>several state changes deep into a "maximized" portlet that no longer
>>>resembles what the user first saw ... therefore they become confused and
>>>wonder what happened to the "home" page!
>>>
>>>It just seems to me that the spec is lacking in this regard.
>>
>>Unfortunately,
>>
>>>I can't wait around for the spec to change (if it ever does),
>>
>>so I need to
>>
>>>customize this ASAP in order to make my site intuitive for my users.
>>>
>>>- Frank
>>>
>>
>>First, what version of Jetspeed are you using ? There was a bug in
>>the render parameters were handled in Jetspeed M2 that should be
>>fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>>
>>Second, if your portlets use URL parameters to keep their render
>>state, as they
>>should, simply using a default URL in the portal menu should get
>>you where you
>>want (ie http://myhost/myportal)
>>
>>Now, if your portlets also depend on session-bound parameters for
>>your state,
>>this is going to be trickier. AFAIK, J2 cannot access the sessions of the
>>portlets themselves since they are in a different webapp and the
>>Servlet API
>>nor the Portlet API allows us to do this, so you'll need to
>>customize J2 itself
>>to do it.
>>
>>Possible strategy:
>>- Subclass the
>>org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>> the doGet() to check for a CLEAR_SESSION request attribute. If
>>this attribute
>> is in the request, invalidate() the current session and create
>>it anew (or
>> manually clear all bound objects).
>> (You'll need to patch
>>org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>>to automatically
>> deploy with your new servlet and possibly manually patch the
>>web.xml of
>>already deployed portlet apps to use your customized container servlet)
>>
>>- Now, you simply need to set the CLEAR_SESSION request attribute
>>by any mean
>> (like a Portal level application or any portlet) to be able to
>>automatically
>> reset the sessions and thus the state of all your portlets.
>>
>>Let us know if this works for you and as always patches are welcome ;)
>>
>>--
>>Raphaël Luta - raphael@apache.org
>>Apache Portals - Enterprise Portal in Java
>>http://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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Clearing render parameters?
Posted by Santiago Urrizola <ch...@yahoo.com.ar>.
> +1 ... I too am only using the out-of-the-box menu rendering that happens
> in
> the velocity templates ... Santiago, do your portlets still appear to be
> using the "last" render parameters when you click directly on a page link?
> I'm curious since you're already using build M3.
Yes, that is exactly wath happens to my.
I lik to a psml page from the left menu, and the j2, render the last request
of the porlet in the psml page.
>
> - Frank
>
>> -----Original Message-----
>> From: Santiago Urrizola [mailto:chily_listas@yahoo.com.ar]
>> Sent: Tuesday, June 21, 2005 03:07 PM
>> To: Jetspeed Users List
>> Subject: Re: Clearing render parameters?
>>
>>
>> > This may be another one.
>> > There can be many reasons why you see previous state in your links:
>> > - you may have encoded the menu URLs with the render parameters thus
>> > keeping your state
>>
>> This is how my menus is painting, they not add nothing to the url
>> <a href="$jetspeed.getAbsoluteUrl($node.url)?init=true"
>> title="$node.getTitle($preferedLocale)">
>> • $node.getShortTitle($preferedLocale)
>> </a>
>>
>> > - there may be a bug in the cache manager
>> I debug the struts bridges, and i see that not remove the last url of
>> the portlet.
>>
>> > - the struts bridge may keep some state in session (I would need to
>> > check).
>> is posible, they keep the last url in the request, so when
>> try to render
>> the portlet, the render with the last url but i link the menu so its
>> imposible this situation.
>>
>>
>> >
>> > I guess what you experience is #1. You can easily check if your menu
>> > URLs encode the render parameters or not. Instead of using tour menu
>> > links, simply type your "basic" URL in the browser and see if state
>> > is as expected.
>> >
>> > --
>> > Raphaël Luta - raphael@apache.org
>> > Apache Portals - Enterprise Portal in Java
>> > http://portals.apache.org/
>> >
>> > Santiago Urrizola wrote:
>> >> Hi i use the M3 version and still happend this bug ?? its posible ??
>> >>
>> >> ----- Original Message ----- From: "Frank Villarreal"
>> >> <f_...@tetco.com>
>> >> To: "Jetspeed Users List" <je...@portals.apache.org>
>> >> Sent: Tuesday, June 21, 2005 4:18 PM
>> >> Subject: RE: Clearing render parameters?
>> >>
>> >>
>> >>> Answered my own question. See bug JS2-231. This has been fixed in
>> >>> Jetspeed2 M3 I believe. Now for the painful task of updating
>> my site to
>> >>> this new version. Yikes.
>> >>>
>> >>> - Frank
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
>> >>>> Sent: Tuesday, June 21, 2005 02:13 PM
>> >>>> To: Jetspeed Users List
>> >>>> Subject: RE: Clearing render parameters?
>> >>>>
>> >>>>
>> >>>> Raphael,
>> >>>>
>> >>>> first off, thanks for the response. Second, are you saying that the
>> >>>> "correct" behavior in Jetspeed2 (which is what I'm using ...
>> M2 build)
>> >>>> should clear the render parameters if I where to for
>> instance, navigate
>> >>>> to
>> >>>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
>> >>>> build
>> >>>> ... the previous state (meaning the previous render parameters)
>> >>>> are somehow
>> >>>> persisted when I try that. Was that a bug or was that by
>> design? I'm
>> >>>> now
>> >>>> confused.
>> >>>>
>> >>>> - Frank
>> >>>>
>> >>>> > -----Original Message-----
>> >>>> > From: Raphaël Luta [mailto:raphael@apache.org]
>> >>>> > Sent: Thursday, June 16, 2005 04:49 AM
>> >>>> > To: Jetspeed Users List
>> >>>> > Subject: Re: Clearing render parameters?
>> >>>> >
>> >>>> >
>> >>>> > Frank Villarreal wrote:
>> >>>> > > <snip>
>> >>>> > >
>> >>>> > > If you have a Menu link that reads "Home" and represents the
>> >>>> > "default" page
>> >>>> > > for portal, is it not logical that the user should be taken
>> >>>> > "back" to what
>> >>>> > > they first "saw" when they logged-in to the portal instead of
>> >>>> > the "current
>> >>>> > > state" of that default page??? Reason being: the "current
>> >>>> > state" could be
>> >>>> > > several state changes deep into a "maximized" portlet that no
>> >>>> > > longer
>> >>>> > > resembles what the user first saw ... therefore they become
>> >>>> confused and
>> >>>> > > wonder what happened to the "home" page!
>> >>>> > >
>> >>>> > > It just seems to me that the spec is lacking in this regard.
>> >>>> > Unfortunately,
>> >>>> > > I can't wait around for the spec to change (if it ever does),
>> >>>> > so I need to
>> >>>> > > customize this ASAP in order to make my site intuitive for my
>> >>>> > > users.
>> >>>> > >
>> >>>> > > - Frank
>> >>>> > >
>> >>>> >
>> >>>> > First, what version of Jetspeed are you using ? There was a bug in
>> >>>> > the render parameters were handled in Jetspeed M2 that should be
>> >>>> > fixed in M3 (JS2-231). So first advice is to update the M3
>> or M4-dev.
>> >>>> >
>> >>>> > Second, if your portlets use URL parameters to keep their render
>> >>>> > state, as they
>> >>>> > should, simply using a default URL in the portal menu should get
>> >>>> > you where you
>> >>>> > want (ie http://myhost/myportal)
>> >>>> >
>> >>>> > Now, if your portlets also depend on session-bound parameters for
>> >>>> > your state,
>> >>>> > this is going to be trickier. AFAIK, J2 cannot access the
>> >>>> sessions of the
>> >>>> > portlets themselves since they are in a different webapp and the
>> >>>> > Servlet API
>> >>>> > nor the Portlet API allows us to do this, so you'll need to
>> >>>> > customize J2 itself
>> >>>> > to do it.
>> >>>> >
>> >>>> > Possible strategy:
>> >>>> > - Subclass the
>> >>>> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>> >>>> > the doGet() to check for a CLEAR_SESSION request attribute. If
>> >>>> > this attribute
>> >>>> > is in the request, invalidate() the current session and create
>> >>>> > it anew (or
>> >>>> > manually clear all bound objects).
>> >>>> > (You'll need to patch
>> >>>> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>> >>>> > to automatically
>> >>>> > deploy with your new servlet and possibly manually patch the
>> >>>> > web.xml of
>> >>>> > already deployed portlet apps to use your customized container
>> >>>> servlet)
>> >>>> >
>> >>>> > - Now, you simply need to set the CLEAR_SESSION request attribute
>> >>>> > by any mean
>> >>>> > (like a Portal level application or any portlet) to be able to
>> >>>> > automatically
>> >>>> > reset the sessions and thus the state of all your portlets.
>> >>>> >
>> >>>> > Let us know if this works for you and as always patches
>> are welcome
>> >>>> > ;)
>> >>>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>> >
>>
>>
>>
>>
>>
>>
>> ___________________________________________________________
>> 1GB gratis, Antivirus y Antispam
>> Correo Yahoo!, el mejor correo web del mundo
>> http://correo.yahoo.com.ar
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: Clearing render parameters?
Posted by Frank Villarreal <f_...@tetco.com>.
Can someone reopen issue JS-231? I'd do it myself (b/c I need it so bad)
but I don't have write access to JIRA. This issue appears to still be
broken in release M3.
- Frank
> -----Original Message-----
> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
> Sent: Tuesday, June 21, 2005 03:22 PM
> To: Jetspeed Users List
> Subject: RE: Clearing render parameters?
>
>
> +1 ... I too am only using the out-of-the-box menu rendering that
> happens in
> the velocity templates ... Santiago, do your portlets still appear to be
> using the "last" render parameters when you click directly on a page link?
> I'm curious since you're already using build M3.
>
> - Frank
>
> > -----Original Message-----
> > From: Santiago Urrizola [mailto:chily_listas@yahoo.com.ar]
> > Sent: Tuesday, June 21, 2005 03:07 PM
> > To: Jetspeed Users List
> > Subject: Re: Clearing render parameters?
> >
> >
> > > This may be another one.
> > > There can be many reasons why you see previous state in your links:
> > > - you may have encoded the menu URLs with the render parameters thus
> > > keeping your state
> >
> > This is how my menus is painting, they not add nothing to the url
> > <a href="$jetspeed.getAbsoluteUrl($node.url)?init=true"
> > title="$node.getTitle($preferedLocale)">
> > • $node.getShortTitle($preferedLocale)
> > </a>
> >
> > > - there may be a bug in the cache manager
> > I debug the struts bridges, and i see that not remove the
> last url of
> > the portlet.
> >
> > > - the struts bridge may keep some state in session (I would need to
> > > check).
> > is posible, they keep the last url in the request, so when
> > try to render
> > the portlet, the render with the last url but i link the menu so its
> > imposible this situation.
> >
> >
> > >
> > > I guess what you experience is #1. You can easily check if your menu
> > > URLs encode the render parameters or not. Instead of using tour menu
> > > links, simply type your "basic" URL in the browser and see if state
> > > is as expected.
> > >
> > > --
> > > Raphaël Luta - raphael@apache.org
> > > Apache Portals - Enterprise Portal in Java
> > > http://portals.apache.org/
> > >
> > > Santiago Urrizola wrote:
> > >> Hi i use the M3 version and still happend this bug ?? its posible ??
> > >>
> > >> ----- Original Message ----- From: "Frank Villarreal"
> > >> <f_...@tetco.com>
> > >> To: "Jetspeed Users List" <je...@portals.apache.org>
> > >> Sent: Tuesday, June 21, 2005 4:18 PM
> > >> Subject: RE: Clearing render parameters?
> > >>
> > >>
> > >>> Answered my own question. See bug JS2-231. This has been fixed in
> > >>> Jetspeed2 M3 I believe. Now for the painful task of updating
> > my site to
> > >>> this new version. Yikes.
> > >>>
> > >>> - Frank
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
> > >>>> Sent: Tuesday, June 21, 2005 02:13 PM
> > >>>> To: Jetspeed Users List
> > >>>> Subject: RE: Clearing render parameters?
> > >>>>
> > >>>>
> > >>>> Raphael,
> > >>>>
> > >>>> first off, thanks for the response. Second, are you
> saying that the
> > >>>> "correct" behavior in Jetspeed2 (which is what I'm using ...
> > M2 build)
> > >>>> should clear the render parameters if I where to for
> > instance, navigate
> > >>>> to
> > >>>> "http://myhost/jetspeed/portal"??? This does not happen
> with the M2
> > >>>> build
> > >>>> ... the previous state (meaning the previous render parameters)
> > >>>> are somehow
> > >>>> persisted when I try that. Was that a bug or was that by
> > design? I'm
> > >>>> now
> > >>>> confused.
> > >>>>
> > >>>> - Frank
> > >>>>
> > >>>> > -----Original Message-----
> > >>>> > From: Raphaël Luta [mailto:raphael@apache.org]
> > >>>> > Sent: Thursday, June 16, 2005 04:49 AM
> > >>>> > To: Jetspeed Users List
> > >>>> > Subject: Re: Clearing render parameters?
> > >>>> >
> > >>>> >
> > >>>> > Frank Villarreal wrote:
> > >>>> > > <snip>
> > >>>> > >
> > >>>> > > If you have a Menu link that reads "Home" and represents the
> > >>>> > "default" page
> > >>>> > > for portal, is it not logical that the user should be taken
> > >>>> > "back" to what
> > >>>> > > they first "saw" when they logged-in to the portal instead of
> > >>>> > the "current
> > >>>> > > state" of that default page??? Reason being: the "current
> > >>>> > state" could be
> > >>>> > > several state changes deep into a "maximized" portlet that no
> > >>>> > > longer
> > >>>> > > resembles what the user first saw ... therefore they become
> > >>>> confused and
> > >>>> > > wonder what happened to the "home" page!
> > >>>> > >
> > >>>> > > It just seems to me that the spec is lacking in this regard.
> > >>>> > Unfortunately,
> > >>>> > > I can't wait around for the spec to change (if it ever does),
> > >>>> > so I need to
> > >>>> > > customize this ASAP in order to make my site intuitive for my
> > >>>> > > users.
> > >>>> > >
> > >>>> > > - Frank
> > >>>> > >
> > >>>> >
> > >>>> > First, what version of Jetspeed are you using ? There
> was a bug in
> > >>>> > the render parameters were handled in Jetspeed M2 that should be
> > >>>> > fixed in M3 (JS2-231). So first advice is to update the M3
> > or M4-dev.
> > >>>> >
> > >>>> > Second, if your portlets use URL parameters to keep their render
> > >>>> > state, as they
> > >>>> > should, simply using a default URL in the portal menu should get
> > >>>> > you where you
> > >>>> > want (ie http://myhost/myportal)
> > >>>> >
> > >>>> > Now, if your portlets also depend on session-bound parameters for
> > >>>> > your state,
> > >>>> > this is going to be trickier. AFAIK, J2 cannot access the
> > >>>> sessions of the
> > >>>> > portlets themselves since they are in a different webapp and the
> > >>>> > Servlet API
> > >>>> > nor the Portlet API allows us to do this, so you'll need to
> > >>>> > customize J2 itself
> > >>>> > to do it.
> > >>>> >
> > >>>> > Possible strategy:
> > >>>> > - Subclass the
> > >>>> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
> > >>>> > the doGet() to check for a CLEAR_SESSION request attribute. If
> > >>>> > this attribute
> > >>>> > is in the request, invalidate() the current session and create
> > >>>> > it anew (or
> > >>>> > manually clear all bound objects).
> > >>>> > (You'll need to patch
> > >>>> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
> > >>>> > to automatically
> > >>>> > deploy with your new servlet and possibly manually patch the
> > >>>> > web.xml of
> > >>>> > already deployed portlet apps to use your customized container
> > >>>> servlet)
> > >>>> >
> > >>>> > - Now, you simply need to set the CLEAR_SESSION request attribute
> > >>>> > by any mean
> > >>>> > (like a Portal level application or any portlet) to be able to
> > >>>> > automatically
> > >>>> > reset the sessions and thus the state of all your portlets.
> > >>>> >
> > >>>> > Let us know if this works for you and as always patches
> > are welcome
> > >>>> > ;)
> > >>>> >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> > >
> >
> >
> >
> >
> >
> >
> > ___________________________________________________________
> > 1GB gratis, Antivirus y Antispam
> > Correo Yahoo!, el mejor correo web del mundo
> > http://correo.yahoo.com.ar
> >
> >
> > ---------------------------------------------------------------------
> > 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: Clearing render parameters?
Posted by Frank Villarreal <f_...@tetco.com>.
+1 ... I too am only using the out-of-the-box menu rendering that happens in
the velocity templates ... Santiago, do your portlets still appear to be
using the "last" render parameters when you click directly on a page link?
I'm curious since you're already using build M3.
- Frank
> -----Original Message-----
> From: Santiago Urrizola [mailto:chily_listas@yahoo.com.ar]
> Sent: Tuesday, June 21, 2005 03:07 PM
> To: Jetspeed Users List
> Subject: Re: Clearing render parameters?
>
>
> > This may be another one.
> > There can be many reasons why you see previous state in your links:
> > - you may have encoded the menu URLs with the render parameters thus
> > keeping your state
>
> This is how my menus is painting, they not add nothing to the url
> <a href="$jetspeed.getAbsoluteUrl($node.url)?init=true"
> title="$node.getTitle($preferedLocale)">
> • $node.getShortTitle($preferedLocale)
> </a>
>
> > - there may be a bug in the cache manager
> I debug the struts bridges, and i see that not remove the last url of
> the portlet.
>
> > - the struts bridge may keep some state in session (I would need to
> > check).
> is posible, they keep the last url in the request, so when
> try to render
> the portlet, the render with the last url but i link the menu so its
> imposible this situation.
>
>
> >
> > I guess what you experience is #1. You can easily check if your menu
> > URLs encode the render parameters or not. Instead of using tour menu
> > links, simply type your "basic" URL in the browser and see if state
> > is as expected.
> >
> > --
> > Raphaël Luta - raphael@apache.org
> > Apache Portals - Enterprise Portal in Java
> > http://portals.apache.org/
> >
> > Santiago Urrizola wrote:
> >> Hi i use the M3 version and still happend this bug ?? its posible ??
> >>
> >> ----- Original Message ----- From: "Frank Villarreal"
> >> <f_...@tetco.com>
> >> To: "Jetspeed Users List" <je...@portals.apache.org>
> >> Sent: Tuesday, June 21, 2005 4:18 PM
> >> Subject: RE: Clearing render parameters?
> >>
> >>
> >>> Answered my own question. See bug JS2-231. This has been fixed in
> >>> Jetspeed2 M3 I believe. Now for the painful task of updating
> my site to
> >>> this new version. Yikes.
> >>>
> >>> - Frank
> >>>
> >>>> -----Original Message-----
> >>>> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
> >>>> Sent: Tuesday, June 21, 2005 02:13 PM
> >>>> To: Jetspeed Users List
> >>>> Subject: RE: Clearing render parameters?
> >>>>
> >>>>
> >>>> Raphael,
> >>>>
> >>>> first off, thanks for the response. Second, are you saying that the
> >>>> "correct" behavior in Jetspeed2 (which is what I'm using ...
> M2 build)
> >>>> should clear the render parameters if I where to for
> instance, navigate
> >>>> to
> >>>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
> >>>> build
> >>>> ... the previous state (meaning the previous render parameters)
> >>>> are somehow
> >>>> persisted when I try that. Was that a bug or was that by
> design? I'm
> >>>> now
> >>>> confused.
> >>>>
> >>>> - Frank
> >>>>
> >>>> > -----Original Message-----
> >>>> > From: Raphaël Luta [mailto:raphael@apache.org]
> >>>> > Sent: Thursday, June 16, 2005 04:49 AM
> >>>> > To: Jetspeed Users List
> >>>> > Subject: Re: Clearing render parameters?
> >>>> >
> >>>> >
> >>>> > Frank Villarreal wrote:
> >>>> > > <snip>
> >>>> > >
> >>>> > > If you have a Menu link that reads "Home" and represents the
> >>>> > "default" page
> >>>> > > for portal, is it not logical that the user should be taken
> >>>> > "back" to what
> >>>> > > they first "saw" when they logged-in to the portal instead of
> >>>> > the "current
> >>>> > > state" of that default page??? Reason being: the "current
> >>>> > state" could be
> >>>> > > several state changes deep into a "maximized" portlet that no
> >>>> > > longer
> >>>> > > resembles what the user first saw ... therefore they become
> >>>> confused and
> >>>> > > wonder what happened to the "home" page!
> >>>> > >
> >>>> > > It just seems to me that the spec is lacking in this regard.
> >>>> > Unfortunately,
> >>>> > > I can't wait around for the spec to change (if it ever does),
> >>>> > so I need to
> >>>> > > customize this ASAP in order to make my site intuitive for my
> >>>> > > users.
> >>>> > >
> >>>> > > - Frank
> >>>> > >
> >>>> >
> >>>> > First, what version of Jetspeed are you using ? There was a bug in
> >>>> > the render parameters were handled in Jetspeed M2 that should be
> >>>> > fixed in M3 (JS2-231). So first advice is to update the M3
> or M4-dev.
> >>>> >
> >>>> > Second, if your portlets use URL parameters to keep their render
> >>>> > state, as they
> >>>> > should, simply using a default URL in the portal menu should get
> >>>> > you where you
> >>>> > want (ie http://myhost/myportal)
> >>>> >
> >>>> > Now, if your portlets also depend on session-bound parameters for
> >>>> > your state,
> >>>> > this is going to be trickier. AFAIK, J2 cannot access the
> >>>> sessions of the
> >>>> > portlets themselves since they are in a different webapp and the
> >>>> > Servlet API
> >>>> > nor the Portlet API allows us to do this, so you'll need to
> >>>> > customize J2 itself
> >>>> > to do it.
> >>>> >
> >>>> > Possible strategy:
> >>>> > - Subclass the
> >>>> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
> >>>> > the doGet() to check for a CLEAR_SESSION request attribute. If
> >>>> > this attribute
> >>>> > is in the request, invalidate() the current session and create
> >>>> > it anew (or
> >>>> > manually clear all bound objects).
> >>>> > (You'll need to patch
> >>>> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
> >>>> > to automatically
> >>>> > deploy with your new servlet and possibly manually patch the
> >>>> > web.xml of
> >>>> > already deployed portlet apps to use your customized container
> >>>> servlet)
> >>>> >
> >>>> > - Now, you simply need to set the CLEAR_SESSION request attribute
> >>>> > by any mean
> >>>> > (like a Portal level application or any portlet) to be able to
> >>>> > automatically
> >>>> > reset the sessions and thus the state of all your portlets.
> >>>> >
> >>>> > Let us know if this works for you and as always patches
> are welcome
> >>>> > ;)
> >>>> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
>
>
>
>
>
>
> ___________________________________________________________
> 1GB gratis, Antivirus y Antispam
> Correo Yahoo!, el mejor correo web del mundo
> http://correo.yahoo.com.ar
>
>
> ---------------------------------------------------------------------
> 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: Clearing render parameters?
Posted by Santiago Urrizola <ch...@yahoo.com.ar>.
> This may be another one.
> There can be many reasons why you see previous state in your links:
> - you may have encoded the menu URLs with the render parameters thus
> keeping your state
This is how my menus is painting, they not add nothing to the url
<a href="$jetspeed.getAbsoluteUrl($node.url)?init=true"
title="$node.getTitle($preferedLocale)">
• $node.getShortTitle($preferedLocale)
</a>
> - there may be a bug in the cache manager
I debug the struts bridges, and i see that not remove the last url of
the portlet.
> - the struts bridge may keep some state in session (I would need to
> check).
is posible, they keep the last url in the request, so when try to render
the portlet, the render with the last url but i link the menu so its
imposible this situation.
>
> I guess what you experience is #1. You can easily check if your menu
> URLs encode the render parameters or not. Instead of using tour menu
> links, simply type your "basic" URL in the browser and see if state
> is as expected.
>
> --
> Raphaël Luta - raphael@apache.org
> Apache Portals - Enterprise Portal in Java
> http://portals.apache.org/
>
> Santiago Urrizola wrote:
>> Hi i use the M3 version and still happend this bug ?? its posible ??
>>
>> ----- Original Message ----- From: "Frank Villarreal"
>> <f_...@tetco.com>
>> To: "Jetspeed Users List" <je...@portals.apache.org>
>> Sent: Tuesday, June 21, 2005 4:18 PM
>> Subject: RE: Clearing render parameters?
>>
>>
>>> Answered my own question. See bug JS2-231. This has been fixed in
>>> Jetspeed2 M3 I believe. Now for the painful task of updating my site to
>>> this new version. Yikes.
>>>
>>> - Frank
>>>
>>>> -----Original Message-----
>>>> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
>>>> Sent: Tuesday, June 21, 2005 02:13 PM
>>>> To: Jetspeed Users List
>>>> Subject: RE: Clearing render parameters?
>>>>
>>>>
>>>> Raphael,
>>>>
>>>> first off, thanks for the response. Second, are you saying that the
>>>> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
>>>> should clear the render parameters if I where to for instance, navigate
>>>> to
>>>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
>>>> build
>>>> ... the previous state (meaning the previous render parameters)
>>>> are somehow
>>>> persisted when I try that. Was that a bug or was that by design? I'm
>>>> now
>>>> confused.
>>>>
>>>> - Frank
>>>>
>>>> > -----Original Message-----
>>>> > From: Raphaël Luta [mailto:raphael@apache.org]
>>>> > Sent: Thursday, June 16, 2005 04:49 AM
>>>> > To: Jetspeed Users List
>>>> > Subject: Re: Clearing render parameters?
>>>> >
>>>> >
>>>> > Frank Villarreal wrote:
>>>> > > <snip>
>>>> > >
>>>> > > If you have a Menu link that reads "Home" and represents the
>>>> > "default" page
>>>> > > for portal, is it not logical that the user should be taken
>>>> > "back" to what
>>>> > > they first "saw" when they logged-in to the portal instead of
>>>> > the "current
>>>> > > state" of that default page??? Reason being: the "current
>>>> > state" could be
>>>> > > several state changes deep into a "maximized" portlet that no
>>>> > > longer
>>>> > > resembles what the user first saw ... therefore they become
>>>> confused and
>>>> > > wonder what happened to the "home" page!
>>>> > >
>>>> > > It just seems to me that the spec is lacking in this regard.
>>>> > Unfortunately,
>>>> > > I can't wait around for the spec to change (if it ever does),
>>>> > so I need to
>>>> > > customize this ASAP in order to make my site intuitive for my
>>>> > > users.
>>>> > >
>>>> > > - Frank
>>>> > >
>>>> >
>>>> > First, what version of Jetspeed are you using ? There was a bug in
>>>> > the render parameters were handled in Jetspeed M2 that should be
>>>> > fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>>>> >
>>>> > Second, if your portlets use URL parameters to keep their render
>>>> > state, as they
>>>> > should, simply using a default URL in the portal menu should get
>>>> > you where you
>>>> > want (ie http://myhost/myportal)
>>>> >
>>>> > Now, if your portlets also depend on session-bound parameters for
>>>> > your state,
>>>> > this is going to be trickier. AFAIK, J2 cannot access the
>>>> sessions of the
>>>> > portlets themselves since they are in a different webapp and the
>>>> > Servlet API
>>>> > nor the Portlet API allows us to do this, so you'll need to
>>>> > customize J2 itself
>>>> > to do it.
>>>> >
>>>> > Possible strategy:
>>>> > - Subclass the
>>>> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>>>> > the doGet() to check for a CLEAR_SESSION request attribute. If
>>>> > this attribute
>>>> > is in the request, invalidate() the current session and create
>>>> > it anew (or
>>>> > manually clear all bound objects).
>>>> > (You'll need to patch
>>>> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>>>> > to automatically
>>>> > deploy with your new servlet and possibly manually patch the
>>>> > web.xml of
>>>> > already deployed portlet apps to use your customized container
>>>> servlet)
>>>> >
>>>> > - Now, you simply need to set the CLEAR_SESSION request attribute
>>>> > by any mean
>>>> > (like a Portal level application or any portlet) to be able to
>>>> > automatically
>>>> > reset the sessions and thus the state of all your portlets.
>>>> >
>>>> > Let us know if this works for you and as always patches are welcome
>>>> > ;)
>>>> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Clearing render parameters?
Posted by Santiago Urrizola <ch...@yahoo.com.ar>.
hi, i see this fragment of code in the StrutsPorlet class of the
struts bridge M3 Version
String path = null;
String pageURL = request.getParameter(StrutsPortletURL.PAGE);
if (pageURL == null)
I think there ir the problem, becasuse when i link a psml (containing an
struts porlet) from the menu, the variable pageURL still have data, form a
previous call to this portlet... making that the porlet render the same
previous context when they must have render the content for de default page,
(ViewPage, defined in the portlet.xml)
----- Original Message -----
From: "Raphaël Luta" <ra...@apache.org>
To: "Jetspeed Users List" <je...@portals.apache.org>
Sent: Tuesday, June 21, 2005 5:00 PM
Subject: Re: Clearing render parameters?
> This may be another one.
> There can be many reasons why you see previous state in your links:
> - you may have encoded the menu URLs with the render parameters thus
> keeping your state
> - there may be a bug in the cache manager
> - the struts bridge may keep some state in session (I would need to
> check).
>
> I guess what you experience is #1. You can easily check if your menu
> URLs encode the render parameters or not. Instead of using tour menu
> links, simply type your "basic" URL in the browser and see if state
> is as expected.
>
> --
> Raphaël Luta - raphael@apache.org
> Apache Portals - Enterprise Portal in Java
> http://portals.apache.org/
>
> Santiago Urrizola wrote:
>> Hi i use the M3 version and still happend this bug ?? its posible ??
>>
>> ----- Original Message ----- From: "Frank Villarreal"
>> <f_...@tetco.com>
>> To: "Jetspeed Users List" <je...@portals.apache.org>
>> Sent: Tuesday, June 21, 2005 4:18 PM
>> Subject: RE: Clearing render parameters?
>>
>>
>>> Answered my own question. See bug JS2-231. This has been fixed in
>>> Jetspeed2 M3 I believe. Now for the painful task of updating my site to
>>> this new version. Yikes.
>>>
>>> - Frank
>>>
>>>> -----Original Message-----
>>>> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
>>>> Sent: Tuesday, June 21, 2005 02:13 PM
>>>> To: Jetspeed Users List
>>>> Subject: RE: Clearing render parameters?
>>>>
>>>>
>>>> Raphael,
>>>>
>>>> first off, thanks for the response. Second, are you saying that the
>>>> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
>>>> should clear the render parameters if I where to for instance, navigate
>>>> to
>>>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
>>>> build
>>>> ... the previous state (meaning the previous render parameters)
>>>> are somehow
>>>> persisted when I try that. Was that a bug or was that by design? I'm
>>>> now
>>>> confused.
>>>>
>>>> - Frank
>>>>
>>>> > -----Original Message-----
>>>> > From: Raphaël Luta [mailto:raphael@apache.org]
>>>> > Sent: Thursday, June 16, 2005 04:49 AM
>>>> > To: Jetspeed Users List
>>>> > Subject: Re: Clearing render parameters?
>>>> >
>>>> >
>>>> > Frank Villarreal wrote:
>>>> > > <snip>
>>>> > >
>>>> > > If you have a Menu link that reads "Home" and represents the
>>>> > "default" page
>>>> > > for portal, is it not logical that the user should be taken
>>>> > "back" to what
>>>> > > they first "saw" when they logged-in to the portal instead of
>>>> > the "current
>>>> > > state" of that default page??? Reason being: the "current
>>>> > state" could be
>>>> > > several state changes deep into a "maximized" portlet that no
>>>> > > longer
>>>> > > resembles what the user first saw ... therefore they become
>>>> confused and
>>>> > > wonder what happened to the "home" page!
>>>> > >
>>>> > > It just seems to me that the spec is lacking in this regard.
>>>> > Unfortunately,
>>>> > > I can't wait around for the spec to change (if it ever does),
>>>> > so I need to
>>>> > > customize this ASAP in order to make my site intuitive for my
>>>> > > users.
>>>> > >
>>>> > > - Frank
>>>> > >
>>>> >
>>>> > First, what version of Jetspeed are you using ? There was a bug in
>>>> > the render parameters were handled in Jetspeed M2 that should be
>>>> > fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>>>> >
>>>> > Second, if your portlets use URL parameters to keep their render
>>>> > state, as they
>>>> > should, simply using a default URL in the portal menu should get
>>>> > you where you
>>>> > want (ie http://myhost/myportal)
>>>> >
>>>> > Now, if your portlets also depend on session-bound parameters for
>>>> > your state,
>>>> > this is going to be trickier. AFAIK, J2 cannot access the
>>>> sessions of the
>>>> > portlets themselves since they are in a different webapp and the
>>>> > Servlet API
>>>> > nor the Portlet API allows us to do this, so you'll need to
>>>> > customize J2 itself
>>>> > to do it.
>>>> >
>>>> > Possible strategy:
>>>> > - Subclass the
>>>> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>>>> > the doGet() to check for a CLEAR_SESSION request attribute. If
>>>> > this attribute
>>>> > is in the request, invalidate() the current session and create
>>>> > it anew (or
>>>> > manually clear all bound objects).
>>>> > (You'll need to patch
>>>> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>>>> > to automatically
>>>> > deploy with your new servlet and possibly manually patch the
>>>> > web.xml of
>>>> > already deployed portlet apps to use your customized container
>>>> servlet)
>>>> >
>>>> > - Now, you simply need to set the CLEAR_SESSION request attribute
>>>> > by any mean
>>>> > (like a Portal level application or any portlet) to be able to
>>>> > automatically
>>>> > reset the sessions and thus the state of all your portlets.
>>>> >
>>>> > Let us know if this works for you and as always patches are welcome
>>>> > ;)
>>>> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
___________________________________
A tu celular ¿no le falta algo?
Usá Yahoo! Messenger y Correo Yahoo! en tu teléfono celular.
Más información en http://movil.yahoo.com.ar
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Clearing render parameters?
Posted by Raphaël Luta <ra...@apache.org>.
This may be another one.
There can be many reasons why you see previous state in your links:
- you may have encoded the menu URLs with the render parameters thus
keeping your state
- there may be a bug in the cache manager
- the struts bridge may keep some state in session (I would need to check).
I guess what you experience is #1. You can easily check if your menu
URLs encode the render parameters or not. Instead of using tour menu
links, simply type your "basic" URL in the browser and see if state
is as expected.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Santiago Urrizola wrote:
> Hi i use the M3 version and still happend this bug ?? its posible ??
>
> ----- Original Message ----- From: "Frank Villarreal"
> <f_...@tetco.com>
> To: "Jetspeed Users List" <je...@portals.apache.org>
> Sent: Tuesday, June 21, 2005 4:18 PM
> Subject: RE: Clearing render parameters?
>
>
>> Answered my own question. See bug JS2-231. This has been fixed in
>> Jetspeed2 M3 I believe. Now for the painful task of updating my site to
>> this new version. Yikes.
>>
>> - Frank
>>
>>> -----Original Message-----
>>> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
>>> Sent: Tuesday, June 21, 2005 02:13 PM
>>> To: Jetspeed Users List
>>> Subject: RE: Clearing render parameters?
>>>
>>>
>>> Raphael,
>>>
>>> first off, thanks for the response. Second, are you saying that the
>>> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
>>> should clear the render parameters if I where to for instance,
>>> navigate to
>>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
>>> build
>>> ... the previous state (meaning the previous render parameters)
>>> are somehow
>>> persisted when I try that. Was that a bug or was that by design?
>>> I'm now
>>> confused.
>>>
>>> - Frank
>>>
>>> > -----Original Message-----
>>> > From: Raphaël Luta [mailto:raphael@apache.org]
>>> > Sent: Thursday, June 16, 2005 04:49 AM
>>> > To: Jetspeed Users List
>>> > Subject: Re: Clearing render parameters?
>>> >
>>> >
>>> > Frank Villarreal wrote:
>>> > > <snip>
>>> > >
>>> > > If you have a Menu link that reads "Home" and represents the
>>> > "default" page
>>> > > for portal, is it not logical that the user should be taken
>>> > "back" to what
>>> > > they first "saw" when they logged-in to the portal instead of
>>> > the "current
>>> > > state" of that default page??? Reason being: the "current
>>> > state" could be
>>> > > several state changes deep into a "maximized" portlet that no longer
>>> > > resembles what the user first saw ... therefore they become
>>> confused and
>>> > > wonder what happened to the "home" page!
>>> > >
>>> > > It just seems to me that the spec is lacking in this regard.
>>> > Unfortunately,
>>> > > I can't wait around for the spec to change (if it ever does),
>>> > so I need to
>>> > > customize this ASAP in order to make my site intuitive for my users.
>>> > >
>>> > > - Frank
>>> > >
>>> >
>>> > First, what version of Jetspeed are you using ? There was a bug in
>>> > the render parameters were handled in Jetspeed M2 that should be
>>> > fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>>> >
>>> > Second, if your portlets use URL parameters to keep their render
>>> > state, as they
>>> > should, simply using a default URL in the portal menu should get
>>> > you where you
>>> > want (ie http://myhost/myportal)
>>> >
>>> > Now, if your portlets also depend on session-bound parameters for
>>> > your state,
>>> > this is going to be trickier. AFAIK, J2 cannot access the
>>> sessions of the
>>> > portlets themselves since they are in a different webapp and the
>>> > Servlet API
>>> > nor the Portlet API allows us to do this, so you'll need to
>>> > customize J2 itself
>>> > to do it.
>>> >
>>> > Possible strategy:
>>> > - Subclass the
>>> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>>> > the doGet() to check for a CLEAR_SESSION request attribute. If
>>> > this attribute
>>> > is in the request, invalidate() the current session and create
>>> > it anew (or
>>> > manually clear all bound objects).
>>> > (You'll need to patch
>>> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>>> > to automatically
>>> > deploy with your new servlet and possibly manually patch the
>>> > web.xml of
>>> > already deployed portlet apps to use your customized container
>>> servlet)
>>> >
>>> > - Now, you simply need to set the CLEAR_SESSION request attribute
>>> > by any mean
>>> > (like a Portal level application or any portlet) to be able to
>>> > automatically
>>> > reset the sessions and thus the state of all your portlets.
>>> >
>>> > Let us know if this works for you and as always patches are welcome ;)
>>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Clearing render parameters?
Posted by Santiago Urrizola <ch...@yahoo.com.ar>.
Hi i use the M3 version and still happend this bug ?? its posible ??
----- Original Message -----
From: "Frank Villarreal" <f_...@tetco.com>
To: "Jetspeed Users List" <je...@portals.apache.org>
Sent: Tuesday, June 21, 2005 4:18 PM
Subject: RE: Clearing render parameters?
> Answered my own question. See bug JS2-231. This has been fixed in
> Jetspeed2 M3 I believe. Now for the painful task of updating my site to
> this new version. Yikes.
>
> - Frank
>
>> -----Original Message-----
>> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
>> Sent: Tuesday, June 21, 2005 02:13 PM
>> To: Jetspeed Users List
>> Subject: RE: Clearing render parameters?
>>
>>
>> Raphael,
>>
>> first off, thanks for the response. Second, are you saying that the
>> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
>> should clear the render parameters if I where to for instance, navigate
>> to
>> "http://myhost/jetspeed/portal"??? This does not happen with the M2
>> build
>> ... the previous state (meaning the previous render parameters)
>> are somehow
>> persisted when I try that. Was that a bug or was that by design? I'm
>> now
>> confused.
>>
>> - Frank
>>
>> > -----Original Message-----
>> > From: Raphaël Luta [mailto:raphael@apache.org]
>> > Sent: Thursday, June 16, 2005 04:49 AM
>> > To: Jetspeed Users List
>> > Subject: Re: Clearing render parameters?
>> >
>> >
>> > Frank Villarreal wrote:
>> > > <snip>
>> > >
>> > > If you have a Menu link that reads "Home" and represents the
>> > "default" page
>> > > for portal, is it not logical that the user should be taken
>> > "back" to what
>> > > they first "saw" when they logged-in to the portal instead of
>> > the "current
>> > > state" of that default page??? Reason being: the "current
>> > state" could be
>> > > several state changes deep into a "maximized" portlet that no longer
>> > > resembles what the user first saw ... therefore they become
>> confused and
>> > > wonder what happened to the "home" page!
>> > >
>> > > It just seems to me that the spec is lacking in this regard.
>> > Unfortunately,
>> > > I can't wait around for the spec to change (if it ever does),
>> > so I need to
>> > > customize this ASAP in order to make my site intuitive for my users.
>> > >
>> > > - Frank
>> > >
>> >
>> > First, what version of Jetspeed are you using ? There was a bug in
>> > the render parameters were handled in Jetspeed M2 that should be
>> > fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>> >
>> > Second, if your portlets use URL parameters to keep their render
>> > state, as they
>> > should, simply using a default URL in the portal menu should get
>> > you where you
>> > want (ie http://myhost/myportal)
>> >
>> > Now, if your portlets also depend on session-bound parameters for
>> > your state,
>> > this is going to be trickier. AFAIK, J2 cannot access the
>> sessions of the
>> > portlets themselves since they are in a different webapp and the
>> > Servlet API
>> > nor the Portlet API allows us to do this, so you'll need to
>> > customize J2 itself
>> > to do it.
>> >
>> > Possible strategy:
>> > - Subclass the
>> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
>> > the doGet() to check for a CLEAR_SESSION request attribute. If
>> > this attribute
>> > is in the request, invalidate() the current session and create
>> > it anew (or
>> > manually clear all bound objects).
>> > (You'll need to patch
>> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
>> > to automatically
>> > deploy with your new servlet and possibly manually patch the
>> > web.xml of
>> > already deployed portlet apps to use your customized container servlet)
>> >
>> > - Now, you simply need to set the CLEAR_SESSION request attribute
>> > by any mean
>> > (like a Portal level application or any portlet) to be able to
>> > automatically
>> > reset the sessions and thus the state of all your portlets.
>> >
>> > Let us know if this works for you and as always patches are welcome ;)
>> >
>> > --
>> > Raphaël Luta - raphael@apache.org
>> > Apache Portals - Enterprise Portal in Java
>> > http://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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
___________________________________
A tu celular ¿no le falta algo?
Usá Yahoo! Messenger y Correo Yahoo! en tu teléfono celular.
Más información en http://movil.yahoo.com.ar
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: Clearing render parameters?
Posted by Frank Villarreal <f_...@tetco.com>.
Answered my own question. See bug JS2-231. This has been fixed in
Jetspeed2 M3 I believe. Now for the painful task of updating my site to
this new version. Yikes.
- Frank
> -----Original Message-----
> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
> Sent: Tuesday, June 21, 2005 02:13 PM
> To: Jetspeed Users List
> Subject: RE: Clearing render parameters?
>
>
> Raphael,
>
> first off, thanks for the response. Second, are you saying that the
> "correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
> should clear the render parameters if I where to for instance, navigate to
> "http://myhost/jetspeed/portal"??? This does not happen with the M2 build
> ... the previous state (meaning the previous render parameters)
> are somehow
> persisted when I try that. Was that a bug or was that by design? I'm now
> confused.
>
> - Frank
>
> > -----Original Message-----
> > From: Raphaël Luta [mailto:raphael@apache.org]
> > Sent: Thursday, June 16, 2005 04:49 AM
> > To: Jetspeed Users List
> > Subject: Re: Clearing render parameters?
> >
> >
> > Frank Villarreal wrote:
> > > <snip>
> > >
> > > If you have a Menu link that reads "Home" and represents the
> > "default" page
> > > for portal, is it not logical that the user should be taken
> > "back" to what
> > > they first "saw" when they logged-in to the portal instead of
> > the "current
> > > state" of that default page??? Reason being: the "current
> > state" could be
> > > several state changes deep into a "maximized" portlet that no longer
> > > resembles what the user first saw ... therefore they become
> confused and
> > > wonder what happened to the "home" page!
> > >
> > > It just seems to me that the spec is lacking in this regard.
> > Unfortunately,
> > > I can't wait around for the spec to change (if it ever does),
> > so I need to
> > > customize this ASAP in order to make my site intuitive for my users.
> > >
> > > - Frank
> > >
> >
> > First, what version of Jetspeed are you using ? There was a bug in
> > the render parameters were handled in Jetspeed M2 that should be
> > fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
> >
> > Second, if your portlets use URL parameters to keep their render
> > state, as they
> > should, simply using a default URL in the portal menu should get
> > you where you
> > want (ie http://myhost/myportal)
> >
> > Now, if your portlets also depend on session-bound parameters for
> > your state,
> > this is going to be trickier. AFAIK, J2 cannot access the
> sessions of the
> > portlets themselves since they are in a different webapp and the
> > Servlet API
> > nor the Portlet API allows us to do this, so you'll need to
> > customize J2 itself
> > to do it.
> >
> > Possible strategy:
> > - Subclass the
> > org.apache.jetspeed.commons.JetspeedContainerServlet and modify
> > the doGet() to check for a CLEAR_SESSION request attribute. If
> > this attribute
> > is in the request, invalidate() the current session and create
> > it anew (or
> > manually clear all bound objects).
> > (You'll need to patch
> > org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
> > to automatically
> > deploy with your new servlet and possibly manually patch the
> > web.xml of
> > already deployed portlet apps to use your customized container servlet)
> >
> > - Now, you simply need to set the CLEAR_SESSION request attribute
> > by any mean
> > (like a Portal level application or any portlet) to be able to
> > automatically
> > reset the sessions and thus the state of all your portlets.
> >
> > Let us know if this works for you and as always patches are welcome ;)
> >
> > --
> > Raphaël Luta - raphael@apache.org
> > Apache Portals - Enterprise Portal in Java
> > http://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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: Clearing render parameters?
Posted by Frank Villarreal <f_...@tetco.com>.
Raphael,
first off, thanks for the response. Second, are you saying that the
"correct" behavior in Jetspeed2 (which is what I'm using ... M2 build)
should clear the render parameters if I where to for instance, navigate to
"http://myhost/jetspeed/portal"??? This does not happen with the M2 build
... the previous state (meaning the previous render parameters) are somehow
persisted when I try that. Was that a bug or was that by design? I'm now
confused.
- Frank
> -----Original Message-----
> From: Raphaël Luta [mailto:raphael@apache.org]
> Sent: Thursday, June 16, 2005 04:49 AM
> To: Jetspeed Users List
> Subject: Re: Clearing render parameters?
>
>
> Frank Villarreal wrote:
> > <snip>
> >
> > If you have a Menu link that reads "Home" and represents the
> "default" page
> > for portal, is it not logical that the user should be taken
> "back" to what
> > they first "saw" when they logged-in to the portal instead of
> the "current
> > state" of that default page??? Reason being: the "current
> state" could be
> > several state changes deep into a "maximized" portlet that no longer
> > resembles what the user first saw ... therefore they become confused and
> > wonder what happened to the "home" page!
> >
> > It just seems to me that the spec is lacking in this regard.
> Unfortunately,
> > I can't wait around for the spec to change (if it ever does),
> so I need to
> > customize this ASAP in order to make my site intuitive for my users.
> >
> > - Frank
> >
>
> First, what version of Jetspeed are you using ? There was a bug in
> the render parameters were handled in Jetspeed M2 that should be
> fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
>
> Second, if your portlets use URL parameters to keep their render
> state, as they
> should, simply using a default URL in the portal menu should get
> you where you
> want (ie http://myhost/myportal)
>
> Now, if your portlets also depend on session-bound parameters for
> your state,
> this is going to be trickier. AFAIK, J2 cannot access the sessions of the
> portlets themselves since they are in a different webapp and the
> Servlet API
> nor the Portlet API allows us to do this, so you'll need to
> customize J2 itself
> to do it.
>
> Possible strategy:
> - Subclass the
> org.apache.jetspeed.commons.JetspeedContainerServlet and modify
> the doGet() to check for a CLEAR_SESSION request attribute. If
> this attribute
> is in the request, invalidate() the current session and create
> it anew (or
> manually clear all bound objects).
> (You'll need to patch
> org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter
> to automatically
> deploy with your new servlet and possibly manually patch the
> web.xml of
> already deployed portlet apps to use your customized container servlet)
>
> - Now, you simply need to set the CLEAR_SESSION request attribute
> by any mean
> (like a Portal level application or any portlet) to be able to
> automatically
> reset the sessions and thus the state of all your portlets.
>
> Let us know if this works for you and as always patches are welcome ;)
>
> --
> Raphaël Luta - raphael@apache.org
> Apache Portals - Enterprise Portal in Java
> http://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: Clearing render parameters?
Posted by Raphaël Luta <ra...@apache.org>.
Frank Villarreal wrote:
> <snip>
>
> If you have a Menu link that reads "Home" and represents the "default" page
> for portal, is it not logical that the user should be taken "back" to what
> they first "saw" when they logged-in to the portal instead of the "current
> state" of that default page??? Reason being: the "current state" could be
> several state changes deep into a "maximized" portlet that no longer
> resembles what the user first saw ... therefore they become confused and
> wonder what happened to the "home" page!
>
> It just seems to me that the spec is lacking in this regard. Unfortunately,
> I can't wait around for the spec to change (if it ever does), so I need to
> customize this ASAP in order to make my site intuitive for my users.
>
> - Frank
>
First, what version of Jetspeed are you using ? There was a bug in
the render parameters were handled in Jetspeed M2 that should be
fixed in M3 (JS2-231). So first advice is to update the M3 or M4-dev.
Second, if your portlets use URL parameters to keep their render state, as they
should, simply using a default URL in the portal menu should get you where you
want (ie http://myhost/myportal)
Now, if your portlets also depend on session-bound parameters for your state,
this is going to be trickier. AFAIK, J2 cannot access the sessions of the
portlets themselves since they are in a different webapp and the Servlet API
nor the Portlet API allows us to do this, so you'll need to customize J2 itself
to do it.
Possible strategy:
- Subclass the org.apache.jetspeed.commons.JetspeedContainerServlet and modify
the doGet() to check for a CLEAR_SESSION request attribute. If this attribute
is in the request, invalidate() the current session and create it anew (or
manually clear all bound objects).
(You'll need to patch
org.apache.jetspeed.tools.deploy.JetspeedWebApplicationRewriter to automatically
deploy with your new servlet and possibly manually patch the web.xml of
already deployed portlet apps to use your customized container servlet)
- Now, you simply need to set the CLEAR_SESSION request attribute by any mean
(like a Portal level application or any portlet) to be able to automatically
reset the sessions and thus the state of all your portlets.
Let us know if this works for you and as always patches are welcome ;)
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://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: Clearing render parameters?
Posted by Edmund Urbani <em...@liland.org>.
Frank Villarreal wrote:
>Thanks for the response Edmund.
>
>I do realize what I'm trying to do most likely "breaks" the spec, but I need
>to do it. All of my portlets are "mini-applications" each and of
>themselves. Each portlet has multiple pages and states ... however, each
>portlet "starts" at a default state ... on the first rendering with no
>render parameters set. As users, "progress" through the site ... they click
>around and change the state of portlets. In order for the menuing system to
>be make any sense ... when a user click a "page link" outside of a portlet
>... then that page should "clear" the previously set render parameters for
>that particular user's session on that page.
>
>Here's an example ...
>
>If you have a Menu link that reads "Home" and represents the "default" page
>for portal, is it not logical that the user should be taken "back" to what
>they first "saw" when they logged-in to the portal instead of the "current
>state" of that default page??? Reason being: the "current state" could be
>several state changes deep into a "maximized" portlet that no longer
>resembles what the user first saw ... therefore they become confused and
>wonder what happened to the "home" page!
>
>It just seems to me that the spec is lacking in this regard. Unfortunately,
>I can't wait around for the spec to change (if it ever does), so I need to
>customize this ASAP in order to make my site intuitive for my users.
>
>- Frank
>
>
If i understand you right, then that "Menu link" you refering to,
is not part of any portlet, but rather a part of the portal's menu.
there is not really any "standard" way to do this, because the
portlet simply never receives any notification, when a portal page
is viewed, where it is not included. the only way to do this would be
to have portlets on ALL the other possible pages that send
notifications (using eg. portlet application context or some
singleton class) to the portlets on the "home" page.
but since that's probably not the way you would want to solve this
problem (i know i wouldn't, unless i had complete control over
all the portlets in the portal), it looks like you'll have to dig into J2
internal APIs and services. i can't help you there. hopefully somebody
else on this list can...
Edmund
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: Clearing render parameters?
Posted by Frank Villarreal <f_...@tetco.com>.
Thanks for the response Edmund.
I do realize what I'm trying to do most likely "breaks" the spec, but I need
to do it. All of my portlets are "mini-applications" each and of
themselves. Each portlet has multiple pages and states ... however, each
portlet "starts" at a default state ... on the first rendering with no
render parameters set. As users, "progress" through the site ... they click
around and change the state of portlets. In order for the menuing system to
be make any sense ... when a user click a "page link" outside of a portlet
... then that page should "clear" the previously set render parameters for
that particular user's session on that page.
Here's an example ...
If you have a Menu link that reads "Home" and represents the "default" page
for portal, is it not logical that the user should be taken "back" to what
they first "saw" when they logged-in to the portal instead of the "current
state" of that default page??? Reason being: the "current state" could be
several state changes deep into a "maximized" portlet that no longer
resembles what the user first saw ... therefore they become confused and
wonder what happened to the "home" page!
It just seems to me that the spec is lacking in this regard. Unfortunately,
I can't wait around for the spec to change (if it ever does), so I need to
customize this ASAP in order to make my site intuitive for my users.
- Frank
> -----Original Message-----
> From: Edmund Urbani [mailto:emu@liland.org]
> Sent: Wednesday, June 15, 2005 09:53 AM
> To: Jetspeed Users List
> Subject: Re: Clearing render parameters?
>
>
> Frank Villarreal wrote:
>
> >To J2 Devs:
> >
> >Can any one tell me where I can "reset" the render parameters
> for a specific
> >page when a user clicks a "non-portlet" specific menu hyperlink?
> What I'm
> >trying to accomplish is to make a portal session "clear" render
> parameters
> >for a requested page when a user clicks a page-link.
> >
> >
> >- Frank
> >
> >
> usually that's what action parameters are for. they are only sent
> to the portlet once with an action request.
>
> generally requests that change the portlet's state should be
> implemented as action requests. getting notifications for links
> clicked "outside" the portlet (i'm not sure whether i understand you
> right, but that's what you want, right?) can be hard, ugly or even
> impossible.
>
> could you give some more info on what you are actually trying to do?
>
> Edmund
>
> ---------------------------------------------------------------------
> 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: Clearing render parameters?
Posted by Edmund Urbani <em...@liland.org>.
Frank Villarreal wrote:
>To J2 Devs:
>
>Can any one tell me where I can "reset" the render parameters for a specific
>page when a user clicks a "non-portlet" specific menu hyperlink? What I'm
>trying to accomplish is to make a portal session "clear" render parameters
>for a requested page when a user clicks a page-link.
>
>
>- Frank
>
>
usually that's what action parameters are for. they are only sent
to the portlet once with an action request.
generally requests that change the portlet's state should be
implemented as action requests. getting notifications for links
clicked "outside" the portlet (i'm not sure whether i understand you
right, but that's what you want, right?) can be hard, ugly or even
impossible.
could you give some more info on what you are actually trying to do?
Edmund
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Clearing render parameters?
Posted by Frank Villarreal <f_...@tetco.com>.
To J2 Devs:
Can any one tell me where I can "reset" the render parameters for a specific
page when a user clicks a "non-portlet" specific menu hyperlink? What I'm
trying to accomplish is to make a portal session "clear" render parameters
for a requested page when a user clicks a page-link.
- Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: how do i get the User-Agent info?
Posted by Edmund Urbani <em...@liland.org>.
Benjamin DAHON wrote:
>You should use :
>portletRequest.getClient().getUserAgent().
>
>
>
i think that's the way you do it with the jetspeed 1.x portlet API. the
PortletRequest class of Sun's JSR-168 Portlet API does not have
getClient() or any similar method.
Edmund
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: how do i get the User-Agent info?
Posted by Benjamin DAHON <be...@gmail.com>.
You should use :
portletRequest.getClient().getUserAgent().
2005/6/14, David Pankros <dp...@miragy.com>:
> > if (req instanceof HttpServletRequestWrapper) {
> > HttpServletRequestWrapper
> > reqWrapper=(HttpServletRequestWrapper)req;
> > ServletRequest servletReq=reqWrapper.getRequest();
> > if (servletReq instanceof HttpServletRequest) {
> > HttpServletRequest
> > httpServletReq=(HttpServletRequest)servletReq;
> > String userAgent=httpServletReq.getHeader("User-Agent");
> > ...
> > }
> > }
>
> FYI, for correctness, you may want to change that. All you really care
> about is that the request is an HttpServletRequest. The wrapper is just
> a convenience class. There is nothing forcing an implementation to use
> the HttpServletRequestWrapper. They could write their own
> implementation from scratch only implementing HttpServletRequest and not
> extending the wrapper, which would cause your code to miss the fact that
> HttpServletRequest is actually implemented! With that, you can get rid
> of your outer "if" check and go straight to the HttpServletRequest
> check.
>
> If you only plan on using JS2, then it's not a big deal (other than the
> extra casts and thus the extra work that would be incurred), but if you
> support other environments, I'd definitely change it.
>
> Cheers!
>
> Dave
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.323 / Virus Database: 267.7.1 - Release Date: 6/13/2005
>
>
> ---------------------------------------------------------------------
> 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 do i get the User-Agent info?
Posted by Edmund Urbani <em...@liland.org>.
David Pankros wrote:
>>if (req instanceof HttpServletRequestWrapper) {
>> HttpServletRequestWrapper
>>reqWrapper=(HttpServletRequestWrapper)req;
>> ServletRequest servletReq=reqWrapper.getRequest();
>> if (servletReq instanceof HttpServletRequest) {
>> HttpServletRequest
>>httpServletReq=(HttpServletRequest)servletReq;
>> String userAgent=httpServletReq.getHeader("User-Agent");
>> ...
>> }
>>}
>>
>>
>
>FYI, for correctness, you may want to change that. All you really care
>about is that the request is an HttpServletRequest. The wrapper is just
>a convenience class. There is nothing forcing an implementation to use
>the HttpServletRequestWrapper. They could write their own
>implementation from scratch only implementing HttpServletRequest and not
>extending the wrapper, which would cause your code to miss the fact that
>HttpServletRequest is actually implemented! With that, you can get rid
>of your outer "if" check and go straight to the HttpServletRequest
>check.
>
>If you only plan on using JS2, then it's not a big deal (other than the
>extra casts and thus the extra work that would be incurred), but if you
>support other environments, I'd definitely change it.
>
>Cheers!
>
>Dave
>
>
Thanks. That makes perfect sense. I should have figured that out myself
(if only
I had taken the time to take a closer look at the servlet API).
Edmund
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: how do i get the User-Agent info?
Posted by David Pankros <dp...@miragy.com>.
> if (req instanceof HttpServletRequestWrapper) {
> HttpServletRequestWrapper
> reqWrapper=(HttpServletRequestWrapper)req;
> ServletRequest servletReq=reqWrapper.getRequest();
> if (servletReq instanceof HttpServletRequest) {
> HttpServletRequest
> httpServletReq=(HttpServletRequest)servletReq;
> String userAgent=httpServletReq.getHeader("User-Agent");
> ...
> }
> }
FYI, for correctness, you may want to change that. All you really care
about is that the request is an HttpServletRequest. The wrapper is just
a convenience class. There is nothing forcing an implementation to use
the HttpServletRequestWrapper. They could write their own
implementation from scratch only implementing HttpServletRequest and not
extending the wrapper, which would cause your code to miss the fact that
HttpServletRequest is actually implemented! With that, you can get rid
of your outer "if" check and go straight to the HttpServletRequest
check.
If you only plan on using JS2, then it's not a big deal (other than the
extra casts and thus the extra work that would be incurred), but if you
support other environments, I'd definitely change it.
Cheers!
Dave
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.7.1 - Release Date: 6/13/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: how do i get the User-Agent info?
Posted by Edmund Urbani <em...@liland.org>.
James Liao wrote:
>On 6/14/05, Edmund Urbani <em...@liland.org> wrote:
>
>
>>I'm trying to find out the browser issuing the request in my portlet.
>>Looks like the portlet API provides no way to access the "User-Agent"
>>HTTP header info. At least, I found none. Is there some way to access
>>the servlet request? ...or some jetspeed-2 specific (non-JSR168) way to
>>get this HTTP header?
>>
>>if all else fails, I'll probably have to solve this with javascript and
>>that would be... plain ugly.
>>
>>cheers,
>>Edmund
>>
>>
>>
>>
>Hi,
>You should try this in your portlet code.
>HttpServletRequest sss = (HttpServletRequest)((HttpServletRequestWrapper)
>request).getRequest();
>sss.getHeader("User-Agent");
>
>or you can import a jetspeed2 service named ServletContextProvider into your
>portlet, then you can get HttpServletRequest, HttpServletResponse and
>ServletContext from it.
>
>-James Liao
>
>
the first solution seems to work fine. i'm doing checks with
'instanceof' to be on the safe side here. so it's actually been bloated
to about this:
if (req instanceof HttpServletRequestWrapper) {
HttpServletRequestWrapper reqWrapper=(HttpServletRequestWrapper)req;
ServletRequest servletReq=reqWrapper.getRequest();
if (servletReq instanceof HttpServletRequest) {
HttpServletRequest httpServletReq=(HttpServletRequest)servletReq;
String userAgent=httpServletReq.getHeader("User-Agent");
...
}
}
that should do nicely. thanks a lot!
cheers,
Edmund
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: how do i get the User-Agent info?
Posted by James Liao <ji...@gmail.com>.
Hi,
You should try this in your portlet code.
HttpServletRequest sss = (HttpServletRequest)((HttpServletRequestWrapper)
request).getRequest();
sss.getHeader("User-Agent");
or you can import a jetspeed2 service named ServletContextProvider into your
portlet, then you can get HttpServletRequest, HttpServletResponse and
ServletContext from it.
-James Liao
On 6/14/05, Edmund Urbani <em...@liland.org> wrote:
>
>
> I'm trying to find out the browser issuing the request in my portlet.
> Looks like the portlet API provides no way to access the "User-Agent"
> HTTP header info. At least, I found none. Is there some way to access
> the servlet request? ...or some jetspeed-2 specific (non-JSR168) way to
> get this HTTP header?
>
> if all else fails, I'll probably have to solve this with javascript and
> that would be... plain ugly.
>
> cheers,
> Edmund
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>