T5: Persistence pains

[Joel Wiegman <Jo...@dswinc.com>]

All,

Maybe I'm missing something here, maybe I'm not, but I'm attempting to
preserve state JUST BETWEEN REQUESTS and I'm really struggling (I know
in T5 there's <really> two requests, but for simplicity's sake let's
just call the round trip from the browser a "request").

My options are:

1) @Persist("session")
- Obviously doesn't work well for just persisting values between
requests, unless someone has come up with a reliable construct for
nulling out these values whenever someone leaves the page?

2) @Persist("flash")
- This is really only useful for messages and other objects that are
reliably referenced once.  This is NOT "request-scoped persistence".

3) @Persist("client")
- While I thought initially thought that this would solve all my woes,
instead every link in my application now carries around an huge encoded
state variable in the URL.  I'm completely missing the benefit of this
versus just using session persistence (enlightenment appreciated).

4) Activation context magic
- While this does make for clean and nifty URLs, the hassle of
constructing the identifiers for complex objects and creating the
contexts for them has not proven "worth it" to me (hint: composite
primary keys are almost unusable).  Also, if your page uses more than
one dynamically-sized collection of objects, then you're out of luck.

PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry has
been a delight to work with compared to previous frameworks I've used.
I'm just really struggling with how to do something that, IMHO, a web
framework should make very simple (request-scoped persistence).

Anyone solve this riddle yet?

Joel


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

Re: T5: Persistence pains

[Josh Canfield <jo...@thedailytube.com>]

Hi Joel,

First,
> PLEASE PLEASE don't interpret this as Tapestry-bashing.

Yikes, hopefully the troll-bashing hasn't made people afraid to ask
tough questions for fear of being labeled troll.

Anyway, back you your question. So, when you render a page you want
some state that was used to render that page to be available the next
time you render the page. You don't want that state hanging around in
the session if the user leaves that page?

> 3) @Persist("client")
> - While I thought initially thought that this would solve all my woes,
> instead every link in my application now carries around an huge encoded
> state variable in the URL.  I'm completely missing the benefit of this
> versus just using session persistence (enlightenment appreciated).

@Persist("client") is better than @Persist("session") when you're
either unable or choosing to not use sessions. It also prevents you
from having to deal with expired sessions. If the user goes away and
comes back an hour later, the page should still work.

> 4) Activation context magic ... (hint: composite
> primary keys are almost unusable).

Can you be more specific about your trouble with composite keys?

> Also, if your page uses more than
> one dynamically-sized collection of objects, then you're out of luck.

I've used markers for cases where I was stowing different types of
context in the url.
http://localhost/m1/one/two/m2/hello/world

Somewhere there is code floating around for cookie based persistence.
That gets it onto the client without putting it in the url. If you're
concerned about the same session being opened in two browsers, there
is also an implementation of "conversation" in the latest jumpstart
that you could take a look at...

Of course, these are tied to page and component. If you want a cookie
based Application State Object that you can pass between pages, I
think you'll have to write that one up.

If you really want to make sure that you aren't using data intended
for a different instance of the page, you could tie the object in the
cookie to an activation context value. If they don't match assume that
you're in a wonky state and clear it out.

Josh

On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com> wrote:
> All,
>
> Maybe I'm missing something here, maybe I'm not, but I'm attempting to
> preserve state JUST BETWEEN REQUESTS and I'm really struggling (I know
> in T5 there's <really> two requests, but for simplicity's sake let's
> just call the round trip from the browser a "request").
>
> My options are:
>
> 1) @Persist("session")
> - Obviously doesn't work well for just persisting values between
> requests, unless someone has come up with a reliable construct for
> nulling out these values whenever someone leaves the page?
>
> 2) @Persist("flash")
> - This is really only useful for messages and other objects that are
> reliably referenced once.  This is NOT "request-scoped persistence".
>
> 3) @Persist("client")
> - While I thought initially thought that this would solve all my woes,
> instead every link in my application now carries around an huge encoded
> state variable in the URL.  I'm completely missing the benefit of this
> versus just using session persistence (enlightenment appreciated).
>
> 4) Activation context magic
> - While this does make for clean and nifty URLs, the hassle of
> constructing the identifiers for complex objects and creating the
> contexts for them has not proven "worth it" to me (hint: composite
> primary keys are almost unusable).  Also, if your page uses more than
> one dynamically-sized collection of objects, then you're out of luck.
>
> PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry has
> been a delight to work with compared to previous frameworks I've used.
> I'm just really struggling with how to do something that, IMHO, a web
> framework should make very simple (request-scoped persistence).
>
> Anyone solve this riddle yet?
>
> Joel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

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

Re: T5: Persistence pains

[Tomasz Dziurko <td...@gmail.com>]

I am not sure if this is what you need, but I had problem similar to
yours and solved it this way:

You wrote:
1) @Persist("session")
- Obviously doesn't work well for just persisting values between
requests, unless someone has come up with a reliable construct for
nulling out these values whenever someone leaves the page?

I have page registerUser, where I want user to have clear fields every
time he enters the page. All fields are market @Persist

@Persist
private String name;

@Persist
private String surname;

// etc...

To solve clearing both fields values and error messages on each page
exit I use method cleanupRender() where I put clearErrors() and
discardPersistentFieldChanges().

@Inject
private ComponentResources componentResources;

void cleanupRender() {
    componentResources.discardPersistentFieldChanges();
    registerForm.clearErrors();
}

// discardPersistentFieldChanges() from T5 api:
Discards all persistent field changes for the page containing the
component. Changes are eliminated from persistent storage (such as the
Session) which will take effect in the next request (the attached page
instance is not affected).

Regards
-- 
Tomasz Dziurko

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

Re: T5: Persistence pains

[Howard Lewis Ship <hl...@gmail.com>]

No, I get that there's an issue here ... I think conversational scope
would be helpful.  In addition, we need more smarts about what gets
stored persistently, something like ValueEncoder but for persisted
values; simple values (String, int, etc.) are find, but we need to
recognize complex objects, such as Hibernate entities, and store just
the entity id in the session, or as client-side data.

On Mon, May 5, 2008 at 6:02 AM, Joel Wiegman <Jo...@dswinc.com> wrote:
> Howard,
>
>  I totally get the "two request" pattern.  A user shouldn't have to
>  decide whether to re-submit their information.  Great feature of the
>  framework.
>
>  So let's say that the "request scope" I'm referring to would be "browser
>  round-trip scope".  As people on the forum have pointed out,
>  combinations of the back button, refreshing, spawning new browser
>  instances (which share session information) all can create chaos for any
>  session-interacting web application.
>
>  Just seems strange that seasoned web developers who use Tapestry are
>  "baking their own" persistence mechanisms.  Some are even making
>  protocol-ish marker-based activation context constructs
>  (/editdoohickeys/d1/keyval1/keyval2/d2/keyval1/keyval2).
>
>  Sounds like what most of us are requesting is to at least permit the
>  developer to not have to persist their components in the session
>  (something like ServletRequest.setAttribute/getAttribute instead).
>
>  Now that I've thoroughly beaten it, I'll just let the dead horse
>  decompose for a while until it starts to smell (no Eight Belles
>  reference intended).
>
>  Joel
>
>
>
>  -----Original Message-----
>  From: Howard Lewis Ship [mailto:hlship@gmail.com]
>
>
> Sent: Saturday, May 03, 2008 5:38 PM
>  To: Tapestry users
>  Subject: Re: T5: Persistence pains
>
>  On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <Jo...@dswinc.com>
>  wrote:
>  > Josh,
>  >
>  >  Thanks for the great suggestions.
>  >
>  >  I guess I'm still befuddled as to why a web framework would resist
>  having a "request scope" so dilligently.
>
>  It's not resistance, it's a different mindset, one that states that URLs
>  should stand on their own in the browser and represent data to be
>  presented to the user (i.e., render page requests) rather than behaviors
>  to execute (the action requests).
>
>  From what you describe, your activate event handler method should be
>  able to load whatever additional data is needed and store it in simple
>  component fields: that's your request scope.  The fact that Tapestry
>  links action requests to page requests is a separate issue.
>
>  The goal is that if the user clicks the refresh button (the other
>  annoying thing users do, besides hit the browser back button) that there
>  won't be unexpected side-effects (such as, for instance, re-submitting
>  an order, re-sending an email, etc., etc.).
>
>  >
>  >  The "flash" scope appears to makes some intelligent guesses as to
>  when you want your objects removed from the session, but the
>  back-button-example I listed is one of quite a few reasons why making
>  such guesses is a fools game.  As we all know, HTTP is a
>  request-response, stateless protocol, but Tapestry appears to be
>  resisting storing state in one of the most basic constructs available in
>  HTTP... the request.  Anyone know why this is?
>
>  Because we can store it inside ordinary fields instead?
>
>  >
>  >  As you illustrated, I'm sure there are quite a few elaborate ways of
>  dancing around the issue in any application (redundant checking,
>  re-verification, passing "clearThisValue" flags around, etc.).  None
>  seem very elegant though (and would probably be associated with "this is
>  why I'm doing this" comments).
>  >
>  >  As for your activation context suggestions, those are some neat
>  ideas.  I hadn't considered your "marking" suggestion.   I'm a little
>  afraid to use it though.  I can see a Tapestry pattern evolving from
>  that that yields (String... stuff) as your parameter to your onActivate
>  with a boatload of extravagant logic.
>  >
>  >  Anyway, still haven't heard a useful suggestion to get objects into a
>  "request only" scope.  If anyone can think of something please post!
>
>  It would be interesting to see what some of these values are that can
>  only be set inside an action request but must then span into a render
>  request.
>
>  >
>  >  Thanks,
>  >
>  >  Joel
>  >
>  >
>  >
>  >
>  >  -----Original Message-----
>  >  From: joshcanfield@gmail.com on behalf of Josh Canfield
>  >  Sent: Fri 5/2/2008 6:31 PM
>  >  To: Tapestry users
>  >  Subject: Re: T5: Persistence pains
>  >
>  >  I generally consider flash persistence as a way to get an object from
>
>  > the action request to the render request...
>  >
>  >  If you're going to set it in the render request you should consider
>  > adding code that validates that your data and context match up. You
>  > could, for instance, also flash persist your id and check it against
>  > the id from the context. If they don't match then null your other
>  > properties.
>  >
>  >  > While some may argue that this is "just poor design", what if the
>  > fields  > I initialize varies by product?  I'd get a "merging" of the
>  > two products  > on the screen depending on what was persisted first.
>  >
>  >  Storing these things in your component smells funny... but I don't
>  > know your app. If someone is coming to the page for the first time you
>
>  > want an empty object, if they are posting an update to the form then
>  > Tapestry is going to populate the values. If you are navigating within
>
>  > the page using pagelinks, but it's a form then I'd consider posting
>  > the form instead...
>  >
>  >  Josh
>  >
>  >  On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com>
>  wrote:
>  >  > Sure Howard.
>  >  >
>  >  > Quite simply, "the back button".  When loading a page with an
>  > activation  > context, say:
>  >  >
>  >  > http://myapp.com/editproduct/20  (where 20 is a product ID)  >  >
>  > I'll initialize some flash-persistable values on the page from the  >
>  > Product whose ID is 20.
>  >  >
>  >  > Now if the user clicks on the Back button and goes to a link that
>  > reuses  > the same screen but without a context, say:
>  >  >
>  >  > http://myapp.com/editproduct/ (let's say this page "should" blank
>  > out  > the screen so the user can enter a new product)  >  > Most of
>  > my flash-persistable values (from Product 20) will still be on  > the
>  > screen.
>  >  >
>  >  > While some may argue that this is "just poor design", what if the
>  > fields  > I initialize varies by product?  I'd get a "merging" of the
>  > two products  > on the screen depending on what was persisted first.
>  >  >
>  >  > Are these scenarios valid?
>  >  >
>  >  >
>  >  >
>  >  > -----Original Message-----
>  >  > From: Howard Lewis Ship [mailto:hlship@gmail.com]  > Sent: Friday,
>  > May 02, 2008 5:17 PM  > To: Tapestry users  > Subject: Re: T5:
>  > Persistence pains  >  > Could you elaborate on why the "flash"
>  > persistence strategy is  > insufficient for your needs?
>  >  >
>  >  > On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman
>  > <Jo...@dswinc.com>  > wrote:
>  >  > > All,
>  >  > >
>  >  > >  Maybe I'm missing something here, maybe I'm not, but I'm
>  > attempting  > > to  preserve state JUST BETWEEN REQUESTS and I'm
>  > really struggling (I  > > know  in T5 there's <really> two requests,
>  > but for simplicity's sake  > > let's  just call the round trip from
>  the browser a "request").
>  >  > >
>  >  > >  My options are:
>  >  > >
>  >  > >  1) @Persist("session")
>  >  > >  - Obviously doesn't work well for just persisting values between
>
>  > > > requests, unless someone has come up with a reliable construct for
>
>  > > > nulling out these values whenever someone leaves the page?
>  >  > >
>  >  > >  2) @Persist("flash")
>  >  > >  - This is really only useful for messages and other objects that
>
>  > are  >  > > reliably referenced once.  This is NOT "request-scoped
>  > persistence".
>  >  > >
>  >  > >  3) @Persist("client")
>  >  > >  - While I thought initially thought that this would solve all my
>
>  > > > woes,  instead every link in my application now carries around an
>  > huge  >  > > encoded  state variable in the URL.  I'm completely
>  > missing the  > > benefit of this  versus just using session
>  > persistence (enlightenment  > appreciated).
>  >  > >
>  >  > >  4) Activation context magic
>  >  > >  - While this does make for clean and nifty URLs, the hassle of
>  > > > constructing the identifiers for complex objects and creating the
>
>  > > > contexts for them has not proven "worth it" to me (hint: composite
>
>  > > > primary keys are almost unusable).  Also, if your page uses more
>  > than  >  > > one dynamically-sized collection of objects, then you're
>  > out of luck.
>  >  > >
>  >  > >  PLEASE PLEASE don't interpret this as Tapestry-bashing.
>  > Tapestry has  >  > > been a delight to work with compared to previous
>  > frameworks I've used.
>  >  > >  I'm just really struggling with how to do something that, IMHO,
>  > a web  >  > > framework should make very simple (request-scoped
>  > persistence).
>  >  > >
>  >  > >  Anyone solve this riddle yet?
>  >  > >
>  >  > >  Joel
>  >  > >
>  >  > >
>  >  > >
>  > ---------------------------------------------------------------------
>  >  > >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  >  > >  For additional commands, e-mail: users-help@tapestry.apache.org
>
>  > > >  > >  >  >  >  > --  > Howard M. Lewis Ship  >  > Creator Apache
>  > Tapestry and Apache HiveMind  >  >
>  > ---------------------------------------------------------------------
>  >  > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  >  > For additional commands, e-mail: users-help@tapestry.apache.org  >
>
>  > >  >
>  > ---------------------------------------------------------------------
>  >  > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  >  > For additional commands, e-mail: users-help@tapestry.apache.org  >
>
>  > >
>  >
>  >
>  >
>  >  --
>  >  --
>  >  TheDailyTube.com. Sign up and get the best new videos on the internet
>
>  > delivered fresh to your inbox.
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  >  For additional commands, e-mail: users-help@tapestry.apache.org
>  >
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  >  For additional commands, e-mail: users-help@tapestry.apache.org
>  >
>
>
>
>  --
>  Howard M. Lewis Ship
>
>  Creator Apache Tapestry and Apache HiveMind
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

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

RE: T5: Persistence pains

[Joel Wiegman <Jo...@dswinc.com>]

Howard,

I totally get the "two request" pattern.  A user shouldn't have to
decide whether to re-submit their information.  Great feature of the
framework.

So let's say that the "request scope" I'm referring to would be "browser
round-trip scope".  As people on the forum have pointed out,
combinations of the back button, refreshing, spawning new browser
instances (which share session information) all can create chaos for any
session-interacting web application.

Just seems strange that seasoned web developers who use Tapestry are
"baking their own" persistence mechanisms.  Some are even making
protocol-ish marker-based activation context constructs
(/editdoohickeys/d1/keyval1/keyval2/d2/keyval1/keyval2).

Sounds like what most of us are requesting is to at least permit the
developer to not have to persist their components in the session
(something like ServletRequest.setAttribute/getAttribute instead).

Now that I've thoroughly beaten it, I'll just let the dead horse
decompose for a while until it starts to smell (no Eight Belles
reference intended).

Joel


-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com] 
Sent: Saturday, May 03, 2008 5:38 PM
To: Tapestry users
Subject: Re: T5: Persistence pains

On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <Jo...@dswinc.com>
wrote:
> Josh,
>
>  Thanks for the great suggestions.
>
>  I guess I'm still befuddled as to why a web framework would resist
having a "request scope" so dilligently.

It's not resistance, it's a different mindset, one that states that URLs
should stand on their own in the browser and represent data to be
presented to the user (i.e., render page requests) rather than behaviors
to execute (the action requests).

>From what you describe, your activate event handler method should be
able to load whatever additional data is needed and store it in simple
component fields: that's your request scope.  The fact that Tapestry
links action requests to page requests is a separate issue.

The goal is that if the user clicks the refresh button (the other
annoying thing users do, besides hit the browser back button) that there
won't be unexpected side-effects (such as, for instance, re-submitting
an order, re-sending an email, etc., etc.).

>
>  The "flash" scope appears to makes some intelligent guesses as to
when you want your objects removed from the session, but the
back-button-example I listed is one of quite a few reasons why making
such guesses is a fools game.  As we all know, HTTP is a
request-response, stateless protocol, but Tapestry appears to be
resisting storing state in one of the most basic constructs available in
HTTP... the request.  Anyone know why this is?

Because we can store it inside ordinary fields instead?

>
>  As you illustrated, I'm sure there are quite a few elaborate ways of
dancing around the issue in any application (redundant checking,
re-verification, passing "clearThisValue" flags around, etc.).  None
seem very elegant though (and would probably be associated with "this is
why I'm doing this" comments).
>
>  As for your activation context suggestions, those are some neat
ideas.  I hadn't considered your "marking" suggestion.   I'm a little
afraid to use it though.  I can see a Tapestry pattern evolving from
that that yields (String... stuff) as your parameter to your onActivate
with a boatload of extravagant logic.
>
>  Anyway, still haven't heard a useful suggestion to get objects into a
"request only" scope.  If anyone can think of something please post!

It would be interesting to see what some of these values are that can
only be set inside an action request but must then span into a render
request.

>
>  Thanks,
>
>  Joel
>
>
>
>
>  -----Original Message-----
>  From: joshcanfield@gmail.com on behalf of Josh Canfield
>  Sent: Fri 5/2/2008 6:31 PM
>  To: Tapestry users
>  Subject: Re: T5: Persistence pains
>
>  I generally consider flash persistence as a way to get an object from

> the action request to the render request...
>
>  If you're going to set it in the render request you should consider  
> adding code that validates that your data and context match up. You  
> could, for instance, also flash persist your id and check it against  
> the id from the context. If they don't match then null your other  
> properties.
>
>  > While some may argue that this is "just poor design", what if the 
> fields  > I initialize varies by product?  I'd get a "merging" of the 
> two products  > on the screen depending on what was persisted first.
>
>  Storing these things in your component smells funny... but I don't  
> know your app. If someone is coming to the page for the first time you

> want an empty object, if they are posting an update to the form then  
> Tapestry is going to populate the values. If you are navigating within

> the page using pagelinks, but it's a form then I'd consider posting  
> the form instead...
>
>  Josh
>
>  On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com>
wrote:
>  > Sure Howard.
>  >
>  > Quite simply, "the back button".  When loading a page with an 
> activation  > context, say:
>  >
>  > http://myapp.com/editproduct/20  (where 20 is a product ID)  >  > 
> I'll initialize some flash-persistable values on the page from the  > 
> Product whose ID is 20.
>  >
>  > Now if the user clicks on the Back button and goes to a link that 
> reuses  > the same screen but without a context, say:
>  >
>  > http://myapp.com/editproduct/ (let's say this page "should" blank 
> out  > the screen so the user can enter a new product)  >  > Most of 
> my flash-persistable values (from Product 20) will still be on  > the 
> screen.
>  >
>  > While some may argue that this is "just poor design", what if the 
> fields  > I initialize varies by product?  I'd get a "merging" of the 
> two products  > on the screen depending on what was persisted first.
>  >
>  > Are these scenarios valid?
>  >
>  >
>  >
>  > -----Original Message-----
>  > From: Howard Lewis Ship [mailto:hlship@gmail.com]  > Sent: Friday, 
> May 02, 2008 5:17 PM  > To: Tapestry users  > Subject: Re: T5: 
> Persistence pains  >  > Could you elaborate on why the "flash" 
> persistence strategy is  > insufficient for your needs?
>  >
>  > On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman 
> <Jo...@dswinc.com>  > wrote:
>  > > All,
>  > >
>  > >  Maybe I'm missing something here, maybe I'm not, but I'm 
> attempting  > > to  preserve state JUST BETWEEN REQUESTS and I'm 
> really struggling (I  > > know  in T5 there's <really> two requests, 
> but for simplicity's sake  > > let's  just call the round trip from
the browser a "request").
>  > >
>  > >  My options are:
>  > >
>  > >  1) @Persist("session")
>  > >  - Obviously doesn't work well for just persisting values between

> > > requests, unless someone has come up with a reliable construct for

> > > nulling out these values whenever someone leaves the page?
>  > >
>  > >  2) @Persist("flash")
>  > >  - This is really only useful for messages and other objects that

> are  >  > > reliably referenced once.  This is NOT "request-scoped 
> persistence".
>  > >
>  > >  3) @Persist("client")
>  > >  - While I thought initially thought that this would solve all my

> > > woes,  instead every link in my application now carries around an 
> huge  >  > > encoded  state variable in the URL.  I'm completely 
> missing the  > > benefit of this  versus just using session 
> persistence (enlightenment  > appreciated).
>  > >
>  > >  4) Activation context magic
>  > >  - While this does make for clean and nifty URLs, the hassle of  
> > > constructing the identifiers for complex objects and creating the

> > > contexts for them has not proven "worth it" to me (hint: composite

> > > primary keys are almost unusable).  Also, if your page uses more 
> than  >  > > one dynamically-sized collection of objects, then you're 
> out of luck.
>  > >
>  > >  PLEASE PLEASE don't interpret this as Tapestry-bashing.  
> Tapestry has  >  > > been a delight to work with compared to previous 
> frameworks I've used.
>  > >  I'm just really struggling with how to do something that, IMHO, 
> a web  >  > > framework should make very simple (request-scoped 
> persistence).
>  > >
>  > >  Anyone solve this riddle yet?
>  > >
>  > >  Joel
>  > >
>  > >
>  > >  
> ---------------------------------------------------------------------
>  > >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  > >  For additional commands, e-mail: users-help@tapestry.apache.org

> > >  > >  >  >  >  > --  > Howard M. Lewis Ship  >  > Creator Apache 
> Tapestry and Apache HiveMind  >  > 
> ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  > For additional commands, e-mail: users-help@tapestry.apache.org  >

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

> >
>
>
>
>  --
>  --
>  TheDailyTube.com. Sign up and get the best new videos on the internet

> delivered fresh to your inbox.
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>



--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

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


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

Re: T5: Persistence pains

[Ivan Dubrov <wf...@gmail.com>]

Kalle Korhonen wrote:
> Hey Ivan,
>
> When you say "we", who are you referring to? 
I mean my company.

> In my mind, this flow aka
> conversation support is absolutely the right solution for the problem. Are
> you planning to share the code or include it with some other project?
>   

Unfortunately, I can't.

> Various implementations of the conversation concept exists, but I'd gladly
> take a look at yours as I agree that embedding the flow key to the url is
> the best way to get support for multiple windows working correctly.
>   
It was modeled after the Spring Webflow. The same idea --- URL contains 
a key, which is used to get the data from the store. Every request 
generates new key.
> Kalle
>
> On Sat, May 3, 2008 at 11:03 PM, Ivan Dubrov <wf...@gmail.com> wrote:
>
>   
>> Right. Most annoying things for us about "session" and "flash" scopes was
>> that they don't work in several tabs. And "client" can't hold too much data.
>>
>> That's why we have implemented a new persistence strategy named "flow"
>> (inspired by the Spring WebFlow). The idea is that every URL has flow key
>> stored in it, and the state is stored in the session under this key. The
>> state is versioned (actually, the state is immutable, every change to the
>> persistent fields introduces new state). We keep about 10 previous states,
>> to keep the session from overburdening.
>>
>> There is still some issues with AJAX calls, though.
>>
>>
>>  The biggest argument to be made for "request scope" state that is
>>     
>>> automatically (or framework assisted developer code) persisted in the page
>>> vs. the "flash" technique of Tapestry is when considering multiple browsers
>>> opened by the user with the same session. Every app that I've developed,
>>> we've had to diligently ensure that nothing other than "login" credentials
>>> were stored in the session and everything was persisted within the request.
>>> For T3, our team developed an elaborate set of components that made this
>>> trivial (including our own annotations based support). The fact that Tap 5
>>> gets in the way of trying to have a very light session is a little
>>> disconcerting. The other side-effect of "flash" would be thrashing in a
>>> clustered environment.
>>>
>>> ----- Original Message ----- From: "Howard Lewis Ship" <hlship@gmail.com
>>>       
>>> To: "Tapestry users" <us...@tapestry.apache.org>
>>> Sent: Saturday, May 03, 2008 5:37 PM
>>> Subject: Re: T5: Persistence pains
>>>
>>>
>>>  On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <Jo...@dswinc.com>
>>>       
>>>> wrote:
>>>>
>>>>         
>>>>> Josh,
>>>>>
>>>>> Thanks for the great suggestions.
>>>>>
>>>>> I guess I'm still befuddled as to why a web framework would resist
>>>>> having a "request scope" so dilligently.
>>>>>
>>>>>           
>>>> It's not resistance, it's a different mindset, one that states that
>>>> URLs should stand on their own in the browser and represent data to be
>>>> presented to the user (i.e., render page requests) rather than
>>>> behaviors to execute (the action requests).
>>>>
>>>> From what you describe, your activate event handler method should be
>>>> able to load whatever additional data is needed and store it in simple
>>>> component fields: that's your request scope. The fact that Tapestry
>>>> links action requests to page requests is a separate issue.
>>>>
>>>> The goal is that if the user clicks the refresh button (the other
>>>> annoying thing users do, besides hit the browser back button) that
>>>> there won't be unexpected side-effects (such as, for instance,
>>>> re-submitting an order, re-sending an email, etc., etc.).
>>>>
>>>>
>>>>         
>>>>> The "flash" scope appears to makes some intelligent guesses as to
>>>>> when you want your objects removed from the session, but the
>>>>> back-button-example I listed is one of quite a few reasons why making such
>>>>> guesses is a fools game. As we all know, HTTP is a request-response,
>>>>> stateless protocol, but Tapestry appears to be resisting storing state in
>>>>> one of the most basic constructs available in HTTP... the request. Anyone
>>>>> know why this is?
>>>>>
>>>>>           
>>>> Because we can store it inside ordinary fields instead?
>>>>
>>>>
>>>>         
>>>>> As you illustrated, I'm sure there are quite a few elaborate ways of
>>>>> dancing around the issue in any application (redundant checking,
>>>>> re-verification, passing "clearThisValue" flags around, etc.). None seem
>>>>> very elegant though (and would probably be associated with "this is why I'm
>>>>> doing this" comments).
>>>>>
>>>>> As for your activation context suggestions, those are some neat
>>>>> ideas. I hadn't considered your "marking" suggestion. I'm a little afraid to
>>>>> use it though. I can see a Tapestry pattern evolving from that that yields
>>>>> (String... stuff) as your parameter to your onActivate with a boatload of
>>>>> extravagant logic.
>>>>>
>>>>> Anyway, still haven't heard a useful suggestion to get objects into
>>>>> a "request only" scope. If anyone can think of something please post!
>>>>>
>>>>>           
>>>> It would be interesting to see what some of these values are that can
>>>> only be set inside an action request but must then span into a render
>>>> request.
>>>>
>>>>
>>>>         
>>>>> Thanks,
>>>>>
>>>>> Joel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: joshcanfield@gmail.com on behalf of Josh Canfield
>>>>> Sent: Fri 5/2/2008 6:31 PM
>>>>> To: Tapestry users
>>>>> Subject: Re: T5: Persistence pains
>>>>>
>>>>> I generally consider flash persistence as a way to get an object
>>>>> from
>>>>> the action request to the render request...
>>>>>
>>>>> If you're going to set it in the render request you should consider
>>>>> adding code that validates that your data and context match up. You
>>>>> could, for instance, also flash persist your id and check it against
>>>>> the id from the context. If they don't match then null your other
>>>>> properties.
>>>>>
>>>>>           
>>>>>> While some may argue that this is "just poor design", what if the
>>>>>>             
>>>>> fields
>>>>>           
>>>>>> I initialize varies by product? I'd get a "merging" of the two
>>>>>>             
>>>>> products
>>>>>           
>>>>>> on the screen depending on what was persisted first.
>>>>>>             
>>>>> Storing these things in your component smells funny... but I don't
>>>>> know your app. If someone is coming to the page for the first time
>>>>> you
>>>>> want an empty object, if they are posting an update to the form then
>>>>> Tapestry is going to populate the values. If you are navigating
>>>>> within
>>>>> the page using pagelinks, but it's a form then I'd consider posting
>>>>> the form instead...
>>>>>
>>>>> Josh
>>>>>
>>>>> On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com>
>>>>> wrote:
>>>>>           
>>>>>> Sure Howard.
>>>>>>
>>>>>> Quite simply, "the back button". When loading a page with an
>>>>>>             
>>>>> activation
>>>>>           
>>>>>> context, say:
>>>>>>
>>>>>> http://myapp.com/editproduct/20 (where 20 is a product ID)
>>>>>>
>>>>>> I'll initialize some flash-persistable values on the page from the
>>>>>> Product whose ID is 20.
>>>>>>
>>>>>> Now if the user clicks on the Back button and goes to a link that
>>>>>>             
>>>>> reuses
>>>>>           
>>>>>> the same screen but without a context, say:
>>>>>>
>>>>>> http://myapp.com/editproduct/ (let's say this page "should" blank
>>>>>>             
>>>>> out
>>>>>           
>>>>>> the screen so the user can enter a new product)
>>>>>>
>>>>>> Most of my flash-persistable values (from Product 20) will still
>>>>>>             
>>>>> be on
>>>>>           
>>>>>> the screen.
>>>>>>
>>>>>> While some may argue that this is "just poor design", what if the
>>>>>>             
>>>>> fields
>>>>>           
>>>>>> I initialize varies by product? I'd get a "merging" of the two
>>>>>>             
>>>>> products
>>>>>           
>>>>>> on the screen depending on what was persisted first.
>>>>>>
>>>>>> Are these scenarios valid?
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Howard Lewis Ship [mailto:hlship@gmail.com]
>>>>>> Sent: Friday, May 02, 2008 5:17 PM
>>>>>> To: Tapestry users
>>>>>> Subject: Re: T5: Persistence pains
>>>>>>
>>>>>> Could you elaborate on why the "flash" persistence strategy is
>>>>>> insufficient for your needs?
>>>>>>
>>>>>> On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <
>>>>>>             
>>>>> JoelWiegman@dswinc.com>
>>>>>           
>>>>>> wrote:
>>>>>>             
>>>>>>> All,
>>>>>>>
>>>>>>> Maybe I'm missing something here, maybe I'm not, but I'm
>>>>>>>               
>>>>> attempting
>>>>>           
>>>>>>> to preserve state JUST BETWEEN REQUESTS and I'm really
>>>>>>>               
>>>>> struggling (I
>>>>>           
>>>>>>> know in T5 there's <really> two requests, but for simplicity's
>>>>>>>               
>>>>> sake
>>>>>           
>>>>>>> let's just call the round trip from the browser a "request").
>>>>>>>
>>>>>>> My options are:
>>>>>>>
>>>>>>> 1) @Persist("session")
>>>>>>> - Obviously doesn't work well for just persisting values between
>>>>>>> requests, unless someone has come up with a reliable construct
>>>>>>>               
>>>>> for
>>>>>           
>>>>>>> nulling out these values whenever someone leaves the page?
>>>>>>>
>>>>>>> 2) @Persist("flash")
>>>>>>> - This is really only useful for messages and other objects that
>>>>>>>               
>>>>> are
>>>>>           
>>>>>>> reliably referenced once. This is NOT "request-scoped
>>>>>>>               
>>>>> persistence".
>>>>>           
>>>>>>> 3) @Persist("client")
>>>>>>> - While I thought initially thought that this would solve all my
>>>>>>> woes, instead every link in my application now carries around an
>>>>>>>               
>>>>> huge
>>>>>           
>>>>>>> encoded state variable in the URL. I'm completely missing the
>>>>>>> benefit of this versus just using session persistence
>>>>>>>               
>>>>> (enlightenment
>>>>>           
>>>>>> appreciated).
>>>>>>             
>>>>>>> 4) Activation context magic
>>>>>>> - While this does make for clean and nifty URLs, the hassle of
>>>>>>> constructing the identifiers for complex objects and creating
>>>>>>>               
>>>>> the
>>>>>           
>>>>>>> contexts for them has not proven "worth it" to me (hint:
>>>>>>>               
>>>>> composite
>>>>>           
>>>>>>> primary keys are almost unusable). Also, if your page uses more
>>>>>>>               
>>>>> than
>>>>>           
>>>>>>> one dynamically-sized collection of objects, then you're out of
>>>>>>>               
>>>>> luck.
>>>>>           
>>>>>>> PLEASE PLEASE don't interpret this as Tapestry-bashing. Tapestry
>>>>>>>               
>>>>> has
>>>>>           
>>>>>>> been a delight to work with compared to previous frameworks I've
>>>>>>>               
>>>>> used.
>>>>>           
>>>>>>> I'm just really struggling with how to do something that, IMHO,
>>>>>>>               
>>>>> a web
>>>>>           
>>>>>>> framework should make very simple (request-scoped persistence).
>>>>>>>
>>>>>>> Anyone solve this riddle yet?
>>>>>>>
>>>>>>> Joel
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>> ---------------------------------------------------------------------
>>>>>           
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>
>>>>>> --
>>>>>> Howard M. Lewis Ship
>>>>>>
>>>>>> Creator Apache Tapestry and Apache HiveMind
>>>>>>
>>>>>>
>>>>>>             
>>>>> ---------------------------------------------------------------------
>>>>>           
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> ---------------------------------------------------------------------
>>>>>           
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>             
>>>>>
>>>>> --
>>>>> --
>>>>> TheDailyTube.com. Sign up and get the best new videos on the
>>>>> internet
>>>>> delivered fresh to your inbox.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>           
>>>> --
>>>> Howard M. Lewis Ship
>>>>
>>>> Creator Apache Tapestry and Apache HiveMind
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>       
>> --
>> WBR,
>> Ivan S. Dubrov
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>     
>
>   


-- 
WBR,
Ivan S. Dubrov

Re: T5: Persistence pains

[Kalle Korhonen <ka...@gmail.com>]

Hey Ivan,

When you say "we", who are you referring to? In my mind, this flow aka
conversation support is absolutely the right solution for the problem. Are
you planning to share the code or include it with some other project?
Various implementations of the conversation concept exists, but I'd gladly
take a look at yours as I agree that embedding the flow key to the url is
the best way to get support for multiple windows working correctly.

Kalle

On Sat, May 3, 2008 at 11:03 PM, Ivan Dubrov <wf...@gmail.com> wrote:

>
> Right. Most annoying things for us about "session" and "flash" scopes was
> that they don't work in several tabs. And "client" can't hold too much data.
>
> That's why we have implemented a new persistence strategy named "flow"
> (inspired by the Spring WebFlow). The idea is that every URL has flow key
> stored in it, and the state is stored in the session under this key. The
> state is versioned (actually, the state is immutable, every change to the
> persistent fields introduces new state). We keep about 10 previous states,
> to keep the session from overburdening.
>
> There is still some issues with AJAX calls, though.
>
>
>  The biggest argument to be made for "request scope" state that is
> > automatically (or framework assisted developer code) persisted in the page
> > vs. the "flash" technique of Tapestry is when considering multiple browsers
> > opened by the user with the same session. Every app that I've developed,
> > we've had to diligently ensure that nothing other than "login" credentials
> > were stored in the session and everything was persisted within the request.
> > For T3, our team developed an elaborate set of components that made this
> > trivial (including our own annotations based support). The fact that Tap 5
> > gets in the way of trying to have a very light session is a little
> > disconcerting. The other side-effect of "flash" would be thrashing in a
> > clustered environment.
> >
> > ----- Original Message ----- From: "Howard Lewis Ship" <hlship@gmail.com
> > >
> > To: "Tapestry users" <us...@tapestry.apache.org>
> > Sent: Saturday, May 03, 2008 5:37 PM
> > Subject: Re: T5: Persistence pains
> >
> >
> >  On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <Jo...@dswinc.com>
> > > wrote:
> > >
> > > > Josh,
> > > >
> > > > Thanks for the great suggestions.
> > > >
> > > > I guess I'm still befuddled as to why a web framework would resist
> > > > having a "request scope" so dilligently.
> > > >
> > >
> > > It's not resistance, it's a different mindset, one that states that
> > > URLs should stand on their own in the browser and represent data to be
> > > presented to the user (i.e., render page requests) rather than
> > > behaviors to execute (the action requests).
> > >
> > > From what you describe, your activate event handler method should be
> > > able to load whatever additional data is needed and store it in simple
> > > component fields: that's your request scope. The fact that Tapestry
> > > links action requests to page requests is a separate issue.
> > >
> > > The goal is that if the user clicks the refresh button (the other
> > > annoying thing users do, besides hit the browser back button) that
> > > there won't be unexpected side-effects (such as, for instance,
> > > re-submitting an order, re-sending an email, etc., etc.).
> > >
> > >
> > > > The "flash" scope appears to makes some intelligent guesses as to
> > > > when you want your objects removed from the session, but the
> > > > back-button-example I listed is one of quite a few reasons why making such
> > > > guesses is a fools game. As we all know, HTTP is a request-response,
> > > > stateless protocol, but Tapestry appears to be resisting storing state in
> > > > one of the most basic constructs available in HTTP... the request. Anyone
> > > > know why this is?
> > > >
> > >
> > > Because we can store it inside ordinary fields instead?
> > >
> > >
> > > > As you illustrated, I'm sure there are quite a few elaborate ways of
> > > > dancing around the issue in any application (redundant checking,
> > > > re-verification, passing "clearThisValue" flags around, etc.). None seem
> > > > very elegant though (and would probably be associated with "this is why I'm
> > > > doing this" comments).
> > > >
> > > > As for your activation context suggestions, those are some neat
> > > > ideas. I hadn't considered your "marking" suggestion. I'm a little afraid to
> > > > use it though. I can see a Tapestry pattern evolving from that that yields
> > > > (String... stuff) as your parameter to your onActivate with a boatload of
> > > > extravagant logic.
> > > >
> > > > Anyway, still haven't heard a useful suggestion to get objects into
> > > > a "request only" scope. If anyone can think of something please post!
> > > >
> > >
> > > It would be interesting to see what some of these values are that can
> > > only be set inside an action request but must then span into a render
> > > request.
> > >
> > >
> > > > Thanks,
> > > >
> > > > Joel
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: joshcanfield@gmail.com on behalf of Josh Canfield
> > > > Sent: Fri 5/2/2008 6:31 PM
> > > > To: Tapestry users
> > > > Subject: Re: T5: Persistence pains
> > > >
> > > > I generally consider flash persistence as a way to get an object
> > > > from
> > > > the action request to the render request...
> > > >
> > > > If you're going to set it in the render request you should consider
> > > > adding code that validates that your data and context match up. You
> > > > could, for instance, also flash persist your id and check it against
> > > > the id from the context. If they don't match then null your other
> > > > properties.
> > > >
> > > > > While some may argue that this is "just poor design", what if the
> > > > fields
> > > > > I initialize varies by product? I'd get a "merging" of the two
> > > > products
> > > > > on the screen depending on what was persisted first.
> > > >
> > > > Storing these things in your component smells funny... but I don't
> > > > know your app. If someone is coming to the page for the first time
> > > > you
> > > > want an empty object, if they are posting an update to the form then
> > > > Tapestry is going to populate the values. If you are navigating
> > > > within
> > > > the page using pagelinks, but it's a form then I'd consider posting
> > > > the form instead...
> > > >
> > > > Josh
> > > >
> > > > On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com>
> > > > wrote:
> > > > > Sure Howard.
> > > > >
> > > > > Quite simply, "the back button". When loading a page with an
> > > > activation
> > > > > context, say:
> > > > >
> > > > > http://myapp.com/editproduct/20 (where 20 is a product ID)
> > > > >
> > > > > I'll initialize some flash-persistable values on the page from the
> > > > > Product whose ID is 20.
> > > > >
> > > > > Now if the user clicks on the Back button and goes to a link that
> > > > reuses
> > > > > the same screen but without a context, say:
> > > > >
> > > > > http://myapp.com/editproduct/ (let's say this page "should" blank
> > > > out
> > > > > the screen so the user can enter a new product)
> > > > >
> > > > > Most of my flash-persistable values (from Product 20) will still
> > > > be on
> > > > > the screen.
> > > > >
> > > > > While some may argue that this is "just poor design", what if the
> > > > fields
> > > > > I initialize varies by product? I'd get a "merging" of the two
> > > > products
> > > > > on the screen depending on what was persisted first.
> > > > >
> > > > > Are these scenarios valid?
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Howard Lewis Ship [mailto:hlship@gmail.com]
> > > > > Sent: Friday, May 02, 2008 5:17 PM
> > > > > To: Tapestry users
> > > > > Subject: Re: T5: Persistence pains
> > > > >
> > > > > Could you elaborate on why the "flash" persistence strategy is
> > > > > insufficient for your needs?
> > > > >
> > > > > On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <
> > > > JoelWiegman@dswinc.com>
> > > > > wrote:
> > > > > > All,
> > > > > >
> > > > > > Maybe I'm missing something here, maybe I'm not, but I'm
> > > > attempting
> > > > > > to preserve state JUST BETWEEN REQUESTS and I'm really
> > > > struggling (I
> > > > > > know in T5 there's <really> two requests, but for simplicity's
> > > > sake
> > > > > > let's just call the round trip from the browser a "request").
> > > > > >
> > > > > > My options are:
> > > > > >
> > > > > > 1) @Persist("session")
> > > > > > - Obviously doesn't work well for just persisting values between
> > > > > > requests, unless someone has come up with a reliable construct
> > > > for
> > > > > > nulling out these values whenever someone leaves the page?
> > > > > >
> > > > > > 2) @Persist("flash")
> > > > > > - This is really only useful for messages and other objects that
> > > > are
> > > > >
> > > > > > reliably referenced once. This is NOT "request-scoped
> > > > persistence".
> > > > > >
> > > > > > 3) @Persist("client")
> > > > > > - While I thought initially thought that this would solve all my
> > > > > > woes, instead every link in my application now carries around an
> > > > huge
> > > > >
> > > > > > encoded state variable in the URL. I'm completely missing the
> > > > > > benefit of this versus just using session persistence
> > > > (enlightenment
> > > > > appreciated).
> > > > > >
> > > > > > 4) Activation context magic
> > > > > > - While this does make for clean and nifty URLs, the hassle of
> > > > > > constructing the identifiers for complex objects and creating
> > > > the
> > > > > > contexts for them has not proven "worth it" to me (hint:
> > > > composite
> > > > > > primary keys are almost unusable). Also, if your page uses more
> > > > than
> > > > >
> > > > > > one dynamically-sized collection of objects, then you're out of
> > > > luck.
> > > > > >
> > > > > > PLEASE PLEASE don't interpret this as Tapestry-bashing. Tapestry
> > > > has
> > > > >
> > > > > > been a delight to work with compared to previous frameworks I've
> > > > used.
> > > > > > I'm just really struggling with how to do something that, IMHO,
> > > > a web
> > > > >
> > > > > > framework should make very simple (request-scoped persistence).
> > > > > >
> > > > > > Anyone solve this riddle yet?
> > > > > >
> > > > > > Joel
> > > > > >
> > > > > >
> > > > >
> > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Howard M. Lewis Ship
> > > > >
> > > > > Creator Apache Tapestry and Apache HiveMind
> > > > >
> > > > >
> > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > > >
> > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > --
> > > > TheDailyTube.com. Sign up and get the best new videos on the
> > > > internet
> > > > delivered fresh to your inbox.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > >
> > > Creator Apache Tapestry and Apache HiveMind
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> WBR,
> Ivan S. Dubrov
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: T5: Persistence pains

[kranga <kr...@k2d2.org>]

We use a serialization strategy that zips the serialized form and base64 
encodes it. We're yet to see a performance issue with the solution. The 
issue with persisting each field in separate parameter is obviously that of 
the number of such fields you are able to persist.

----- Original Message ----- 
From: "Dmitry Shyshkin" <sh...@devoler.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Monday, May 05, 2008 4:48 AM
Subject: Re: T5: Persistence pains


> The problem in "client" strategy that it used Serializable mechanism of 
> jvm. Of cause it produce a lot of data (not getting in mind that most 
> domain objects are not Serializable). I use own persistent strategy called 
> 'parameter'. It is similar to "client" with follow exceptions.
>
>    *  It uses ValueEncoder to convert from Object to String and from
>      String to Object. It save a lot of space, because for domain
>      object only it id is persistent, which is rarely longer than 6
>      characters.
>    * It persist each field in separate parameters (when "client"
>      persist all data in parameter t:ac) . In this way it is similar to
>      activation context's friendly url behavior. User see somethings
>      like this http://somewhere.com/page?user=123&order=12&item=5
>
> With help of this strategy I persist data between request to the same 
> page. It solves both: problem with multiple browser tabs and problem with 
> too many persistent fields in session.
>
> Ivan Dubrov wrote:
>>
>> Right. Most annoying things for us about “session” and “flash” scopes was 
>> that they don’t work in several tabs. And “client” can’t hold too much 
>> data.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 


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

Re: T5: Persistence pains

[Dmitry Shyshkin <sh...@devoler.com>]

The problem in "client" strategy that it used Serializable mechanism of 
jvm. Of cause it produce a lot of data (not getting in mind that most 
domain objects are not Serializable). I use own persistent strategy 
called  'parameter'. It is similar to "client" with follow exceptions.

    *  It uses ValueEncoder to convert from Object to String and from
      String to Object. It save a lot of space, because for domain
      object only it id is persistent, which is rarely longer than 6
      characters.
    * It persist each field in separate parameters (when "client"
      persist all data in parameter t:ac) . In this way it is similar to
      activation context's friendly url behavior. User see somethings
      like this http://somewhere.com/page?user=123&order=12&item=5

With help of this strategy I persist data between request to the same 
page. It solves both: problem with multiple browser tabs and problem 
with too many persistent fields in session.

Ivan Dubrov wrote:
>
> Right. Most annoying things for us about “session” and “flash” scopes 
> was that they don’t work in several tabs. And “client” can’t hold too 
> much data.
>


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

Re: T5: Persistence pains

[Thiago HP <th...@gmail.com>]

On Sun, May 4, 2008 at 3:03 AM, Ivan Dubrov <wf...@gmail.com> wrote:

>  Right. Most annoying things for us about "session" and "flash" scopes was
> that they don't work in several tabs. And "client" can't hold too much data.

Maybe you're having an issue with the statelessness of HTTP, not with
Tapestry itself.

-- 
Thiago

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

Re: T5: Persistence pains

[Ivan Dubrov <wf...@gmail.com>]

Right. Most annoying things for us about “session” and “flash” scopes 
was that they don’t work in several tabs. And “client” can’t hold too 
much data.

That’s why we have implemented a new persistence strategy named “flow” 
(inspired by the Spring WebFlow). The idea is that every URL has flow 
key stored in it, and the state is stored in the session under this key. 
The state is versioned (actually, the state is immutable, every change 
to the persistent fields introduces new state). We keep about 10 
previous states, to keep the session from overburdening.

There is still some issues with AJAX calls, though.

> The biggest argument to be made for "request scope" state that is 
> automatically (or framework assisted developer code) persisted in the 
> page vs. the "flash" technique of Tapestry is when considering 
> multiple browsers opened by the user with the same session. Every app 
> that I've developed, we've had to diligently ensure that nothing other 
> than "login" credentials were stored in the session and everything was 
> persisted within the request. For T3, our team developed an elaborate 
> set of components that made this trivial (including our own 
> annotations based support). The fact that Tap 5 gets in the way of 
> trying to have a very light session is a little disconcerting. The 
> other side-effect of "flash" would be thrashing in a clustered 
> environment.
>
> ----- Original Message ----- From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry users" <us...@tapestry.apache.org>
> Sent: Saturday, May 03, 2008 5:37 PM
> Subject: Re: T5: Persistence pains
>
>
>> On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <Jo...@dswinc.com> 
>> wrote:
>>> Josh,
>>>
>>> Thanks for the great suggestions.
>>>
>>> I guess I'm still befuddled as to why a web framework would resist 
>>> having a "request scope" so dilligently.
>>
>> It's not resistance, it's a different mindset, one that states that
>> URLs should stand on their own in the browser and represent data to be
>> presented to the user (i.e., render page requests) rather than
>> behaviors to execute (the action requests).
>>
>> From what you describe, your activate event handler method should be
>> able to load whatever additional data is needed and store it in simple
>> component fields: that's your request scope. The fact that Tapestry
>> links action requests to page requests is a separate issue.
>>
>> The goal is that if the user clicks the refresh button (the other
>> annoying thing users do, besides hit the browser back button) that
>> there won't be unexpected side-effects (such as, for instance,
>> re-submitting an order, re-sending an email, etc., etc.).
>>
>>>
>>> The "flash" scope appears to makes some intelligent guesses as to 
>>> when you want your objects removed from the session, but the 
>>> back-button-example I listed is one of quite a few reasons why 
>>> making such guesses is a fools game. As we all know, HTTP is a 
>>> request-response, stateless protocol, but Tapestry appears to be 
>>> resisting storing state in one of the most basic constructs 
>>> available in HTTP... the request. Anyone know why this is?
>>
>> Because we can store it inside ordinary fields instead?
>>
>>>
>>> As you illustrated, I'm sure there are quite a few elaborate ways of 
>>> dancing around the issue in any application (redundant checking, 
>>> re-verification, passing "clearThisValue" flags around, etc.). None 
>>> seem very elegant though (and would probably be associated with 
>>> "this is why I'm doing this" comments).
>>>
>>> As for your activation context suggestions, those are some neat 
>>> ideas. I hadn't considered your "marking" suggestion. I'm a little 
>>> afraid to use it though. I can see a Tapestry pattern evolving from 
>>> that that yields (String... stuff) as your parameter to your 
>>> onActivate with a boatload of extravagant logic.
>>>
>>> Anyway, still haven't heard a useful suggestion to get objects into 
>>> a "request only" scope. If anyone can think of something please post!
>>
>> It would be interesting to see what some of these values are that can
>> only be set inside an action request but must then span into a render
>> request.
>>
>>>
>>> Thanks,
>>>
>>> Joel
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: joshcanfield@gmail.com on behalf of Josh Canfield
>>> Sent: Fri 5/2/2008 6:31 PM
>>> To: Tapestry users
>>> Subject: Re: T5: Persistence pains
>>>
>>> I generally consider flash persistence as a way to get an object from
>>> the action request to the render request...
>>>
>>> If you're going to set it in the render request you should consider
>>> adding code that validates that your data and context match up. You
>>> could, for instance, also flash persist your id and check it against
>>> the id from the context. If they don't match then null your other
>>> properties.
>>>
>>> > While some may argue that this is "just poor design", what if the 
>>> fields
>>> > I initialize varies by product? I'd get a "merging" of the two 
>>> products
>>> > on the screen depending on what was persisted first.
>>>
>>> Storing these things in your component smells funny... but I don't
>>> know your app. If someone is coming to the page for the first time you
>>> want an empty object, if they are posting an update to the form then
>>> Tapestry is going to populate the values. If you are navigating within
>>> the page using pagelinks, but it's a form then I'd consider posting
>>> the form instead...
>>>
>>> Josh
>>>
>>> On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman 
>>> <Jo...@dswinc.com> wrote:
>>> > Sure Howard.
>>> >
>>> > Quite simply, "the back button". When loading a page with an 
>>> activation
>>> > context, say:
>>> >
>>> > http://myapp.com/editproduct/20 (where 20 is a product ID)
>>> >
>>> > I'll initialize some flash-persistable values on the page from the
>>> > Product whose ID is 20.
>>> >
>>> > Now if the user clicks on the Back button and goes to a link that 
>>> reuses
>>> > the same screen but without a context, say:
>>> >
>>> > http://myapp.com/editproduct/ (let's say this page "should" blank out
>>> > the screen so the user can enter a new product)
>>> >
>>> > Most of my flash-persistable values (from Product 20) will still 
>>> be on
>>> > the screen.
>>> >
>>> > While some may argue that this is "just poor design", what if the 
>>> fields
>>> > I initialize varies by product? I'd get a "merging" of the two 
>>> products
>>> > on the screen depending on what was persisted first.
>>> >
>>> > Are these scenarios valid?
>>> >
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Howard Lewis Ship [mailto:hlship@gmail.com]
>>> > Sent: Friday, May 02, 2008 5:17 PM
>>> > To: Tapestry users
>>> > Subject: Re: T5: Persistence pains
>>> >
>>> > Could you elaborate on why the "flash" persistence strategy is
>>> > insufficient for your needs?
>>> >
>>> > On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com>
>>> > wrote:
>>> > > All,
>>> > >
>>> > > Maybe I'm missing something here, maybe I'm not, but I'm attempting
>>> > > to preserve state JUST BETWEEN REQUESTS and I'm really 
>>> struggling (I
>>> > > know in T5 there's <really> two requests, but for simplicity's sake
>>> > > let's just call the round trip from the browser a "request").
>>> > >
>>> > > My options are:
>>> > >
>>> > > 1) @Persist("session")
>>> > > - Obviously doesn't work well for just persisting values between
>>> > > requests, unless someone has come up with a reliable construct for
>>> > > nulling out these values whenever someone leaves the page?
>>> > >
>>> > > 2) @Persist("flash")
>>> > > - This is really only useful for messages and other objects that 
>>> are
>>> >
>>> > > reliably referenced once. This is NOT "request-scoped persistence".
>>> > >
>>> > > 3) @Persist("client")
>>> > > - While I thought initially thought that this would solve all my
>>> > > woes, instead every link in my application now carries around an 
>>> huge
>>> >
>>> > > encoded state variable in the URL. I'm completely missing the
>>> > > benefit of this versus just using session persistence 
>>> (enlightenment
>>> > appreciated).
>>> > >
>>> > > 4) Activation context magic
>>> > > - While this does make for clean and nifty URLs, the hassle of
>>> > > constructing the identifiers for complex objects and creating the
>>> > > contexts for them has not proven "worth it" to me (hint: composite
>>> > > primary keys are almost unusable). Also, if your page uses more 
>>> than
>>> >
>>> > > one dynamically-sized collection of objects, then you're out of 
>>> luck.
>>> > >
>>> > > PLEASE PLEASE don't interpret this as Tapestry-bashing. Tapestry 
>>> has
>>> >
>>> > > been a delight to work with compared to previous frameworks I've 
>>> used.
>>> > > I'm just really struggling with how to do something that, IMHO, 
>>> a web
>>> >
>>> > > framework should make very simple (request-scoped persistence).
>>> > >
>>> > > Anyone solve this riddle yet?
>>> > >
>>> > > Joel
>>> > >
>>> > >
>>> > ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Howard M. Lewis Ship
>>> >
>>> > Creator Apache Tapestry and Apache HiveMind
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> > For additional commands, e-mail: users-help@tapestry.apache.org
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> > For additional commands, e-mail: users-help@tapestry.apache.org
>>> >
>>> >
>>>
>>>
>>>
>>> -- 
>>> -- 
>>> TheDailyTube.com. Sign up and get the best new videos on the internet
>>> delivered fresh to your inbox.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>>
>> -- 
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
WBR,
Ivan S. Dubrov


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

Re: T5: Persistence pains

[kranga <kr...@k2d2.org>]

The biggest argument to be made for "request scope" state that is 
automatically (or framework assisted developer code) persisted in the page 
vs. the "flash" technique of Tapestry is when considering multiple browsers 
opened by the user with the same session. Every app that I've developed, 
we've had to diligently ensure that nothing other than "login" credentials 
were stored in the session and everything was persisted within the request. 
For T3, our team developed an elaborate set of components that made this 
trivial (including our own annotations based support). The fact that Tap 5 
gets in the way of trying to have a very light session is a little 
disconcerting. The other side-effect of "flash" would be thrashing in a 
clustered environment.

----- Original Message ----- 
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Saturday, May 03, 2008 5:37 PM
Subject: Re: T5: Persistence pains


> On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <Jo...@dswinc.com> 
> wrote:
>> Josh,
>>
>>  Thanks for the great suggestions.
>>
>>  I guess I'm still befuddled as to why a web framework would resist 
>> having a "request scope" so dilligently.
>
> It's not resistance, it's a different mindset, one that states that
> URLs should stand on their own in the browser and represent data to be
> presented to the user (i.e., render page requests) rather than
> behaviors to execute (the action requests).
>
> From what you describe, your activate event handler method should be
> able to load whatever additional data is needed and store it in simple
> component fields: that's your request scope.  The fact that Tapestry
> links action requests to page requests is a separate issue.
>
> The goal is that if the user clicks the refresh button (the other
> annoying thing users do, besides hit the browser back button) that
> there won't be unexpected side-effects (such as, for instance,
> re-submitting an order, re-sending an email, etc., etc.).
>
>>
>>  The "flash" scope appears to makes some intelligent guesses as to when 
>> you want your objects removed from the session, but the 
>> back-button-example I listed is one of quite a few reasons why making 
>> such guesses is a fools game.  As we all know, HTTP is a 
>> request-response, stateless protocol, but Tapestry appears to be 
>> resisting storing state in one of the most basic constructs available in 
>> HTTP... the request.  Anyone know why this is?
>
> Because we can store it inside ordinary fields instead?
>
>>
>>  As you illustrated, I'm sure there are quite a few elaborate ways of 
>> dancing around the issue in any application (redundant checking, 
>> re-verification, passing "clearThisValue" flags around, etc.).  None seem 
>> very elegant though (and would probably be associated with "this is why 
>> I'm doing this" comments).
>>
>>  As for your activation context suggestions, those are some neat ideas. 
>> I hadn't considered your "marking" suggestion.   I'm a little afraid to 
>> use it though.  I can see a Tapestry pattern evolving from that that 
>> yields (String... stuff) as your parameter to your onActivate with a 
>> boatload of extravagant logic.
>>
>>  Anyway, still haven't heard a useful suggestion to get objects into a 
>> "request only" scope.  If anyone can think of something please post!
>
> It would be interesting to see what some of these values are that can
> only be set inside an action request but must then span into a render
> request.
>
>>
>>  Thanks,
>>
>>  Joel
>>
>>
>>
>>
>>  -----Original Message-----
>>  From: joshcanfield@gmail.com on behalf of Josh Canfield
>>  Sent: Fri 5/2/2008 6:31 PM
>>  To: Tapestry users
>>  Subject: Re: T5: Persistence pains
>>
>>  I generally consider flash persistence as a way to get an object from
>>  the action request to the render request...
>>
>>  If you're going to set it in the render request you should consider
>>  adding code that validates that your data and context match up. You
>>  could, for instance, also flash persist your id and check it against
>>  the id from the context. If they don't match then null your other
>>  properties.
>>
>>  > While some may argue that this is "just poor design", what if the 
>> fields
>>  > I initialize varies by product?  I'd get a "merging" of the two 
>> products
>>  > on the screen depending on what was persisted first.
>>
>>  Storing these things in your component smells funny... but I don't
>>  know your app. If someone is coming to the page for the first time you
>>  want an empty object, if they are posting an update to the form then
>>  Tapestry is going to populate the values. If you are navigating within
>>  the page using pagelinks, but it's a form then I'd consider posting
>>  the form instead...
>>
>>  Josh
>>
>>  On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com> 
>> wrote:
>>  > Sure Howard.
>>  >
>>  > Quite simply, "the back button".  When loading a page with an 
>> activation
>>  > context, say:
>>  >
>>  > http://myapp.com/editproduct/20  (where 20 is a product ID)
>>  >
>>  > I'll initialize some flash-persistable values on the page from the
>>  > Product whose ID is 20.
>>  >
>>  > Now if the user clicks on the Back button and goes to a link that 
>> reuses
>>  > the same screen but without a context, say:
>>  >
>>  > http://myapp.com/editproduct/ (let's say this page "should" blank out
>>  > the screen so the user can enter a new product)
>>  >
>>  > Most of my flash-persistable values (from Product 20) will still be on
>>  > the screen.
>>  >
>>  > While some may argue that this is "just poor design", what if the 
>> fields
>>  > I initialize varies by product?  I'd get a "merging" of the two 
>> products
>>  > on the screen depending on what was persisted first.
>>  >
>>  > Are these scenarios valid?
>>  >
>>  >
>>  >
>>  > -----Original Message-----
>>  > From: Howard Lewis Ship [mailto:hlship@gmail.com]
>>  > Sent: Friday, May 02, 2008 5:17 PM
>>  > To: Tapestry users
>>  > Subject: Re: T5: Persistence pains
>>  >
>>  > Could you elaborate on why the "flash" persistence strategy is
>>  > insufficient for your needs?
>>  >
>>  > On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com>
>>  > wrote:
>>  > > All,
>>  > >
>>  > >  Maybe I'm missing something here, maybe I'm not, but I'm attempting
>>  > > to  preserve state JUST BETWEEN REQUESTS and I'm really struggling 
>> (I
>>  > > know  in T5 there's <really> two requests, but for simplicity's sake
>>  > > let's  just call the round trip from the browser a "request").
>>  > >
>>  > >  My options are:
>>  > >
>>  > >  1) @Persist("session")
>>  > >  - Obviously doesn't work well for just persisting values between
>>  > > requests, unless someone has come up with a reliable construct for
>>  > > nulling out these values whenever someone leaves the page?
>>  > >
>>  > >  2) @Persist("flash")
>>  > >  - This is really only useful for messages and other objects that 
>> are
>>  >
>>  > > reliably referenced once.  This is NOT "request-scoped persistence".
>>  > >
>>  > >  3) @Persist("client")
>>  > >  - While I thought initially thought that this would solve all my
>>  > > woes,  instead every link in my application now carries around an 
>> huge
>>  >
>>  > > encoded  state variable in the URL.  I'm completely missing the
>>  > > benefit of this  versus just using session persistence 
>> (enlightenment
>>  > appreciated).
>>  > >
>>  > >  4) Activation context magic
>>  > >  - While this does make for clean and nifty URLs, the hassle of
>>  > > constructing the identifiers for complex objects and creating the
>>  > > contexts for them has not proven "worth it" to me (hint: composite
>>  > > primary keys are almost unusable).  Also, if your page uses more 
>> than
>>  >
>>  > > one dynamically-sized collection of objects, then you're out of 
>> luck.
>>  > >
>>  > >  PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry 
>> has
>>  >
>>  > > been a delight to work with compared to previous frameworks I've 
>> used.
>>  > >  I'm just really struggling with how to do something that, IMHO, a 
>> web
>>  >
>>  > > framework should make very simple (request-scoped persistence).
>>  > >
>>  > >  Anyone solve this riddle yet?
>>  > >
>>  > >  Joel
>>  > >
>>  > >
>>  > 
>>   ---------------------------------------------------------------------
>>  > >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>  > >  For additional commands, e-mail: users-help@tapestry.apache.org
>>  > >
>>  > >
>>  >
>>  >
>>  >
>>  > --
>>  > Howard M. Lewis Ship
>>  >
>>  > Creator Apache Tapestry and Apache HiveMind
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>  > For additional commands, e-mail: users-help@tapestry.apache.org
>>  >
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>  > For additional commands, e-mail: users-help@tapestry.apache.org
>>  >
>>  >
>>
>>
>>
>>  --
>>  --
>>  TheDailyTube.com. Sign up and get the best new videos on the internet
>>  delivered fresh to your inbox.
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>  For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>  For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> -- 
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
> 


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

Re: T5: Persistence pains

[Howard Lewis Ship <hl...@gmail.com>]

On Fri, May 2, 2008 at 6:36 PM, Joel Wiegman <Jo...@dswinc.com> wrote:
> Josh,
>
>  Thanks for the great suggestions.
>
>  I guess I'm still befuddled as to why a web framework would resist having a "request scope" so dilligently.

It's not resistance, it's a different mindset, one that states that
URLs should stand on their own in the browser and represent data to be
presented to the user (i.e., render page requests) rather than
behaviors to execute (the action requests).

>From what you describe, your activate event handler method should be
able to load whatever additional data is needed and store it in simple
component fields: that's your request scope.  The fact that Tapestry
links action requests to page requests is a separate issue.

The goal is that if the user clicks the refresh button (the other
annoying thing users do, besides hit the browser back button) that
there won't be unexpected side-effects (such as, for instance,
re-submitting an order, re-sending an email, etc., etc.).

>
>  The "flash" scope appears to makes some intelligent guesses as to when you want your objects removed from the session, but the back-button-example I listed is one of quite a few reasons why making such guesses is a fools game.  As we all know, HTTP is a request-response, stateless protocol, but Tapestry appears to be resisting storing state in one of the most basic constructs available in HTTP... the request.  Anyone know why this is?

Because we can store it inside ordinary fields instead?

>
>  As you illustrated, I'm sure there are quite a few elaborate ways of dancing around the issue in any application (redundant checking, re-verification, passing "clearThisValue" flags around, etc.).  None seem very elegant though (and would probably be associated with "this is why I'm doing this" comments).
>
>  As for your activation context suggestions, those are some neat ideas.  I hadn't considered your "marking" suggestion.   I'm a little afraid to use it though.  I can see a Tapestry pattern evolving from that that yields (String... stuff) as your parameter to your onActivate with a boatload of extravagant logic.
>
>  Anyway, still haven't heard a useful suggestion to get objects into a "request only" scope.  If anyone can think of something please post!

It would be interesting to see what some of these values are that can
only be set inside an action request but must then span into a render
request.

>
>  Thanks,
>
>  Joel
>
>
>
>
>  -----Original Message-----
>  From: joshcanfield@gmail.com on behalf of Josh Canfield
>  Sent: Fri 5/2/2008 6:31 PM
>  To: Tapestry users
>  Subject: Re: T5: Persistence pains
>
>  I generally consider flash persistence as a way to get an object from
>  the action request to the render request...
>
>  If you're going to set it in the render request you should consider
>  adding code that validates that your data and context match up. You
>  could, for instance, also flash persist your id and check it against
>  the id from the context. If they don't match then null your other
>  properties.
>
>  > While some may argue that this is "just poor design", what if the fields
>  > I initialize varies by product?  I'd get a "merging" of the two products
>  > on the screen depending on what was persisted first.
>
>  Storing these things in your component smells funny... but I don't
>  know your app. If someone is coming to the page for the first time you
>  want an empty object, if they are posting an update to the form then
>  Tapestry is going to populate the values. If you are navigating within
>  the page using pagelinks, but it's a form then I'd consider posting
>  the form instead...
>
>  Josh
>
>  On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com> wrote:
>  > Sure Howard.
>  >
>  > Quite simply, "the back button".  When loading a page with an activation
>  > context, say:
>  >
>  > http://myapp.com/editproduct/20  (where 20 is a product ID)
>  >
>  > I'll initialize some flash-persistable values on the page from the
>  > Product whose ID is 20.
>  >
>  > Now if the user clicks on the Back button and goes to a link that reuses
>  > the same screen but without a context, say:
>  >
>  > http://myapp.com/editproduct/ (let's say this page "should" blank out
>  > the screen so the user can enter a new product)
>  >
>  > Most of my flash-persistable values (from Product 20) will still be on
>  > the screen.
>  >
>  > While some may argue that this is "just poor design", what if the fields
>  > I initialize varies by product?  I'd get a "merging" of the two products
>  > on the screen depending on what was persisted first.
>  >
>  > Are these scenarios valid?
>  >
>  >
>  >
>  > -----Original Message-----
>  > From: Howard Lewis Ship [mailto:hlship@gmail.com]
>  > Sent: Friday, May 02, 2008 5:17 PM
>  > To: Tapestry users
>  > Subject: Re: T5: Persistence pains
>  >
>  > Could you elaborate on why the "flash" persistence strategy is
>  > insufficient for your needs?
>  >
>  > On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com>
>  > wrote:
>  > > All,
>  > >
>  > >  Maybe I'm missing something here, maybe I'm not, but I'm attempting
>  > > to  preserve state JUST BETWEEN REQUESTS and I'm really struggling (I
>  > > know  in T5 there's <really> two requests, but for simplicity's sake
>  > > let's  just call the round trip from the browser a "request").
>  > >
>  > >  My options are:
>  > >
>  > >  1) @Persist("session")
>  > >  - Obviously doesn't work well for just persisting values between
>  > > requests, unless someone has come up with a reliable construct for
>  > > nulling out these values whenever someone leaves the page?
>  > >
>  > >  2) @Persist("flash")
>  > >  - This is really only useful for messages and other objects that are
>  >
>  > > reliably referenced once.  This is NOT "request-scoped persistence".
>  > >
>  > >  3) @Persist("client")
>  > >  - While I thought initially thought that this would solve all my
>  > > woes,  instead every link in my application now carries around an huge
>  >
>  > > encoded  state variable in the URL.  I'm completely missing the
>  > > benefit of this  versus just using session persistence (enlightenment
>  > appreciated).
>  > >
>  > >  4) Activation context magic
>  > >  - While this does make for clean and nifty URLs, the hassle of
>  > > constructing the identifiers for complex objects and creating the
>  > > contexts for them has not proven "worth it" to me (hint: composite
>  > > primary keys are almost unusable).  Also, if your page uses more than
>  >
>  > > one dynamically-sized collection of objects, then you're out of luck.
>  > >
>  > >  PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry has
>  >
>  > > been a delight to work with compared to previous frameworks I've used.
>  > >  I'm just really struggling with how to do something that, IMHO, a web
>  >
>  > > framework should make very simple (request-scoped persistence).
>  > >
>  > >  Anyone solve this riddle yet?
>  > >
>  > >  Joel
>  > >
>  > >
>  > >  ---------------------------------------------------------------------
>  > >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  > >  For additional commands, e-mail: users-help@tapestry.apache.org
>  > >
>  > >
>  >
>  >
>  >
>  > --
>  > Howard M. Lewis Ship
>  >
>  > Creator Apache Tapestry and Apache HiveMind
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  > For additional commands, e-mail: users-help@tapestry.apache.org
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  > For additional commands, e-mail: users-help@tapestry.apache.org
>  >
>  >
>
>
>
>  --
>  --
>  TheDailyTube.com. Sign up and get the best new videos on the internet
>  delivered fresh to your inbox.
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

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

RE: T5: Persistence pains

[Joel Wiegman <Jo...@dswinc.com>]

Josh,

Thanks for the great suggestions.

I guess I'm still befuddled as to why a web framework would resist having a "request scope" so dilligently.

The "flash" scope appears to makes some intelligent guesses as to when you want your objects removed from the session, but the back-button-example I listed is one of quite a few reasons why making such guesses is a fools game.  As we all know, HTTP is a request-response, stateless protocol, but Tapestry appears to be resisting storing state in one of the most basic constructs available in HTTP... the request.  Anyone know why this is?

As you illustrated, I'm sure there are quite a few elaborate ways of dancing around the issue in any application (redundant checking, re-verification, passing "clearThisValue" flags around, etc.).  None seem very elegant though (and would probably be associated with "this is why I'm doing this" comments).

As for your activation context suggestions, those are some neat ideas.  I hadn't considered your "marking" suggestion.   I'm a little afraid to use it though.  I can see a Tapestry pattern evolving from that that yields (String... stuff) as your parameter to your onActivate with a boatload of extravagant logic. 

Anyway, still haven't heard a useful suggestion to get objects into a "request only" scope.  If anyone can think of something please post!

Thanks,

Joel


-----Original Message-----
From: joshcanfield@gmail.com on behalf of Josh Canfield
Sent: Fri 5/2/2008 6:31 PM
To: Tapestry users
Subject: Re: T5: Persistence pains
 
I generally consider flash persistence as a way to get an object from
the action request to the render request...

If you're going to set it in the render request you should consider
adding code that validates that your data and context match up. You
could, for instance, also flash persist your id and check it against
the id from the context. If they don't match then null your other
properties.

> While some may argue that this is "just poor design", what if the fields
> I initialize varies by product?  I'd get a "merging" of the two products
> on the screen depending on what was persisted first.

Storing these things in your component smells funny... but I don't
know your app. If someone is coming to the page for the first time you
want an empty object, if they are posting an update to the form then
Tapestry is going to populate the values. If you are navigating within
the page using pagelinks, but it's a form then I'd consider posting
the form instead...

Josh

On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com> wrote:
> Sure Howard.
>
> Quite simply, "the back button".  When loading a page with an activation
> context, say:
>
> http://myapp.com/editproduct/20  (where 20 is a product ID)
>
> I'll initialize some flash-persistable values on the page from the
> Product whose ID is 20.
>
> Now if the user clicks on the Back button and goes to a link that reuses
> the same screen but without a context, say:
>
> http://myapp.com/editproduct/ (let's say this page "should" blank out
> the screen so the user can enter a new product)
>
> Most of my flash-persistable values (from Product 20) will still be on
> the screen.
>
> While some may argue that this is "just poor design", what if the fields
> I initialize varies by product?  I'd get a "merging" of the two products
> on the screen depending on what was persisted first.
>
> Are these scenarios valid?
>
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Friday, May 02, 2008 5:17 PM
> To: Tapestry users
> Subject: Re: T5: Persistence pains
>
> Could you elaborate on why the "flash" persistence strategy is
> insufficient for your needs?
>
> On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com>
> wrote:
> > All,
> >
> >  Maybe I'm missing something here, maybe I'm not, but I'm attempting
> > to  preserve state JUST BETWEEN REQUESTS and I'm really struggling (I
> > know  in T5 there's <really> two requests, but for simplicity's sake
> > let's  just call the round trip from the browser a "request").
> >
> >  My options are:
> >
> >  1) @Persist("session")
> >  - Obviously doesn't work well for just persisting values between
> > requests, unless someone has come up with a reliable construct for
> > nulling out these values whenever someone leaves the page?
> >
> >  2) @Persist("flash")
> >  - This is really only useful for messages and other objects that are
>
> > reliably referenced once.  This is NOT "request-scoped persistence".
> >
> >  3) @Persist("client")
> >  - While I thought initially thought that this would solve all my
> > woes,  instead every link in my application now carries around an huge
>
> > encoded  state variable in the URL.  I'm completely missing the
> > benefit of this  versus just using session persistence (enlightenment
> appreciated).
> >
> >  4) Activation context magic
> >  - While this does make for clean and nifty URLs, the hassle of
> > constructing the identifiers for complex objects and creating the
> > contexts for them has not proven "worth it" to me (hint: composite
> > primary keys are almost unusable).  Also, if your page uses more than
>
> > one dynamically-sized collection of objects, then you're out of luck.
> >
> >  PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry has
>
> > been a delight to work with compared to previous frameworks I've used.
> >  I'm just really struggling with how to do something that, IMHO, a web
>
> > framework should make very simple (request-scoped persistence).
> >
> >  Anyone solve this riddle yet?
> >
> >  Joel
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >  For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

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

Re: T5: Persistence pains

[Josh Canfield <jo...@thedailytube.com>]

I generally consider flash persistence as a way to get an object from
the action request to the render request...

If you're going to set it in the render request you should consider
adding code that validates that your data and context match up. You
could, for instance, also flash persist your id and check it against
the id from the context. If they don't match then null your other
properties.

> While some may argue that this is "just poor design", what if the fields
> I initialize varies by product?  I'd get a "merging" of the two products
> on the screen depending on what was persisted first.

Storing these things in your component smells funny... but I don't
know your app. If someone is coming to the page for the first time you
want an empty object, if they are posting an update to the form then
Tapestry is going to populate the values. If you are navigating within
the page using pagelinks, but it's a form then I'd consider posting
the form instead...

Josh

On Fri, May 2, 2008 at 2:39 PM, Joel Wiegman <Jo...@dswinc.com> wrote:
> Sure Howard.
>
> Quite simply, "the back button".  When loading a page with an activation
> context, say:
>
> http://myapp.com/editproduct/20  (where 20 is a product ID)
>
> I'll initialize some flash-persistable values on the page from the
> Product whose ID is 20.
>
> Now if the user clicks on the Back button and goes to a link that reuses
> the same screen but without a context, say:
>
> http://myapp.com/editproduct/ (let's say this page "should" blank out
> the screen so the user can enter a new product)
>
> Most of my flash-persistable values (from Product 20) will still be on
> the screen.
>
> While some may argue that this is "just poor design", what if the fields
> I initialize varies by product?  I'd get a "merging" of the two products
> on the screen depending on what was persisted first.
>
> Are these scenarios valid?
>
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Friday, May 02, 2008 5:17 PM
> To: Tapestry users
> Subject: Re: T5: Persistence pains
>
> Could you elaborate on why the "flash" persistence strategy is
> insufficient for your needs?
>
> On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com>
> wrote:
> > All,
> >
> >  Maybe I'm missing something here, maybe I'm not, but I'm attempting
> > to  preserve state JUST BETWEEN REQUESTS and I'm really struggling (I
> > know  in T5 there's <really> two requests, but for simplicity's sake
> > let's  just call the round trip from the browser a "request").
> >
> >  My options are:
> >
> >  1) @Persist("session")
> >  - Obviously doesn't work well for just persisting values between
> > requests, unless someone has come up with a reliable construct for
> > nulling out these values whenever someone leaves the page?
> >
> >  2) @Persist("flash")
> >  - This is really only useful for messages and other objects that are
>
> > reliably referenced once.  This is NOT "request-scoped persistence".
> >
> >  3) @Persist("client")
> >  - While I thought initially thought that this would solve all my
> > woes,  instead every link in my application now carries around an huge
>
> > encoded  state variable in the URL.  I'm completely missing the
> > benefit of this  versus just using session persistence (enlightenment
> appreciated).
> >
> >  4) Activation context magic
> >  - While this does make for clean and nifty URLs, the hassle of
> > constructing the identifiers for complex objects and creating the
> > contexts for them has not proven "worth it" to me (hint: composite
> > primary keys are almost unusable).  Also, if your page uses more than
>
> > one dynamically-sized collection of objects, then you're out of luck.
> >
> >  PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry has
>
> > been a delight to work with compared to previous frameworks I've used.
> >  I'm just really struggling with how to do something that, IMHO, a web
>
> > framework should make very simple (request-scoped persistence).
> >
> >  Anyone solve this riddle yet?
> >
> >  Joel
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >  For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

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

Re: T5: Persistence pains

[Thiago HP <th...@gmail.com>]

On 5/2/08, Joel Wiegman <Jo...@dswinc.com> wrote:

>  Quite simply, "the back button".  When loading a page with an activation
>  context, say:

I noticed what you described in it is not a problem with Tapestry (at
least most of the time), it's a browser cache or browser prefilling
forms issue. Take a look at that, looking at the generated HTML after
you hit the back button. It can be the case.

-- 
Thiago

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

RE: T5: Persistence pains

[Joel Wiegman <Jo...@dswinc.com>]

Sure Howard.

Quite simply, "the back button".  When loading a page with an activation
context, say:

http://myapp.com/editproduct/20  (where 20 is a product ID)

I'll initialize some flash-persistable values on the page from the
Product whose ID is 20.

Now if the user clicks on the Back button and goes to a link that reuses
the same screen but without a context, say:

http://myapp.com/editproduct/ (let's say this page "should" blank out
the screen so the user can enter a new product)

Most of my flash-persistable values (from Product 20) will still be on
the screen.

While some may argue that this is "just poor design", what if the fields
I initialize varies by product?  I'd get a "merging" of the two products
on the screen depending on what was persisted first.

Are these scenarios valid?


-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com] 
Sent: Friday, May 02, 2008 5:17 PM
To: Tapestry users
Subject: Re: T5: Persistence pains

Could you elaborate on why the "flash" persistence strategy is
insufficient for your needs?

On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com>
wrote:
> All,
>
>  Maybe I'm missing something here, maybe I'm not, but I'm attempting 
> to  preserve state JUST BETWEEN REQUESTS and I'm really struggling (I 
> know  in T5 there's <really> two requests, but for simplicity's sake 
> let's  just call the round trip from the browser a "request").
>
>  My options are:
>
>  1) @Persist("session")
>  - Obviously doesn't work well for just persisting values between  
> requests, unless someone has come up with a reliable construct for  
> nulling out these values whenever someone leaves the page?
>
>  2) @Persist("flash")
>  - This is really only useful for messages and other objects that are

> reliably referenced once.  This is NOT "request-scoped persistence".
>
>  3) @Persist("client")
>  - While I thought initially thought that this would solve all my 
> woes,  instead every link in my application now carries around an huge

> encoded  state variable in the URL.  I'm completely missing the 
> benefit of this  versus just using session persistence (enlightenment
appreciated).
>
>  4) Activation context magic
>  - While this does make for clean and nifty URLs, the hassle of  
> constructing the identifiers for complex objects and creating the  
> contexts for them has not proven "worth it" to me (hint: composite  
> primary keys are almost unusable).  Also, if your page uses more than

> one dynamically-sized collection of objects, then you're out of luck.
>
>  PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry has

> been a delight to work with compared to previous frameworks I've used.
>  I'm just really struggling with how to do something that, IMHO, a web

> framework should make very simple (request-scoped persistence).
>
>  Anyone solve this riddle yet?
>
>  Joel
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>
>



--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

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


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

Re: T5: Persistence pains

[Howard Lewis Ship <hl...@gmail.com>]

Could you elaborate on why the "flash" persistence strategy is
insufficient for your needs?

On Fri, May 2, 2008 at 2:00 PM, Joel Wiegman <Jo...@dswinc.com> wrote:
> All,
>
>  Maybe I'm missing something here, maybe I'm not, but I'm attempting to
>  preserve state JUST BETWEEN REQUESTS and I'm really struggling (I know
>  in T5 there's <really> two requests, but for simplicity's sake let's
>  just call the round trip from the browser a "request").
>
>  My options are:
>
>  1) @Persist("session")
>  - Obviously doesn't work well for just persisting values between
>  requests, unless someone has come up with a reliable construct for
>  nulling out these values whenever someone leaves the page?
>
>  2) @Persist("flash")
>  - This is really only useful for messages and other objects that are
>  reliably referenced once.  This is NOT "request-scoped persistence".
>
>  3) @Persist("client")
>  - While I thought initially thought that this would solve all my woes,
>  instead every link in my application now carries around an huge encoded
>  state variable in the URL.  I'm completely missing the benefit of this
>  versus just using session persistence (enlightenment appreciated).
>
>  4) Activation context magic
>  - While this does make for clean and nifty URLs, the hassle of
>  constructing the identifiers for complex objects and creating the
>  contexts for them has not proven "worth it" to me (hint: composite
>  primary keys are almost unusable).  Also, if your page uses more than
>  one dynamically-sized collection of objects, then you're out of luck.
>
>  PLEASE PLEASE don't interpret this as Tapestry-bashing.  Tapestry has
>  been a delight to work with compared to previous frameworks I've used.
>  I'm just really struggling with how to do something that, IMHO, a web
>  framework should make very simple (request-scoped persistence).
>
>  Anyone solve this riddle yet?
>
>  Joel
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>  For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

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