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: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]
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 <
[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
TheDailyTube.com. Sign up and get the best new videos on the
internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
