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: [Jakarta Tapestry Wiki] Updated: Tapestry31Status
Date Tue, 09 Nov 2004 21:14:27 GMT
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 <jamie@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" <hlship@gmail.com>
> To: "Tapestry development" <tapestry-dev@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 <jamie@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 <hlship@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


Mime
View raw message