You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Johnny Cass <ar...@jab.org> on 2001/04/17 13:17:38 UTC
Re: RunData parameter history ( was: Quick Question )
Jon Stevens wrote:
>
> on 4/16/01 12:47 PM, "Daniel Rall" <dl...@collab.net> wrote:
>
> Jon Stevens <jo...@latchkey.com> writes:
>
> nextNextTemplate
>
> nextTemplateSquared
>
> templateAfterTheNextTemplate
>
I tried to do something similar using Jetspeed. I wanted to add 'Back'
and 'Forward' buttons for each portlet ( just like a browser ). I wrote
a RunDataParameterHistory class that added the RunData's ParameterParser
object to a Vector on each new request.
When the portlet renders, it checks if one of the back or forward
buttons were pressed and then uses the previous or next ParameterParser
object from the history for all processing instead of the current
request's RunData's ParameterParser.
I have no idea if this behaviour is at all acceptable.
What I liked about it is that *ALL* the RunData parameters are
preserved. So if you displayed a specific template, executed an action,
and supplied parameters for that action on some previous request, all
you needed to do was fetch the right ParameterParser from the history
and the page will render exactly the way it did the first time ( with
all the actions executed again and the right template displayed ).
Anybody think I took a wrong turn?
- Johnny
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: RunData parameter history ( was: Quick Question )
Posted by Johnny Cass <ar...@jab.org>.
John McNally wrote:
>
> This sounds fine to me. I assume you are storing the vector in the
> session.
Each portlet manages it's own history vector. Parameterparsers are only
added to the portlet's history if they have an effect on the portlet's
content.
> How do you handle browsers within the same session at
> different states?
This is the one snag... :(
> It is not a problem to declare an application single
> browser only, I just do not want it to become the standard imposed by
> Turbine. And there is no reason to do it for a simple String parameter,
> like lastTemplate.
>
> The other problem to be addressed is if other state data is being stored
> in the session, you need to save copies of the User temp and perm
> hashtables.
In our case, we want the state to be determined by the URL alone. There
shouldn't be any other state dependencies.
> And in general you need to worry about other storage of
> data. The solution is very application dependent.
>
> john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: RunData parameter history ( was: Quick Question )
Posted by John McNally <jm...@collab.net>.
This sounds fine to me. I assume you are storing the vector in the
session. How do you handle browsers within the same session at
different states? It is not a problem to declare an application single
browser only, I just do not want it to become the standard imposed by
Turbine. And there is no reason to do it for a simple String parameter,
like lastTemplate.
The other problem to be addressed is if other state data is being stored
in the session, you need to save copies of the User temp and perm
hashtables. And in general you need to worry about other storage of
data. The solution is very application dependent.
john mcnally
Johnny Cass wrote:
>
> Jon Stevens wrote:
> >
> > on 4/16/01 12:47 PM, "Daniel Rall" <dl...@collab.net> wrote:
> >
> > Jon Stevens <jo...@latchkey.com> writes:
> >
> > nextNextTemplate
> >
> > nextTemplateSquared
> >
> > templateAfterTheNextTemplate
> >
>
> I tried to do something similar using Jetspeed. I wanted to add 'Back'
> and 'Forward' buttons for each portlet ( just like a browser ). I wrote
> a RunDataParameterHistory class that added the RunData's ParameterParser
> object to a Vector on each new request.
>
> When the portlet renders, it checks if one of the back or forward
> buttons were pressed and then uses the previous or next ParameterParser
> object from the history for all processing instead of the current
> request's RunData's ParameterParser.
>
> I have no idea if this behaviour is at all acceptable.
>
> What I liked about it is that *ALL* the RunData parameters are
> preserved. So if you displayed a specific template, executed an action,
> and supplied parameters for that action on some previous request, all
> you needed to do was fetch the right ParameterParser from the history
> and the page will render exactly the way it did the first time ( with
> all the actions executed again and the right template displayed ).
>
> Anybody think I took a wrong turn?
>
> - Johnny
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org