You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2004/11/09 18:03:42 UTC
Re: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
Right now, persistent == persist in HttpSession
I think it is reasonable to add two further options right off the bat:
- persist as session cookie
- persist as query parameter (or hidden form field)
Then there's the duration of the value. For example, there are cases
where it would be nice for a value to stay persistent while you are on
the same page, but when you venture out to a different page, the
information can be discarded.
Another direction: if you have a WebObjects background, it stored all
sorts of state variations. so you could be on a page and click option
A and go down that path, then back up a few steps and choose option B
and go down that path and it would just work. I think some of that
should be possible.
Lastly, whatever solution comes about should be pluggable. So, if you
want session-like behaviour with HttpSessions, you should be able to
provide your own persistent properties manager that works directly
with a database.
On Tue, 9 Nov 2004 09:35:09 -0500, Jamie Orchard-Hays <ja...@dang.com> wrote:
> Yay! Howard, what do you mean by "different kinds of persistent
> properties"?
>
> Jamie
>
>
>
>
> On Oct 30, 2004, at 11:03 AM, tapestry-dev@jakarta.apache.org wrote:
>
> > Date: 2004-10-30T08:03:28
> > Editor: HowardLewisShip <hl...@apache.org>
> > Wiki: Jakarta Tapestry Wiki
> > Page: Tapestry31Status
> > URL: http://wiki.apache.org/jakarta-tapestry/Tapestry31Status
> >
> > no comment
> >
> > Change Log:
> >
> > -----------------------------------------------------------------------
> > -------
> > @@ -71,4 +71,19 @@
> >
> > A lot of refactoring over the last few weeks to reorganize things
> > into proper HiveMind services.
> >
> > -Next up: Integrate OGNL properly (for the moment, it is kludged in).
> > +OGNL is now represented as its own service, hidden behind an
> > !ExpressionEvaluator interface. For now, it's still OGNL 2.x, but will
> > be easy to upgrade to 3.x now.
> > +
> > +Tapestry engine services are now full HiveMind services contributed
> > into the tapestry.services.FactoryServices and
> > tapestry.services.ApplicationServices configuration points.
> > +The <service> element of the application specification is removed in
> > 3.1 and ignored (with a warning) in 3.0. The !EngineServiceView
> > interface has been removed; the functionality is now available as
> > additional !HiveMind services that can be injected into engine service
> > implementations.
> > +
> > +Refactorings are starting around component class enhancement. 3.1
> > will have some different behavior than 3.0. By the time I'm through,
> > all parameters will be treated as an improved version of Tapestry
> > 3.0's Direction.AUTO (one that properly handles non-required
> > parameters and caches the bound expression's value).
> > +
> > +Changes:
> > + * A <property> will always create a property; the checks for an
> > existing non-abstract method have been removed.
> > + * 3.1 will create a transient property if an abstract accessor
> > exists for a property, even if there is no matching <property> (this
> > falls under ''dont repeat yourself'').
> > + * 3.1 will allow the type attribute of <property> to be ignored
> > (more ''dont repeat yourself''). The property created will match the
> > accessors (if they exist) or will simply be java.lang.Object (if they
> > don't).
> > + * 3.1 will eventually allow different kinds of persistent properties.
> > + * 3.1 will no longer support binding properties; these were
> > properties used to access the underlying bindings for component
> > parameters. In 3.0, if an abstract accessor was available, Tapestry
> > would provide and use the full implementation.
> > + * The direction attribute of <property> will be removed in 3.1 (and
> > ignored inside 3.0's <property-specification>).
> > +
> > +The upshot of this is that component properties and parameters will
> > ''just work''.
> >
> > ---------------------------------------------------------------------
> > 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 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
Persistent Properties in 3.1
Posted by Jonathan Millett <jo...@millett.net>.
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: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
Posted by Jamie Orchard-Hays <ja...@dang.com>.
yup, what you said in the last paragraph.
On Nov 9, 2004, at 8:27 PM, Erik Hatcher wrote:
>
> On Nov 9, 2004, at 5:34 PM, Jamie Orchard-Hays wrote:
>> Is having data persist only per page difficult?
>
> Could you elaborate on what you mean by "per page"? Static variables
> in page classes are persistent per page, globally. But this is not
> what you mean, I suspect. Per page per session? Persistent
> properties already are that.
>
> Are you asking for session based data or application based? Surely at
> least session based, I presume.
>
> But what would cause the data to be invalidated and able to be garbage
> collected?
>
> Maybe you're asking for the same thing Howard described with the
> prescribed path keeping things persistent, but once a user navigates
> away from that path the persistent information is released.
>
> Erik
>
>
> ---------------------------------------------------------------------
> 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: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Nov 9, 2004, at 5:34 PM, Jamie Orchard-Hays wrote:
> Is having data persist only per page difficult?
Could you elaborate on what you mean by "per page"? Static variables
in page classes are persistent per page, globally. But this is not
what you mean, I suspect. Per page per session? Persistent properties
already are that.
Are you asking for session based data or application based? Surely at
least session based, I presume.
But what would cause the data to be invalidated and able to be garbage
collected?
Maybe you're asking for the same thing Howard described with the
prescribed path keeping things persistent, but once a user navigates
away from that path the persistent information is released.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Is having data persist only per page difficult? This would be the default
usage and probably apply to 95% of situations.
Jamie
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Jamie Orchard-Hays" <ja...@dang.com>; "Tapestry development"
<ta...@jakarta.apache.org>
Sent: Tuesday, November 09, 2004 4:14 PM
Subject: Re: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
> The problem is coming up with hard rules for when you can discard
> data, mated to some simple syntax for expressing it!
>
>
> On Tue, 9 Nov 2004 12:26:00 -0500, Jamie Orchard-Hays <ja...@dang.com>
> wrote:
>> I like the direction you're heading with this. Cookie, q param and form
>> fields are all valid ways of persisting and having an automatic way would
>> be
>> great.
>>
>> Having duration would also solve a lot of problems and/or code verbosity
>> I've encountered with having persistence that I don't want hanging around
>> when I'm done with the data. Having a persistence mode or duration that
>> only
>> lasted while returning to the same page and then discard after would be a
>> big plus. It would mean less manual coding to clean up data from memory
>> when
>> leaving a page and would take care of those cases when you can't clean it
>> out (ie, user wanders off via a link to some other part of the app).
>>
>> Jamie
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
Posted by Howard Lewis Ship <hl...@gmail.com>.
The problem is coming up with hard rules for when you can discard
data, mated to some simple syntax for expressing it!
On Tue, 9 Nov 2004 12:26:00 -0500, Jamie Orchard-Hays <ja...@dang.com> wrote:
> I like the direction you're heading with this. Cookie, q param and form
> fields are all valid ways of persisting and having an automatic way would be
> great.
>
> Having duration would also solve a lot of problems and/or code verbosity
> I've encountered with having persistence that I don't want hanging around
> when I'm done with the data. Having a persistence mode or duration that only
> lasted while returning to the same page and then discard after would be a
> big plus. It would mean less manual coding to clean up data from memory when
> leaving a page and would take care of those cases when you can't clean it
> out (ie, user wanders off via a link to some other part of the app).
>
> Jamie
>
>
>
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Tuesday, November 09, 2004 12:03 PM
> Subject: Re: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
>
> > Right now, persistent == persist in HttpSession
> >
> > I think it is reasonable to add two further options right off the bat:
> > - persist as session cookie
> > - persist as query parameter (or hidden form field)
> >
> > Then there's the duration of the value. For example, there are cases
> > where it would be nice for a value to stay persistent while you are on
> > the same page, but when you venture out to a different page, the
> > information can be discarded.
> >
> > Another direction: if you have a WebObjects background, it stored all
> > sorts of state variations. so you could be on a page and click option
> > A and go down that path, then back up a few steps and choose option B
> > and go down that path and it would just work. I think some of that
> > should be possible.
> >
> > Lastly, whatever solution comes about should be pluggable. So, if you
> > want session-like behaviour with HttpSessions, you should be able to
> > provide your own persistent properties manager that works directly
> > with a database.
> >
> >
> > On Tue, 9 Nov 2004 09:35:09 -0500, Jamie Orchard-Hays <ja...@dang.com>
> > wrote:
> >> Yay! Howard, what do you mean by "different kinds of persistent
> >> properties"?
> >>
> >> Jamie
> >>
> >>
> >>
> >>
> >> On Oct 30, 2004, at 11:03 AM, tapestry-dev@jakarta.apache.org wrote:
> >>
> >> > Date: 2004-10-30T08:03:28
> >> > Editor: HowardLewisShip <hl...@apache.org>
> >> > Wiki: Jakarta Tapestry Wiki
> >> > Page: Tapestry31Status
> >> > URL: http://wiki.apache.org/jakarta-tapestry/Tapestry31Status
> >> >
> >> > no comment
> >> >
> >> > Change Log:
> >> >
> >> > -----------------------------------------------------------------------
> >> > -------
> >> > @@ -71,4 +71,19 @@
> >> >
> >> > A lot of refactoring over the last few weeks to reorganize things
> >> > into proper HiveMind services.
> >> >
> >> > -Next up: Integrate OGNL properly (for the moment, it is kludged in).
> >> > +OGNL is now represented as its own service, hidden behind an
> >> > !ExpressionEvaluator interface. For now, it's still OGNL 2.x, but will
> >> > be easy to upgrade to 3.x now.
> >> > +
> >> > +Tapestry engine services are now full HiveMind services contributed
> >> > into the tapestry.services.FactoryServices and
> >> > tapestry.services.ApplicationServices configuration points.
> >> > +The <service> element of the application specification is removed in
> >> > 3.1 and ignored (with a warning) in 3.0. The !EngineServiceView
> >> > interface has been removed; the functionality is now available as
> >> > additional !HiveMind services that can be injected into engine service
> >> > implementations.
> >> > +
> >> > +Refactorings are starting around component class enhancement. 3.1
> >> > will have some different behavior than 3.0. By the time I'm through,
> >> > all parameters will be treated as an improved version of Tapestry
> >> > 3.0's Direction.AUTO (one that properly handles non-required
> >> > parameters and caches the bound expression's value).
> >> > +
> >> > +Changes:
> >> > + * A <property> will always create a property; the checks for an
> >> > existing non-abstract method have been removed.
> >> > + * 3.1 will create a transient property if an abstract accessor
> >> > exists for a property, even if there is no matching <property> (this
> >> > falls under ''dont repeat yourself'').
> >> > + * 3.1 will allow the type attribute of <property> to be ignored
> >> > (more ''dont repeat yourself''). The property created will match the
> >> > accessors (if they exist) or will simply be java.lang.Object (if they
> >> > don't).
> >> > + * 3.1 will eventually allow different kinds of persistent properties.
> >> > + * 3.1 will no longer support binding properties; these were
> >> > properties used to access the underlying bindings for component
> >> > parameters. In 3.0, if an abstract accessor was available, Tapestry
> >> > would provide and use the full implementation.
> >> > + * The direction attribute of <property> will be removed in 3.1 (and
> >> > ignored inside 3.0's <property-specification>).
> >> > +
> >> > +The upshot of this is that component properties and parameters will
> >> > ''just work''.
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >
>
>
--
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: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
Posted by Jamie Orchard-Hays <ja...@dang.com>.
I like the direction you're heading with this. Cookie, q param and form
fields are all valid ways of persisting and having an automatic way would be
great.
Having duration would also solve a lot of problems and/or code verbosity
I've encountered with having persistence that I don't want hanging around
when I'm done with the data. Having a persistence mode or duration that only
lasted while returning to the same page and then discard after would be a
big plus. It would mean less manual coding to clean up data from memory when
leaving a page and would take care of those cases when you can't clean it
out (ie, user wanders off via a link to some other part of the app).
Jamie
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Tuesday, November 09, 2004 12:03 PM
Subject: Re: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
> Right now, persistent == persist in HttpSession
>
> I think it is reasonable to add two further options right off the bat:
> - persist as session cookie
> - persist as query parameter (or hidden form field)
>
> Then there's the duration of the value. For example, there are cases
> where it would be nice for a value to stay persistent while you are on
> the same page, but when you venture out to a different page, the
> information can be discarded.
>
> Another direction: if you have a WebObjects background, it stored all
> sorts of state variations. so you could be on a page and click option
> A and go down that path, then back up a few steps and choose option B
> and go down that path and it would just work. I think some of that
> should be possible.
>
> Lastly, whatever solution comes about should be pluggable. So, if you
> want session-like behaviour with HttpSessions, you should be able to
> provide your own persistent properties manager that works directly
> with a database.
>
>
> On Tue, 9 Nov 2004 09:35:09 -0500, Jamie Orchard-Hays <ja...@dang.com>
> wrote:
>> Yay! Howard, what do you mean by "different kinds of persistent
>> properties"?
>>
>> Jamie
>>
>>
>>
>>
>> On Oct 30, 2004, at 11:03 AM, tapestry-dev@jakarta.apache.org wrote:
>>
>> > Date: 2004-10-30T08:03:28
>> > Editor: HowardLewisShip <hl...@apache.org>
>> > Wiki: Jakarta Tapestry Wiki
>> > Page: Tapestry31Status
>> > URL: http://wiki.apache.org/jakarta-tapestry/Tapestry31Status
>> >
>> > no comment
>> >
>> > Change Log:
>> >
>> > -----------------------------------------------------------------------
>> > -------
>> > @@ -71,4 +71,19 @@
>> >
>> > A lot of refactoring over the last few weeks to reorganize things
>> > into proper HiveMind services.
>> >
>> > -Next up: Integrate OGNL properly (for the moment, it is kludged in).
>> > +OGNL is now represented as its own service, hidden behind an
>> > !ExpressionEvaluator interface. For now, it's still OGNL 2.x, but will
>> > be easy to upgrade to 3.x now.
>> > +
>> > +Tapestry engine services are now full HiveMind services contributed
>> > into the tapestry.services.FactoryServices and
>> > tapestry.services.ApplicationServices configuration points.
>> > +The <service> element of the application specification is removed in
>> > 3.1 and ignored (with a warning) in 3.0. The !EngineServiceView
>> > interface has been removed; the functionality is now available as
>> > additional !HiveMind services that can be injected into engine service
>> > implementations.
>> > +
>> > +Refactorings are starting around component class enhancement. 3.1
>> > will have some different behavior than 3.0. By the time I'm through,
>> > all parameters will be treated as an improved version of Tapestry
>> > 3.0's Direction.AUTO (one that properly handles non-required
>> > parameters and caches the bound expression's value).
>> > +
>> > +Changes:
>> > + * A <property> will always create a property; the checks for an
>> > existing non-abstract method have been removed.
>> > + * 3.1 will create a transient property if an abstract accessor
>> > exists for a property, even if there is no matching <property> (this
>> > falls under ''dont repeat yourself'').
>> > + * 3.1 will allow the type attribute of <property> to be ignored
>> > (more ''dont repeat yourself''). The property created will match the
>> > accessors (if they exist) or will simply be java.lang.Object (if they
>> > don't).
>> > + * 3.1 will eventually allow different kinds of persistent properties.
>> > + * 3.1 will no longer support binding properties; these were
>> > properties used to access the underlying bindings for component
>> > parameters. In 3.0, if an abstract accessor was available, Tapestry
>> > would provide and use the full implementation.
>> > + * The direction attribute of <property> will be removed in 3.1 (and
>> > ignored inside 3.0's <property-specification>).
>> > +
>> > +The upshot of this is that component properties and parameters will
>> > ''just work''.
>> >
>> > ---------------------------------------------------------------------
>> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org