tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie Orchard-Hays" <ja...@dang.com>
Subject Re: Persistent Properties in 3.1
Date Thu, 11 Nov 2004 20:09:22 GMT
Boy, am I glad you did the ServerSide work <grin>. The state issues are what 
we've struggled with more than anything else here at Darden.

----- Original Message ----- 
From: "Howard Lewis Ship" <hlship@gmail.com>
To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Sent: Thursday, November 11, 2004 12:32 PM
Subject: Re: Persistent Properties in 3.1

>A lot of these patterns show up in TheServerSide.com as well, where
> I'm using a lot of Hidden fields inside forms to store ICallback
> instances.  Doing that work really lit a fire under me to address it
> inside the framework and make it much, much easier.  A significant
> portion of the TSS code is tied up in this ... for example, each page
> class has a corresponding callback instance that exists to persist and
> restore the page's state.
> And you can only go so far along those lines; it isn't practical to
> persistently store component state this way, or for components to
> easily store page state, or for it all to work with links instead of
> forms.  By moving this logic into the framework, these edge cases
> become tractable.
> I've been making the claim that Tapestry's templating approach is a
> chief draw for new developers, but over time, its the state management
> that people can't live without. This will be more true in Tapestry
> 3.1.
> On Thu, 11 Nov 2004 13:31:48 -0300, Jonathan Millett <jon@millett.net> 
> wrote:
>> Hi all,
>> I've been following the users list for a couple of months and the
>> developers list for a couple of weeks. I think Tapestry is a great
>> framework and I continue to enjoy it the more I dig into it. I am
>> excited for the new release and just wanted to chip in my 2 cents based
>> on my experience of the last 2 months.
>> Following up on the persistent properties thread:
>> I second Jaime's idea. If the page properties are persisted in the query
>> string, a user could have, for example, 3 copies of a product detail
>> page open each pointing to a different product based on a product id
>> property persisted in the query string. This is a little awkward to
>> implement now because you have to choose between a) using a persistent
>> property to store the id which doesn't allow the user to have multiple
>> instances of the page open and b) forcing any directLinks on the page
>> (e.g. Buy button, or Add to Favorites button) to pass the product id
>> through their own listener and back to the parent page so it can
>> properly render itself. Another thing nice about using the query string
>> model is that each instance of a page the user has open is self
>> sufficient. It contains all its own state and remains valid for as long
>> as the user keeps it around.
>> I could also imagine the ability to define a property set for a group of
>> pages. Where the set of properties would keep persisting through the
>> query string (or session) until the user navigated away from that set of
>> pages. I presume this might be an alternative way to approach the
>> prescribed path notion (which I didn't see).
>> Another flow pattern I have used in multiple places in my app is that of
>> call and return. I implemented a mechanism where my page validate
>> function when necessary implements a function call to another set of
>> pages. It creates a unique id for the call and persists a set of
>> parameters including a return page/callback which are then looked up by
>> the called page. Once the called page (or set of pages) completes, the
>> return/callback is executed and the call stack released. It would be
>> great if the framework handled this too.
>> As a side note to get the call and return working for my use case, I
>> created a FormCallback which encapsulates a form post. When the callback
>> is executed in a later request cycle, a FormRedirectException (extends
>> PageRedirectException) is thrown to pass control to a modified
>> DirectService which then services the form post (with rewinding etc)
>> just as it would have happened originally. I'm not sure how generally
>> useful this is, but I used it to interrupt a form post with a password
>> confirmation page and then if the password was correct, submit the
>> original form post with no further user interaction.
>> Phew! If you made it this far, thanks for bearing with me :-)
>> I hope some useful information was transmitted.
>> Cheers
>> Jon
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> -- 
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> http://howardlewisship.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

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

View raw message