You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jonathan Millett <jo...@millett.net> on 2004/11/11 17:31:48 UTC
Persistent Properties in 3.1
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
Re: Persistent Properties in 3.1
Posted by Howard Lewis Ship <hl...@gmail.com>.
One view of Tapestry is that its all about automating and abstracting
state management ... and that the rest of the technology exists to
service that single need.
On Thu, 11 Nov 2004 15:09:22 -0500, Jamie Orchard-Hays <ja...@dang.com> wrote:
> 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" <hl...@gmail.com>
> To: "Tapestry development" <ta...@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 <jo...@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
>
>
--
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
Re: Persistent Properties in 3.1
Posted by Jamie Orchard-Hays <ja...@dang.com>.
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" <hl...@gmail.com>
To: "Tapestry development" <ta...@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 <jo...@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
Re: Persistent Properties in 3.1
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jo...@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