You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jan Hoskens <jh...@schaubroeck.be> on 2006/02/13 10:29:41 UTC
continuations
Hi,
I have a flow in which I create a form. When this form is displayed, I
like to keep the continuation to stay alive for as long as the user is
filling in that form (which can take more than one hour, depends on how
many times the user is refilling his cup of tea or coffee, and how many
colleagues are passing by to have a nice chat with ;-) ). I'm thinking
of something similar like daisy does
(http://cocoondev.org/daisy/index.html, made by outerthought): sending a
form which carries an internal frame that refreshes itself every x
minutes. This frame will load a page which contains the original ID from
the form continuation (by request). A small flowscript function will
then call the continuationmanager and retrieve the WebContinuation.
Getting the continuation from this object will trigger the
WebContinuation to update its access time and thus it will stay alive.
Is this sensible? Has anyone else ever tried something alike or solved
this another way? Any comments welcome!
Kind Regards,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: continuations
Posted by Jan Hoskens <jh...@schaubroeck.be>.
Gunter D'Hondt wrote:
>> I don't want my sessions/continuations to have long time-out periods for
>>
> security reasons. It's ok to have them log in again if their session is
> timed out
>
>> after eg a half hour. But then again, when they are editing a form, this
>>
> might take some time, and the responsibility of keeping this form window
>
>> open/uncommitted is completely on their side. So if they are off to
>>
> McDonalds during editing, it's their own decision to leave that window
> open.
>
> this I don't understand coz you started this discussion with the fact that
> you want your continuations to stay alive long enough but you don't want
> to increase your session timeout?? the continuation might survive the
> container session but in my opinion this will be a confusing situation for
> the end user
>
I want my session to be eg only a half hour. So when users are just
browsing (not editing a form) and leave their pc for more than 30
minutes, they need to log in again. Besides this, when they are editing
a form, this might take a while, so when the form is presented, I want
the continuation to be extended as long as the form is on the users
screen/browser. This actually implies that the session will be extended
also. When the users stares at the form for a few hours, an iframe will
periodically contact the server, which automatically extends the session
time, and the continuation related with the form is accessed so that
it's time is extended too.
Kind Regards,
Jan
Re: continuations
Posted by Gunter D'Hondt <gu...@sofico.be>.
> I don't want my sessions/continuations to have long time-out periods for
security reasons. It's ok to have them log in again if their session is
timed out
> after eg a half hour. But then again, when they are editing a form, this
might take some time, and the responsibility of keeping this form window
> open/uncommitted is completely on their side. So if they are off to
McDonalds during editing, it's their own decision to leave that window
open.
this I don't understand coz you started this discussion with the fact that
you want your continuations to stay alive long enough but you don't want
to increase your session timeout?? the continuation might survive the
container session but in my opinion this will be a confusing situation for
the end user
Jan Hoskens <jh...@schaubroeck.be>
13/02/2006 11:31
Please respond to
users@cocoon.apache.org
To
users@cocoon.apache.org
cc
Subject
Re: continuations
Fabrizio Sitzia wrote:
Hello,
I have a flow in which I create a form. When this form is displayed, I
like to keep the continuation to stay alive for as long as the user is
filling in that form (which can take more than one hour, depends on how
many times the user is refilling his cup of tea or coffee, and how many
colleagues are passing by to have a nice chat with...
Yep, and people tend to get very upset if they spent 5 minutes beginning
to fill out a form just before they left for a 2 hour lunch, and find
their session has expired when they come back!
For a less security-critical intranet app, I therefore defined a timeout
of 4 hours, as follows:
- In "cocoon.xconf", I set the continuations-manager's time-to-live"
attribute to 14400000 (4 hours * 3600 seconds * 1000 milliseconds :-)
I also set the "session-bound-continuations" attribute to "true", as
there is no point leaving continuations around when the servlet
container's session has expired...
That's correct, I'll definitely check that session-bound-continuations
attribute, thanks for the info.
- I also set the servlet container's (Jetty) session-timeout to 4 hours
(240 minutes), by adding the following to its "web.xml" file:
...
<session-config>
<session-timeout>240</session-timeout>
</session-config>
</web-app>
I don't want my sessions/continuations to have long time-out periods for
security reasons. It's ok to have them log in again if their session is
timed out after eg a half hour. But then again, when they are editing a
form, this might take some time, and the responsibility of keeping this
form window open/uncommitted is completely on their side. So if they are
off to McDonalds during editing, it's their own decision to leave that
window open.
Kind Regards,
Jan
Fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: continuations
Posted by Jan Hoskens <jh...@schaubroeck.be>.
Fabrizio Sitzia wrote:
> Hello,
>
>
>> I have a flow in which I create a form. When this form is displayed, I
>> like to keep the continuation to stay alive for as long as the user is
>> filling in that form (which can take more than one hour, depends on how
>> many times the user is refilling his cup of tea or coffee, and how many
>> colleagues are passing by to have a nice chat with...
>>
>
> Yep, and people tend to get very upset if they spent 5 minutes beginning
> to fill out a form just before they left for a 2 hour lunch, and find
> their session has expired when they come back!
>
> For a less security-critical intranet app, I therefore defined a timeout
> of 4 hours, as follows:
>
> - In "cocoon.xconf", I set the continuations-manager's time-to-live"
> attribute to 14400000 (4 hours * 3600 seconds * 1000 milliseconds :-)
> I also set the "session-bound-continuations" attribute to "true", as
> there is no point leaving continuations around when the servlet
> container's session has expired...
>
That's correct, I'll definitely check that session-bound-continuations
attribute, thanks for the info.
> - I also set the servlet container's (Jetty) session-timeout to 4 hours
> (240 minutes), by adding the following to its "web.xml" file:
>
> ...
> <session-config>
> <session-timeout>240</session-timeout>
> </session-config>
> </web-app>
>
I don't want my sessions/continuations to have long time-out periods for
security reasons. It's ok to have them log in again if their session is
timed out after eg a half hour. But then again, when they are editing a
form, this might take some time, and the responsibility of keeping this
form window open/uncommitted is completely on their side. So if they are
off to McDonalds during editing, it's their own decision to leave that
window open.
Kind Regards,
Jan
>
> Fabrizio
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: continuations
Posted by Fabrizio Sitzia <fa...@chem.lu>.
Hello,
> I have a flow in which I create a form. When this form is displayed, I
> like to keep the continuation to stay alive for as long as the user is
> filling in that form (which can take more than one hour, depends on how
> many times the user is refilling his cup of tea or coffee, and how many
> colleagues are passing by to have a nice chat with...
Yep, and people tend to get very upset if they spent 5 minutes beginning
to fill out a form just before they left for a 2 hour lunch, and find
their session has expired when they come back!
For a less security-critical intranet app, I therefore defined a timeout
of 4 hours, as follows:
- In "cocoon.xconf", I set the continuations-manager's time-to-live"
attribute to 14400000 (4 hours * 3600 seconds * 1000 milliseconds :-)
I also set the "session-bound-continuations" attribute to "true", as
there is no point leaving continuations around when the servlet
container's session has expired...
- I also set the servlet container's (Jetty) session-timeout to 4 hours
(240 minutes), by adding the following to its "web.xml" file:
...
<session-config>
<session-timeout>240</session-timeout>
</session-config>
</web-app>
Fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: get values from multivaluefield
Posted by Gunter D'Hondt <gu...@sofico.be>.
sorry my bad; solved with:
Object[] myvalues= (Object[]) myfield.getValue();
... myvalues[i].toString() ...
Gunter D'Hondt <gu...@sofico.be>
13/02/2006 11:31
Please respond to
users@cocoon.apache.org
To
users@cocoon.apache.org
cc
Subject
get values from multivaluefield
I'm trying to get the string array from a multivaluefield widget; so
something like getValues() which returns an Object[] instead of the
getValue() which returns an Object. Is there a reason why the getValues()
is not implemented while the setValues() and setValue() is?
MultiValueField myfield = (MultiValueField) myform.getWidget("mywifes");
String[] myvalues = (String[]) myfield.getValue();
--> which doesn't work since casting from Object to String[] gives a
ClassCastException
Regards,
Gunter D'Hondt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
get values from multivaluefield
Posted by Gunter D'Hondt <gu...@sofico.be>.
I'm trying to get the string array from a multivaluefield widget; so
something like getValues() which returns an Object[] instead of the
getValue() which returns an Object. Is there a reason why the getValues()
is not implemented while the setValues() and setValue() is?
MultiValueField myfield = (MultiValueField) myform.getWidget("mywifes");
String[] myvalues = (String[]) myfield.getValue();
--> which doesn't work since casting from Object to String[] gives a
ClassCastException
Regards,
Gunter D'Hondt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: continuations
Posted by Jan Hoskens <jh...@schaubroeck.be>.
Gunter D'Hondt wrote:
> done that trick also for a few sites but major problem here might consists
> that the client browser must have javascript enabled (to force the reload
> of the frame) and it must support frames (which is ugly) or iframes (which
> is IE only)
>
IFrames is a html 4.0 element and supported by more browsers (ie 3.0+,
nn 6.0+, moz 1.0+, ff 1.0+ , op 4.0+), besides this our customers
mostly use IE 6 or up with javascript enabled (needed in other webapps
we use).
> can't you just always keep the continuations alive; so setting no session
> timeouts; or you might even temporarily store them yourself on a disk/db
> or whatever
>
If setting no timeouts, are continuations kept alive forever or will a
default timeout setting be used? When will the continuation be set
invalid so it can be removed from the cache? I'm not looking forward to
writing my own continuation storage.
Kind Regards,
Jan
> Regards,
> Gunter D'Hondt
>
>
>
>
>
>
> Jan Hoskens <jh...@schaubroeck.be>
> 13/02/2006 10:29
> Please respond to
> users@cocoon.apache.org
>
>
> To
> users@cocoon.apache.org
> cc
>
> Subject
> continuations
>
>
>
>
>
>
> Hi,
>
> I have a flow in which I create a form. When this form is displayed, I
> like to keep the continuation to stay alive for as long as the user is
> filling in that form (which can take more than one hour, depends on how
> many times the user is refilling his cup of tea or coffee, and how many
> colleagues are passing by to have a nice chat with ;-) ). I'm thinking
> of something similar like daisy does
> (http://cocoondev.org/daisy/index.html, made by outerthought): sending a
> form which carries an internal frame that refreshes itself every x
> minutes. This frame will load a page which contains the original ID from
> the form continuation (by request). A small flowscript function will
> then call the continuationmanager and retrieve the WebContinuation.
> Getting the continuation from this object will trigger the
> WebContinuation to update its access time and thus it will stay alive.
>
> Is this sensible? Has anyone else ever tried something alike or solved
> this another way? Any comments welcome!
>
>
> Kind Regards,
> Jan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: continuations
Posted by Gunter D'Hondt <gu...@sofico.be>.
done that trick also for a few sites but major problem here might consists
that the client browser must have javascript enabled (to force the reload
of the frame) and it must support frames (which is ugly) or iframes (which
is IE only)
can't you just always keep the continuations alive; so setting no session
timeouts; or you might even temporarily store them yourself on a disk/db
or whatever
Regards,
Gunter D'Hondt
Jan Hoskens <jh...@schaubroeck.be>
13/02/2006 10:29
Please respond to
users@cocoon.apache.org
To
users@cocoon.apache.org
cc
Subject
continuations
Hi,
I have a flow in which I create a form. When this form is displayed, I
like to keep the continuation to stay alive for as long as the user is
filling in that form (which can take more than one hour, depends on how
many times the user is refilling his cup of tea or coffee, and how many
colleagues are passing by to have a nice chat with ;-) ). I'm thinking
of something similar like daisy does
(http://cocoondev.org/daisy/index.html, made by outerthought): sending a
form which carries an internal frame that refreshes itself every x
minutes. This frame will load a page which contains the original ID from
the form continuation (by request). A small flowscript function will
then call the continuationmanager and retrieve the WebContinuation.
Getting the continuation from this object will trigger the
WebContinuation to update its access time and thus it will stay alive.
Is this sensible? Has anyone else ever tried something alike or solved
this another way? Any comments welcome!
Kind Regards,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org