tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Persistent Properties in 3.1
Date Thu, 11 Nov 2004 17:32:20 GMT
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

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

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

View raw message