subject:"Re\: Persistance"

Re: Persistance

2009-01-14 Thread Ville Virtanen

Moi Kalle,

I would try to achieve something like that using:

Custom PersistentFieldStrategy
(http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/PersistentFieldStrategy.html)

Custom LinkFactoryListener
(http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/internal/services/LinkFactoryListener.html)

Custom ComponentEventRequestFilter + PageRenderRequestFilter
(http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventRequestFilter.html)

Then in theory you can code the conversation id to all links and forms, use
the filters to intercept the request and get the id back and finally use the
id to retrieve the value from ConversationManager via the CustomPersistence
strategy. The persistence strategy may use ehcache or something like that to
actually persist the objects. The request object can be used to transmit the
conversation id from the filter to the persistence strategy?

This implementation could also be per client tab and not at all dependent of
the session etc.

Just some quick thoughts..

- Ville

Kalle Korhonen-2 wrote:

I don't know if there's a better thread for discussing page scope and
conversation (if you know other threads, please link them in) but I'm just
doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic implementation
for conversations by dictating that a conversation should always happen on
a
single page or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be bookmarkable and
that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared to
xml-based navigation flow configurations). These conversations could also
be
cleaned from session before the session expires and can have individual
timeout values.

Regarding the problem with multiple pages that others have already pointed
out, with or without using cookies the urls need to be different (so the
page contexts can be kept separate). Typically when editing a single
object,
you don't even want to allow multiple windows and this can be easily dealt
with cookies transparently to the user. The only good example of where
multi-window support is actually useful that I can come up with is search
(say when you are trying to find the best flight to a destination). There,
I
wouldn't even like to necessary have a conversation identifier as part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123) since
it's not meaningful to bookmark a url with a conversationId in it, but T5
doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests (from
the
same page) are participating in the same conversation. However, one of the
issues with T5 I haven't been able to satisfactorily solve is forcing a
page
to use an additional context parameter. I've tried with returning the same
page from onActivate then setting a conversation id in onPassivate, which
works in principle but only if I persist the conversation id which kind of
defies the point. Anybody happen to have a good, generic solution for
automatically adding parameters to the activation context (so they are
visible in the url)? I'd be also interested to know if anybody has
thoughts
on these ideas or is further along in providing a generic implementation
for
conversations in T5.

Kalle

On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue teamp...@gmail.com wrote:

In the past I manually implemented this behavior by mixing server side
and
client side persistence. My code-fu was probably not very elegant.

In my case, a user could open a report page after filling out a page of
variables. These report pages would open in a new browser window/tab. So
instantly you have the situation where two reports can be open but use
different data. I would store a client side string on each report page,
and
LRU hash map on the ASO side would match it to the relative data, just
before the report was run and a new page opened. If it was in the LRU, I
could grab the cached report. If not, I still had enough information to
run
the report again. If the report page needed to be refreshed (such as
sorting something on the page, non-async), the client side key would look
up
the data.

I used a small LRU limit (like 5) to keep the size down.

Daniel

On Fri, Nov 28, 2008 at 10:18 PM, thermus msch...@gmail.com wrote:

I'm interested in this as well. Specifically if a user has two page
instances open, how can T5 persistence be used reliably?

I found on Safari and Firefox (not sure about IE, but likely a problem
there
as well) that the persisted session properties are shared between page
instances and each page can overwrite the another. My searches didn't
come
up with a

Re: Persistance

2009-01-14 Thread Geoff Callender

It would be great if Tapestry provided a really nice clear solution to
conversation state (and continuations), but in the meantime the
workarounds are actually not all that hard. Have you looked at the 3
Wizard examples and the Conversations List at http://jumpstart.doublenegative.com.au:8080/jumpstart/
?

One modification I'd like to make to the Wizards is to defer assigning
a conversation id until you're on your way from the first page to the
second page.

Howard's talking about somehow making 5.1 work with Spring WebFlow.
I'll follow that one with great interest, but I'll be wearing my
sceptics hat as I fear that the SWF medicine might be worse than the
problem it's trying to solve.

Here are some good discussions of the problem:

http://www.developertutorials.com/tutorials/java/develop-complex-web-applications-050422/page1.html
http://rifers.org/blogs/gbevin/2005/4/11/continuations_continuations
http://www.artima.com/forums/flat.jsp?forum=226thread=197351

http://debasishg.blogspot.com/2006/07/spring-web-flow-declarative-web.html

Geoff

On 14/01/2009, at 5:25 PM, Kalle Korhonen wrote:

I don't know if there's a better thread for discussing page scope and
conversation (if you know other threads, please link them in) but
I'm just

doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic
implementation
for conversations by dictating that a conversation should always
happen on a

single page or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be
bookmarkable and

that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared to
xml-based navigation flow configurations). These conversations could
also be
cleaned from session before the session expires and can have
individual

timeout values.

with cookies transparently to the user. The only good example of where
multi-window support is actually useful that I can come up with is
search
(say when you are trying to find the best flight to a destination).
There, I
wouldn't even like to necessary have a conversation identifier as
part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123)
since
it's not meaningful to bookmark a url with a conversationId in it,
but T5

doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests
(from the
same page) are participating in the same conversation. However, one
of the
issues with T5 I haven't been able to satisfactorily solve is
forcing a page
to use an additional context parameter. I've tried with returning
the same
page from onActivate then setting a conversation id in onPassivate,
which
works in principle but only if I persist the conversation id which
kind of

defies the point. Anybody happen to have a good, generic solution for
automatically adding parameters to the activation context (so they are
visible in the url)? I'd be also interested to know if anybody has
thoughts
on these ideas or is further along in providing a generic
implementation for

conversations in T5.

Kalle

On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue teamp...@gmail.com
wrote:

In the past I manually implemented this behavior by mixing server
side and

client side persistence. My code-fu was probably not very elegant.

and
LRU hash map on the ASO side would match it to the relative data,
just
before the report was run and a new page opened. If it was in the
LRU, I
could grab the cached report. If not, I still had enough
information to

run
the report again. If the report page needed to be refreshed (such as
sorting something on the page, non-async), the client side key
would look

up
the data.

I used a small LRU limit (like 5) to keep the size down.

Daniel

On Fri, Nov 28, 2008 at 10:18 PM, thermus msch...@gmail.com wrote:

I'm interested in this as well. Specifically if a user has two page
instances open, how can T5 persistence be used reliably?

I found on Safari and Firefox (not sure about IE, but likely a
problem

there
as well) that the persisted session properties are shared between
page
instances and each page can overwrite the

Re: Persistance

2009-01-14 Thread Ville Virtanen

But still the wizard example requires session in some form and thus the same
conversation in two tabs scenario is not possible?

- Ville

Geoff Callender-2 wrote:

It would be great if Tapestry provided a really nice clear solution to
conversation state (and continuations), but in the meantime the
workarounds are actually not all that hard. Have you looked at the 3
Wizard examples and the Conversations List at
http://jumpstart.doublenegative.com.au:8080/jumpstart/
?

One modification I'd like to make to the Wizards is to defer assigning
a conversation id until you're on your way from the first page to the
second page.

Here are some good discussions of the problem:

http://debasishg.blogspot.com/2006/07/spring-web-flow-declarative-web.html

Geoff

On 14/01/2009, at 5:25 PM, Kalle Korhonen wrote:

I don't know if there's a better thread for discussing page scope and
conversation (if you know other threads, please link them in) but
I'm just
doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic
implementation
for conversations by dictating that a conversation should always
happen on a
single page or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be
bookmarkable and
that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared to
xml-based navigation flow configurations). These conversations could
also be
cleaned from session before the session expires and can have
individual
timeout values.

Regarding the problem with multiple pages that others have already
pointed
out, with or without using cookies the urls need to be different (so
the
page contexts can be kept separate). Typically when editing a single
object,
you don't even want to allow multiple windows and this can be easily
dealt
with cookies transparently to the user. The only good example of where
multi-window support is actually useful that I can come up with is
search
(say when you are trying to find the best flight to a destination).
There, I
wouldn't even like to necessary have a conversation identifier as
part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123)
since
it's not meaningful to bookmark a url with a conversationId in it,
but T5
doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests
(from the
same page) are participating in the same conversation. However, one
of the
issues with T5 I haven't been able to satisfactorily solve is
forcing a page
to use an additional context parameter. I've tried with returning
the same
page from onActivate then setting a conversation id in onPassivate,
which
works in principle but only if I persist the conversation id which
kind of
defies the point. Anybody happen to have a good, generic solution for
automatically adding parameters to the activation context (so they are
visible in the url)? I'd be also interested to know if anybody has
thoughts
on these ideas or is further along in providing a generic
implementation for
conversations in T5.

Kalle

On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue teamp...@gmail.com
wrote:

In the past I manually implemented this behavior by mixing server
side and
client side persistence. My code-fu was probably not very elegant.

In my case, a user could open a report page after filling out a
page of
variables. These report pages would open in a new browser window/
tab. So
instantly you have the situation where two reports can be open but
use
different data. I would store a client side string on each report
page,
and
LRU hash map on the ASO side would match it to the relative data,
just
before the report was run and a new page opened. If it was in the
LRU, I
could grab the cached report. If not, I still had enough
information to
run
the report again. If the report page needed to be refreshed (such as
sorting something on the page, non-async), the client side key
would look
up
the data.

I used a small LRU limit (like 5) to keep the size down.

Daniel

On Fri, Nov 28, 2008 at 10:18 PM, thermus msch...@gmail.com wrote:

I'm interested in this as well. Specifically if a user has two page
instances

Re: Persistance

2009-01-14 Thread Geoff Callender

Try it!

What you'll see is that if you open two tabs or windows and then start
the Wizard in each one then they will get different conversations.
This allows you, for example, to work on two orders at once.

If, however, you start the Wizard AND then open a new tab or window
AND your browser preferences are set to open with the current URL AND
the browser is not IE or Chrome, then they will share the
conversation. I think this is reasonable because it's the preference
you have set. To avoid it, I guess some javascript would be required
to detect the situation in the new tab or window or perhaps to prevent
new tab or window being started? But maybe that's going too far?

Geoff

On 14/01/2009, at 10:45 PM, Ville Virtanen wrote:

But still the wizard example requires session in some form and thus
the same

conversation in two tabs scenario is not possible?

- Ville

Geoff Callender-2 wrote:

It would be great if Tapestry provided a really nice clear solution
to

conversation state (and continuations), but in the meantime the
workarounds are actually not all that hard. Have you looked at the 3
Wizard examples and the Conversations List at
http://jumpstart.doublenegative.com.au:8080/jumpstart/
?

One modification I'd like to make to the Wizards is to defer
assigning

a conversation id until you're on your way from the first page to the
second page.

Here are some good discussions of the problem:

http://debasishg.blogspot.com/2006/07/spring-web-flow-declarative-web.html

Geoff

On 14/01/2009, at 5:25 PM, Kalle Korhonen wrote:

I don't know if there's a better thread for discussing page scope
and

conversation (if you know other threads, please link them in) but
I'm just
doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic
implementation
for conversations by dictating that a conversation should always
happen on a
single page or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be
bookmarkable and
that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared
to

xml-based navigation flow configurations). These conversations could
also be
cleaned from session before the session expires and can have
individual
timeout values.

multi-window support is actually useful that I can come up with is
search
(say when you are trying to find the best flight to a destination).
There, I
wouldn't even like to necessary have a conversation identifier as
part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123)
since
it's not meaningful to bookmark a url with a conversationId in it,
but T5
doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests
(from the
same page) are participating in the same conversation. However, one
of the
issues with T5 I haven't been able to satisfactorily solve is
forcing a page
to use an additional context parameter. I've tried with returning
the same
page from onActivate then setting a conversation id in onPassivate,
which
works in principle but only if I persist the conversation id which
kind of
defies the point. Anybody happen to have a good, generic solution
for
automatically adding parameters to the activation context (so they
are

visible in the url)? I'd be also interested to know if anybody has
thoughts
on these ideas or is further along in providing a generic
implementation for
conversations in T5.

Kalle

On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue teamp...@gmail.com
wrote:

In the past I manually implemented this behavior by mixing server
side and
client side persistence. My code-fu was probably not very elegant.

Re: Persistance

2009-01-14 Thread Ville Virtanen

Ok, it uses currentMillis inside the session to differentiate the
conversations. It works, but as we are seasoned T5 users we expect
everything to just work without all that scary java code :)

- Ville

Ps. Seriously I appreciate greatly your effort and just want to say Thank
you. (I've learned quite a bit reading through jumpstart examples.)

Geoff Callender-2 wrote:

Try it!

What you'll see is that if you open two tabs or windows and then start
the Wizard in each one then they will get different conversations.
This allows you, for example, to work on two orders at once.

Geoff

On 14/01/2009, at 10:45 PM, Ville Virtanen wrote:

But still the wizard example requires session in some form and thus
the same
conversation in two tabs scenario is not possible?

- Ville

Geoff Callender-2 wrote:

It would be great if Tapestry provided a really nice clear solution
to
conversation state (and continuations), but in the meantime the
workarounds are actually not all that hard. Have you looked at the 3
Wizard examples and the Conversations List at
http://jumpstart.doublenegative.com.au:8080/jumpstart/
?

One modification I'd like to make to the Wizards is to defer
assigning
a conversation id until you're on your way from the first page to the
second page.

Here are some good discussions of the problem:

http://debasishg.blogspot.com/2006/07/spring-web-flow-declarative-web.html

Geoff

On 14/01/2009, at 5:25 PM, Kalle Korhonen wrote:

I don't know if there's a better thread for discussing page scope
and
conversation (if you know other threads, please link them in) but
I'm just
doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic
implementation
for conversations by dictating that a conversation should always
happen on a
single page or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be
bookmarkable and
that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared
to
xml-based navigation flow configurations). These conversations could
also be
cleaned from session before the session expires and can have
individual
timeout values.

Regarding the problem with multiple pages that others have already
pointed
out, with or without using cookies the urls need to be different (so
the
page contexts can be kept separate). Typically when editing a single
object,
you don't even want to allow multiple windows and this can be easily
dealt
with cookies transparently to the user. The only good example of
where
multi-window support is actually useful that I can come up with is
search
(say when you are trying to find the best flight to a destination).
There, I
wouldn't even like to necessary have a conversation identifier as
part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123)
since
it's not meaningful to bookmark a url with a conversationId in it,
but T5
doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests
(from the
same page) are participating in the same conversation. However, one
of the
issues with T5 I haven't been able to satisfactorily solve is
forcing a page
to use an additional context parameter. I've tried with returning
the same
page from onActivate then setting a conversation id in onPassivate,
which
works in principle but only if I persist the conversation id which
kind of
defies the point. Anybody happen to have a good, generic solution
for
automatically adding parameters to the activation context (so they
are
visible in the url)? I'd be also interested to know if anybody has
thoughts
on these ideas or is further along in providing a generic
implementation for
conversations in T5.

Kalle

On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue

Re: Persistance

2009-01-14 Thread Kalle Korhonen

On Wed, Jan 14, 2009 at 1:29 AM, Ville Virtanen ville.virta...@cerion.fiwrote:

I would try to achieve something like that using:
Custom PersistentFieldStrategy
(
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/PersistentFieldStrategy.html
)
Custom LinkFactoryListener
(
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/internal/services/LinkFactoryListener.html
)
Custom ComponentEventRequestFilter + PageRenderRequestFilter
(
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventRequestFilter.html
)

Moi moi Ville,

thanks for the links. A custom PersistentFieldStrategy is certainly
something I'm currently looking into.

Then in theory you can code the conversation id to all links and forms, use
the filters to intercept the request and get the id back and finally use
the
id to retrieve the value from ConversationManager via the CustomPersistence
strategy. The persistence strategy may use ehcache or something like that
to
actually persist the objects. The request object can be used to transmit
the
conversation id from the filter to the persistence strategy?

I think its a minor detail whether the id is part of the url a parameter.
EHCache doesn't really come to play, I actually want to keep the
conversation as part of the session (you log out, it'll end all
conversations). In my view, users would have lots of short-lived
conversations going on, each using session but so they don't step on each
other.

This implementation could also be per client tab and not at all dependent of
the session etc.

From my opinion, a session is one of the biggest things going for Java
webapps compared to two-tier db-backed architectures like PHP, we just have
to learn to use it the right way.

Kalle

Kalle Korhonen-2 wrote:

I don't know if there's a better thread for discussing page scope and
conversation (if you know other threads, please link them in) but I'm
just
doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic
implementation
for conversations by dictating that a conversation should always happen
on
a
single page or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be bookmarkable
and
that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared to
xml-based navigation flow configurations). These conversations could also
be
cleaned from session before the session expires and can have individual
timeout values.

Regarding the problem with multiple pages that others have already
pointed
out, with or without using cookies the urls need to be different (so the
page contexts can be kept separate). Typically when editing a single
object,
you don't even want to allow multiple windows and this can be easily
dealt
with cookies transparently to the user. The only good example of where
multi-window support is actually useful that I can come up with is search
(say when you are trying to find the best flight to a destination).
There,
I
wouldn't even like to necessary have a conversation identifier as part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123) since
it's not meaningful to bookmark a url with a conversationId in it, but T5
doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests (from
the
same page) are participating in the same conversation. However, one of
the
issues with T5 I haven't been able to satisfactorily solve is forcing a
page
to use an additional context parameter. I've tried with returning the
same
page from onActivate then setting a conversation id in onPassivate, which
works in principle but only if I persist the conversation id which kind
of
defies the point. Anybody happen to have a good, generic solution for
automatically adding parameters to the activation context (so they are
visible in the url)? I'd be also interested to know if anybody has
thoughts
on these ideas or is further along in providing a generic implementation
for
conversations in T5.

Kalle

On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue teamp...@gmail.com wrote:

In the past I manually implemented this behavior by mixing server side
and
client side persistence. My code-fu was probably not very elegant.

Re: Persistance

2009-01-14 Thread Kalle Korhonen

On Wed, Jan 14, 2009 at 1:39 AM, Geoff Callender 
geoff.callender.jumpst...@gmail.com wrote:

 It would be great if Tapestry provided a really nice clear solution to
 conversation state (and continuations), but in the meantime the workarounds
 are actually not all that hard.  Have you looked at the 3 Wizard examples
 and the Conversations List at
 http://jumpstart.doublenegative.com.au:8080/jumpstart/ ?


I know, and obviously I've looked at your examples; where else would one
learn T5 from :) Continuations actually have very little to do with it when
the only problem I really want to solve is to have a scope longer than
request but one that doesn't pollute the session till it expires. While
continuations and RIFE is very innovative, it really is targeted to solve a
different problem than what I'm after.


 One modification I'd like to make to the Wizards is to defer assigning a
 conversation id until you're on your way from the first page to the second
 page.
 Howard's talking about somehow making 5.1 work with Spring WebFlow. I'll
 follow that one with great interest, but I'll be wearing my sceptics hat as
 I fear that the SWF medicine might be worse than the problem it's trying to
 solve.


Agree, flows complicate things and don't offer a generic solution to this
problem. I've used SWF (and tried out Seam as well) but I really don't want
to force developers to require configuring flows consisting of multiple
pages when most of the time you just want that object to survive through a
few requests so you can display the validation errors and/or the success
message with the data the object contains. Personally I'm sold on ajax to a
point where I don't see a need to worry about back buttons or design
operation logic in a traditional way with multiple pages for a single
operation/conversation. Pages/urls are useful for differentiating between
separate logical operations like edit profile or search but if you click on
back button you should go to the previous operation, not to a previous stage
within the same operation. Wizards are of course a little different; you may
want to even independently store the whole state once you are half-way
through the wizard and go back and forth between the stages (where
continuations are also very useful), but the conversations in my mind a
really short-lived, happening for example on a single page/stage/url of a
wizard.

Thanks Geoff for the links as well; if we have any other threads about this
on the Tapestry mailing list, please continue linking them here.

Kalle



 Here are some good discussions of the problem:


 http://www.developertutorials.com/tutorials/java/develop-complex-web-applications-050422/page1.html

 http://rifers.org/blogs/gbevin/2005/4/11/continuations_continuations
http://www.artima.com/forums/flat.jsp?forum=226thread=197351

 http://debasishg.blogspot.com/2006/07/spring-web-flow-declarative-web.html

 Geoff


 On 14/01/2009, at 5:25 PM, Kalle Korhonen wrote:

  I don't know if there's a better thread for discussing page scope and
 conversation (if you know other threads, please link them in) but I'm just
 doing research on this topic for supporting conversations in Trails.
 Shortly, I'm hoping that it'd be possible to have a generic implementation
 for conversations by dictating that a conversation should always happen on
 a
 single page or url with asynchronous calls. From my point of view,
 assuming that only the beginning of a conversation can be bookmarkable and
 that a conversation has one-to-one mapping with a url are reasonable
 conventions and will greatly simplify the required logic (compared to
 xml-based navigation flow configurations). These conversations could also
 be
 cleaned from session before the session expires and can have individual
 timeout values.

 Regarding the problem with multiple pages that others have already pointed
 out, with or without using cookies the urls need to be different (so the
 page contexts can be kept separate). Typically when editing a single
 object,
 you don't even want to allow multiple windows and this can be easily dealt
 with cookies transparently to the user. The only good example of where
 multi-window support is actually useful that I can come up with is search
 (say when you are trying to find the best flight to a destination). There,
 I
 wouldn't even like to necessary have a conversation identifier as part of
 the url, but as a parameter (e.g. /travelsearch?conversationId=123) since
 it's not meaningful to bookmark a url with a conversationId in it, but T5
 doesn't allow one to easily manipulate urls and the page context is
 extremely handy way of making sure all subsequent action requests (from
 the
 same page) are participating in the same conversation. However, one of the
 issues with T5 I haven't been able to satisfactorily solve is forcing a
 page
 to use an additional context parameter. I've tried with returning the same
 page from onActivate then setting a conversation id in

Re: Persistance

2009-01-13 Thread Kalle Korhonen

I don't know if there's a better thread for discussing page scope and
conversation (if you know other threads, please link them in) but I'm just
doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic implementation
for conversations by dictating that a conversation should always happen on a
single page or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be bookmarkable and
that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared to
xml-based navigation flow configurations). These conversations could also be
cleaned from session before the session expires and can have individual
timeout values.

Regarding the problem with multiple pages that others have already pointed
out, with or without using cookies the urls need to be different (so the
page contexts can be kept separate). Typically when editing a single object,
you don't even want to allow multiple windows and this can be easily dealt
with cookies transparently to the user. The only good example of where
multi-window support is actually useful that I can come up with is search
(say when you are trying to find the best flight to a destination). There, I
wouldn't even like to necessary have a conversation identifier as part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123) since
it's not meaningful to bookmark a url with a conversationId in it, but T5
doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests (from the
same page) are participating in the same conversation. However, one of the
issues with T5 I haven't been able to satisfactorily solve is forcing a page
to use an additional context parameter. I've tried with returning the same
page from onActivate then setting a conversation id in onPassivate, which
works in principle but only if I persist the conversation id which kind of
defies the point. Anybody happen to have a good, generic solution for
automatically adding parameters to the activation context (so they are
visible in the url)? I'd be also interested to know if anybody has thoughts
on these ideas or is further along in providing a generic implementation for
conversations in T5.

Kalle


On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue teamp...@gmail.com wrote:

 In the past I manually implemented this behavior by mixing server side and
 client side persistence.  My code-fu was probably not very elegant.

 In my case, a user could open a report page after filling out a page of
 variables.  These report pages would open in a new browser window/tab. So
 instantly you have the situation where two reports can be open but use
 different data.  I would store a client side string on each report page,
 and
 LRU hash map on the ASO side would match it to the relative data, just
 before the report was run and a new page opened.  If it was in the LRU, I
 could grab the cached report.  If not, I still had enough information to
 run
 the report again.  If the report page needed to be refreshed (such as
 sorting something on the page, non-async), the client side key would look
 up
 the data.

 I used a small LRU limit (like 5) to keep the size down.

 Daniel

 On Fri, Nov 28, 2008 at 10:18 PM, thermus msch...@gmail.com wrote:

 
  I'm interested in this as well.  Specifically if a user has two page
  instances open, how can T5 persistence be used reliably?
 
  I found on Safari and Firefox (not sure about IE, but likely a problem
  there
  as well) that the persisted session properties are shared between page
  instances and each page can overwrite the another.  My searches didn't
 come
  up with a definitive answer although I did see that the question has been
  asked several times.  Can anyone comment on this or provide a workaround?
 
 
 
  Peter Stavrinides wrote:
  
   ... but what would be ideal in my humble view is a proper page
  persistence
   Strategy, where a value is retained until the user leaves the page. In
   truth someone posted such a solution which used a cookie, and it seemed
  to
   behave exactly as it should, nevertheless I am still against relying on
 a
   cookie. I understand this may be difficult to implement due to
 Tapestry's
   inner workings, particularly the way pages are pooled, but since
   conversational state covers some of this ground (the difference being a
   conversation is tied to not only the page, but the window so each tab
 is
   treated as a new conversation)...
  
 
  --
  View this message in context:
  http://www.nabble.com/Persistance-tp20732003p20743522.html
  Sent from the Tapestry - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
  For additional commands, e-mail:

Re: Persistance

2008-12-12 Thread Daniel Jue

In the past I manually implemented this behavior by mixing server side and
client side persistence.  My code-fu was probably not very elegant.

In my case, a user could open a report page after filling out a page of
variables.  These report pages would open in a new browser window/tab. So
instantly you have the situation where two reports can be open but use
different data.  I would store a client side string on each report page, and
LRU hash map on the ASO side would match it to the relative data, just
before the report was run and a new page opened.  If it was in the LRU, I
could grab the cached report.  If not, I still had enough information to run
the report again.  If the report page needed to be refreshed (such as
sorting something on the page, non-async), the client side key would look up
the data.

I used a small LRU limit (like 5) to keep the size down.

Daniel

On Fri, Nov 28, 2008 at 10:18 PM, thermus msch...@gmail.com wrote:


 I'm interested in this as well.  Specifically if a user has two page
 instances open, how can T5 persistence be used reliably?

 I found on Safari and Firefox (not sure about IE, but likely a problem
 there
 as well) that the persisted session properties are shared between page
 instances and each page can overwrite the another.  My searches didn't come
 up with a definitive answer although I did see that the question has been
 asked several times.  Can anyone comment on this or provide a workaround?



 Peter Stavrinides wrote:
 
  ... but what would be ideal in my humble view is a proper page
 persistence
  Strategy, where a value is retained until the user leaves the page. In
  truth someone posted such a solution which used a cookie, and it seemed
 to
  behave exactly as it should, nevertheless I am still against relying on a
  cookie. I understand this may be difficult to implement due to Tapestry's
  inner workings, particularly the way pages are pooled, but since
  conversational state covers some of this ground (the difference being a
  conversation is tied to not only the page, but the window so each tab is
  treated as a new conversation)...
 

 --
 View this message in context:
 http://www.nabble.com/Persistance-tp20732003p20743522.html
 Sent from the Tapestry - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Persistance

2008-12-11 Thread Hugo Palma

I myself have found the need for such a persistence strategy.
I would suggest creating an issue for this so that people can vote and
follow it.

On Fri, Nov 28, 2008 at 10:23 AM, Peter Stavrinides 
[EMAIL PROTECTED] wrote:

 Hi,

 I have been thinking about persistence lately... and after moving all our
 apps from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct
 patterns emerge in the way pages fit together and use persistence, and I
 have been searching all the while for best practices... here are some
 comments on how persistence evolved in my code:

 @Persist - I tended to use it a lot in the beginning, but far less now, I
 have found it optimal not to clutter the session, and therefore persist only
 a select few fields (mostly primitives).

 @Persist(flash) - I moved to flash persistence wherever I could, as it
 helps limit the number of queries required, but its not always feasible to
 use. On the odd occasion I also ran into problems with render methods when
 pages were complex.

 I now use mostly onActivate and onPassivate, this has proven to be the most
 reliable pattern, and the most scalable. It does require a bit more
 boilerplate code for checking that URL parameters are passed correctly,
 particularly for pages that have 'optional parameters'... the one downside
 is that I have a few more queries now.

 So whats missing in an ideal world? A read in a post some time ago that
 conversational patterns may be added in 5.1, that would be great! but what
 would be ideal in my humble view is a proper page persistence Strategy,
 where a value is retained until the user leaves the page. In truth someone
 posted such a solution which used a cookie, and it seemed to behave exactly
 as it should, nevertheless I am still against relying on a cookie. I
 understand this may be difficult to implement due to Tapestry's inner
 workings, particularly the way pages are pooled, but since conversational
 state covers some of this ground (the difference being a conversation is
 tied to not only the page, but the window so each tab is treated as a new
 conversation), I thought to at least to ask if it could be considered at
 some point if at all feasible. I would also love to hear other peoples
 thoughts/opinions on this.

 cheers,
 Peter




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Persistance

2008-12-11 Thread Peter Stavrinides

I think this feature would set Tapestry 5 even further apart from the rest, go 
vote for it at:
https://issues.apache.org/jira/browse/TAP5-411

cheers,
Peter

- Original Message -
From: Hugo Palma [EMAIL PROTECTED]
To: Tapestry users users@tapestry.apache.org
Sent: Thursday, 11 December, 2008 12:52:37 PM GMT +02:00 Athens, Beirut, 
Bucharest, Istanbul
Subject: Re: Persistance

I myself have found the need for such a persistence strategy.
I would suggest creating an issue for this so that people can vote and
follow it.

On Fri, Nov 28, 2008 at 10:23 AM, Peter Stavrinides 
[EMAIL PROTECTED] wrote:

 Hi,

 I have been thinking about persistence lately... and after moving all our
 apps from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct
 patterns emerge in the way pages fit together and use persistence, and I
 have been searching all the while for best practices... here are some
 comments on how persistence evolved in my code:

 @Persist - I tended to use it a lot in the beginning, but far less now, I
 have found it optimal not to clutter the session, and therefore persist only
 a select few fields (mostly primitives).

 @Persist(flash) - I moved to flash persistence wherever I could, as it
 helps limit the number of queries required, but its not always feasible to
 use. On the odd occasion I also ran into problems with render methods when
 pages were complex.

 I now use mostly onActivate and onPassivate, this has proven to be the most
 reliable pattern, and the most scalable. It does require a bit more
 boilerplate code for checking that URL parameters are passed correctly,
 particularly for pages that have 'optional parameters'... the one downside
 is that I have a few more queries now.

 So whats missing in an ideal world? A read in a post some time ago that
 conversational patterns may be added in 5.1, that would be great! but what
 would be ideal in my humble view is a proper page persistence Strategy,
 where a value is retained until the user leaves the page. In truth someone
 posted such a solution which used a cookie, and it seemed to behave exactly
 as it should, nevertheless I am still against relying on a cookie. I
 understand this may be difficult to implement due to Tapestry's inner
 workings, particularly the way pages are pooled, but since conversational
 state covers some of this ground (the difference being a conversation is
 tied to not only the page, but the window so each tab is treated as a new
 conversation), I thought to at least to ask if it could be considered at
 some point if at all feasible. I would also love to hear other peoples
 thoughts/opinions on this.

 cheers,
 Peter

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Persistance

2008-11-29 Thread Marcelo Lotif

I think this is very interesting too, and I have implemented something like
this in a menu component I've made, but the solution is specific to my case.

This persistence strategy would be a nice improvement, and would solve some
problems we had with the session size.

On Fri, Nov 28, 2008 at 7:23 AM, Peter Stavrinides 
[EMAIL PROTECTED] wrote:

 Hi,

 I have been thinking about persistence lately... and after moving all our
 apps from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct
 patterns emerge in the way pages fit together and use persistence, and I
 have been searching all the while for best practices... here are some
 comments on how persistence evolved in my code:

 @Persist - I tended to use it a lot in the beginning, but far less now, I
 have found it optimal not to clutter the session, and therefore persist only
 a select few fields (mostly primitives).

 @Persist(flash) - I moved to flash persistence wherever I could, as it
 helps limit the number of queries required, but its not always feasible to
 use. On the odd occasion I also ran into problems with render methods when
 pages were complex.

 I now use mostly onActivate and onPassivate, this has proven to be the most
 reliable pattern, and the most scalable. It does require a bit more
 boilerplate code for checking that URL parameters are passed correctly,
 particularly for pages that have 'optional parameters'... the one downside
 is that I have a few more queries now.

 So whats missing in an ideal world? A read in a post some time ago that
 conversational patterns may be added in 5.1, that would be great! but what
 would be ideal in my humble view is a proper page persistence Strategy,
 where a value is retained until the user leaves the page. In truth someone
 posted such a solution which used a cookie, and it seemed to behave exactly
 as it should, nevertheless I am still against relying on a cookie. I
 understand this may be difficult to implement due to Tapestry's inner
 workings, particularly the way pages are pooled, but since conversational
 state covers some of this ground (the difference being a conversation is
 tied to not only the page, but the window so each tab is treated as a new
 conversation), I thought to at least to ask if it could be considered at
 some point if at all feasible. I would also love to hear other peoples
 thoughts/opinions on this.

 cheers,
 Peter




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
Atenciosamente,

Marcelo Lotif
Programador Java e Tapestry
FIEC - Federação das Indústrias do Estado do Ceará
(85) 3477-5910

Re: Persistance

2008-11-29 Thread Patrick Moore

Hi 

Yeah in our T4 app we don't use @Persist at all and we really control the
session-size ... we have been setting up to open source this code that
handles the session issues.

I have been wanting to get the code in better shape before releasing back to
the community ... but it is good enough. .. I just submitted the project to
sourceforge for consideration. I have to wait a few days for approval.

Patrick Moore
Amplafi
http://amplafi.com
650-207-9792
copy/paste
blog : http://www.sworddance.com/blog


On Sat, Nov 29, 2008 at 6:19 AM, Marcelo Lotif [EMAIL PROTECTED] wrote:

 I think this is very interesting too, and I have implemented something like
 this in a menu component I've made, but the solution is specific to my
 case.

 This persistence strategy would be a nice improvement, and would solve some
 problems we had with the session size.

 On Fri, Nov 28, 2008 at 7:23 AM, Peter Stavrinides 
 [EMAIL PROTECTED] wrote:

  Hi,
 
  I have been thinking about persistence lately... and after moving all our
  apps from Tapestry 4 to Tapestry 5 this past year, I have noticed
 distinct
  patterns emerge in the way pages fit together and use persistence, and I
  have been searching all the while for best practices... here are some
  comments on how persistence evolved in my code:
 
  @Persist - I tended to use it a lot in the beginning, but far less now, I
  have found it optimal not to clutter the session, and therefore persist
 only
  a select few fields (mostly primitives).
 
  @Persist(flash) - I moved to flash persistence wherever I could, as it
  helps limit the number of queries required, but its not always feasible
 to
  use. On the odd occasion I also ran into problems with render methods
 when
  pages were complex.
 
  I now use mostly onActivate and onPassivate, this has proven to be the
 most
  reliable pattern, and the most scalable. It does require a bit more
  boilerplate code for checking that URL parameters are passed correctly,
  particularly for pages that have 'optional parameters'... the one
 downside
  is that I have a few more queries now.
 
  So whats missing in an ideal world? A read in a post some time ago that
  conversational patterns may be added in 5.1, that would be great! but
 what
  would be ideal in my humble view is a proper page persistence Strategy,
  where a value is retained until the user leaves the page. In truth
 someone
  posted such a solution which used a cookie, and it seemed to behave
 exactly
  as it should, nevertheless I am still against relying on a cookie. I
  understand this may be difficult to implement due to Tapestry's inner
  workings, particularly the way pages are pooled, but since conversational
  state covers some of this ground (the difference being a conversation is
  tied to not only the page, but the window so each tab is treated as a new
  conversation), I thought to at least to ask if it could be considered at
  some point if at all feasible. I would also love to hear other peoples
  thoughts/opinions on this.
 
  cheers,
  Peter
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Atenciosamente,

 Marcelo Lotif
 Programador Java e Tapestry
 FIEC - Federação das Indústrias do Estado do Ceará
 (85) 3477-5910

Re: Persistance

2008-11-28 Thread thermus


I'm interested in this as well.  Specifically if a user has two page
instances open, how can T5 persistence be used reliably?

I found on Safari and Firefox (not sure about IE, but likely a problem there
as well) that the persisted session properties are shared between page
instances and each page can overwrite the another.  My searches didn't come
up with a definitive answer although I did see that the question has been
asked several times.  Can anyone comment on this or provide a workaround?



Peter Stavrinides wrote:
 
 ... but what would be ideal in my humble view is a proper page persistence
 Strategy, where a value is retained until the user leaves the page. In
 truth someone posted such a solution which used a cookie, and it seemed to
 behave exactly as it should, nevertheless I am still against relying on a
 cookie. I understand this may be difficult to implement due to Tapestry's
 inner workings, particularly the way pages are pooled, but since
 conversational state covers some of this ground (the difference being a
 conversation is tied to not only the page, but the window so each tab is
 treated as a new conversation)...
 

-- 
View this message in context: 
http://www.nabble.com/Persistance-tp20732003p20743522.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

Re: Persistance

14 matches

Site Navigation

Mail list logo

Footer information