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 2005/01/28 21:22:57 UTC
[3.1] Engine deprecated
The way I'm headed right now, the engine will be deprecated in a later
release of Tapestry.
The engine has three main purposes:
1. Runs the request cycle
2. Allows different subsystems to locate each other
3. Manages persistent application state
Obviously, with all the HiveMind changes, the utility of the engine is
evaporating into a soup of HiveMind services and configurations. This
is good for lots of reasons, including plans to support the Portlet
API as well as the Servlet API.
I'm nearly done with changes such that the engine is completely
divorced from persistent application state. The engine will no longer
be serializable or stored in the HttpSession. Each application state
object will be stored in the session under a unique key.
What's an application state object? It's the visit object and the
global object. In 3.1, you can have as many as you want, stored in
whatever scope you want (application, session). You can even define
your own scopes. For backwards compatibility, visit and global will
be maintained (for a while).
My question to the community ... how many people subclass BaseEngine,
and for what reasons?
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. 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: [3.1] Engine deprecated
Posted by Paul Ferraro <pm...@columbia.edu>.
I've only ever had to subclass BaseEngine for 2 reasons:
1. Friendly url support [specifically, extractServiceName()] - but this
will (thankfully) be obsolete in 3.1.
2. Registering custom ISqueezeAdaptors [specifically,
createDataSqueezer()] - but this moves into the tapestry.data service
descriptor.
Speaking of which, it has always bothered me that I can't override an
ISqueezeAdaptor. Would you, or anyone else, object to changing this in 3.1?
An easy option is to move all of the "default" ISqueezeAdaptor
registration into the service descriptor. Thoughts?
Paul
Howard Lewis Ship wrote:
>The way I'm headed right now, the engine will be deprecated in a later
>release of Tapestry.
>
>The engine has three main purposes:
>1. Runs the request cycle
>2. Allows different subsystems to locate each other
>3. Manages persistent application state
>
>Obviously, with all the HiveMind changes, the utility of the engine is
>evaporating into a soup of HiveMind services and configurations. This
>is good for lots of reasons, including plans to support the Portlet
>API as well as the Servlet API.
>
>I'm nearly done with changes such that the engine is completely
>divorced from persistent application state. The engine will no longer
>be serializable or stored in the HttpSession. Each application state
>object will be stored in the session under a unique key.
>
>What's an application state object? It's the visit object and the
>global object. In 3.1, you can have as many as you want, stored in
>whatever scope you want (application, session). You can even define
>your own scopes. For backwards compatibility, visit and global will
>be maintained (for a while).
>
>My question to the community ... how many people subclass BaseEngine,
>and for what reasons?
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Jamie Orchard-Hays <ja...@dang.com>.
At Darden we've got:
setupForRequest()
createSpecificationSource() for a custom SpecificationSource
getComponentMessagesSource() for custom message resource location
activateExceptionPage() for custom exception redirection
Jamie
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Friday, January 28, 2005 3:22 PM
Subject: [3.1] Engine deprecated
> The way I'm headed right now, the engine will be deprecated in a later
> release of Tapestry.
>
> The engine has three main purposes:
> 1. Runs the request cycle
> 2. Allows different subsystems to locate each other
> 3. Manages persistent application state
>
> Obviously, with all the HiveMind changes, the utility of the engine is
> evaporating into a soup of HiveMind services and configurations. This
> is good for lots of reasons, including plans to support the Portlet
> API as well as the Servlet API.
>
> I'm nearly done with changes such that the engine is completely
> divorced from persistent application state. The engine will no longer
> be serializable or stored in the HttpSession. Each application state
> object will be stored in the session under a unique key.
>
> What's an application state object? It's the visit object and the
> global object. In 3.1, you can have as many as you want, stored in
> whatever scope you want (application, session). You can even define
> your own scopes. For backwards compatibility, visit and global will
> be maintained (for a while).
>
> My question to the community ... how many people subclass BaseEngine,
> and for what reasons?
>
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. 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: [3.1] Engine deprecated
Posted by Howard Lewis Ship <hl...@gmail.com>.
I want to wait and see how difficult the upgrade is from 3.0 to
3.1/4.0 for existing applications.
On Fri, 28 Jan 2005 16:38:02 -0500, Jamie Orchard-Hays <ja...@dang.com> wrote:
> +1 on 4.0. It's a serious rewrite of the app
>
>
> ----- Original Message -----
> From: "Colin Sampaleanu" <co...@exis.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
>
> Sent: Friday, January 28, 2005 4:24 PM
> Subject: Re: [3.1] Engine deprecated
>
> >I think 3.0 -> 3.1 implies backwards compatibility (API level, not just
> >conceptual level), while 3.0 -> 4.0 doesn't... In that respect, I think 4.0
> >makes sense, as the new version will not be strictly backwards compatible.
> >
> > Colin
> >
> > Howard Lewis Ship wrote:
> >
> >>This seems to happen on every release. 2.4 became 3.0. I don't know
> >>that there's a marketing advantage to using 4.0 over 3.1.
> >>
> >>I think for the majority of end users, the differences between 2.3 and
> >>3.0 will be greater than the differences between 3.0 and 3.1. For
> >>power users, there will be a lot of new differences, hopefully
> >>improvements.
> >>
> >>
> >>On Fri, 28 Jan 2005 15:50:38 -0500, Colin Sampaleanu <co...@exis.com>
> >>wrote:
> >>
> >>>Howard Lewis Ship wrote:
> >>>
> >>>
> >>>>The way I'm headed right now, the engine will be deprecated in a later
> >>>>release of Tapestry.
> >>>>
> >>>>The engine has three main purposes:
> >>>>1. Runs the request cycle
> >>>>2. Allows different subsystems to locate each other
> >>>>3. Manages persistent application state
> >>>>
> >>>>Obviously, with all the HiveMind changes, the utility of the engine is
> >>>>evaporating into a soup of HiveMind services and configurations. This
> >>>>is good for lots of reasons, including plans to support the Portlet
> >>>>API as well as the Servlet API.
> >>>>
> >>>>I'm nearly done with changes such that the engine is completely
> >>>>divorced from persistent application state. The engine will no longer
> >>>>be serializable or stored in the HttpSession. Each application state
> >>>>object will be stored in the session under a unique key.
> >>>>
> >>>>What's an application state object? It's the visit object and the
> >>>>global object. In 3.1, you can have as many as you want, stored in
> >>>>whatever scope you want (application, session). You can even define
> >>>>your own scopes. For backwards compatibility, visit and global will
> >>>>be maintained (for a while).
> >>>>
> >>>>My question to the community ... how many people subclass BaseEngine,
> >>>>and for what reasons?
> >>>>
> >>>>
> >>>>
> >>>I subclassed Engine, but only to access Spring. Obviously there'll be
> >>>other ways to do it now...
> >>>
> >>>Btw, this is not really related, but I keep meaning to ask (and
> >>>apologies if somebody else has brought this up). With all these changes
> >>>to Tapestry, is this release really appropriately called v3.1 vs. let's
> >>>say 4.0?
> >>>
> >>>Colin
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>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
> >
>
> ---------------------------------------------------------------------
> 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
Professional Tapestry training, mentoring, support
and project work. 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: [3.1] Engine deprecated
Posted by Jamie Orchard-Hays <ja...@dang.com>.
+1 on 4.0. It's a serious rewrite of the app
----- Original Message -----
From: "Colin Sampaleanu" <co...@exis.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Friday, January 28, 2005 4:24 PM
Subject: Re: [3.1] Engine deprecated
>I think 3.0 -> 3.1 implies backwards compatibility (API level, not just
>conceptual level), while 3.0 -> 4.0 doesn't... In that respect, I think 4.0
>makes sense, as the new version will not be strictly backwards compatible.
>
> Colin
>
> Howard Lewis Ship wrote:
>
>>This seems to happen on every release. 2.4 became 3.0. I don't know
>>that there's a marketing advantage to using 4.0 over 3.1.
>>
>>I think for the majority of end users, the differences between 2.3 and
>>3.0 will be greater than the differences between 3.0 and 3.1. For
>>power users, there will be a lot of new differences, hopefully
>>improvements.
>>
>>
>>On Fri, 28 Jan 2005 15:50:38 -0500, Colin Sampaleanu <co...@exis.com>
>>wrote:
>>
>>>Howard Lewis Ship wrote:
>>>
>>>
>>>>The way I'm headed right now, the engine will be deprecated in a later
>>>>release of Tapestry.
>>>>
>>>>The engine has three main purposes:
>>>>1. Runs the request cycle
>>>>2. Allows different subsystems to locate each other
>>>>3. Manages persistent application state
>>>>
>>>>Obviously, with all the HiveMind changes, the utility of the engine is
>>>>evaporating into a soup of HiveMind services and configurations. This
>>>>is good for lots of reasons, including plans to support the Portlet
>>>>API as well as the Servlet API.
>>>>
>>>>I'm nearly done with changes such that the engine is completely
>>>>divorced from persistent application state. The engine will no longer
>>>>be serializable or stored in the HttpSession. Each application state
>>>>object will be stored in the session under a unique key.
>>>>
>>>>What's an application state object? It's the visit object and the
>>>>global object. In 3.1, you can have as many as you want, stored in
>>>>whatever scope you want (application, session). You can even define
>>>>your own scopes. For backwards compatibility, visit and global will
>>>>be maintained (for a while).
>>>>
>>>>My question to the community ... how many people subclass BaseEngine,
>>>>and for what reasons?
>>>>
>>>>
>>>>
>>>I subclassed Engine, but only to access Spring. Obviously there'll be
>>>other ways to do it now...
>>>
>>>Btw, this is not really related, but I keep meaning to ask (and
>>>apologies if somebody else has brought this up). With all these changes
>>>to Tapestry, is this release really appropriately called v3.1 vs. let's
>>>say 4.0?
>>>
>>>Colin
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Colin Sampaleanu <co...@exis.com>.
I think 3.0 -> 3.1 implies backwards compatibility (API level, not just
conceptual level), while 3.0 -> 4.0 doesn't... In that respect, I think
4.0 makes sense, as the new version will not be strictly backwards
compatible.
Colin
Howard Lewis Ship wrote:
>This seems to happen on every release. 2.4 became 3.0. I don't know
>that there's a marketing advantage to using 4.0 over 3.1.
>
>I think for the majority of end users, the differences between 2.3 and
>3.0 will be greater than the differences between 3.0 and 3.1. For
>power users, there will be a lot of new differences, hopefully
>improvements.
>
>
>On Fri, 28 Jan 2005 15:50:38 -0500, Colin Sampaleanu <co...@exis.com> wrote:
>
>
>>Howard Lewis Ship wrote:
>>
>>
>>
>>>The way I'm headed right now, the engine will be deprecated in a later
>>>release of Tapestry.
>>>
>>>The engine has three main purposes:
>>>1. Runs the request cycle
>>>2. Allows different subsystems to locate each other
>>>3. Manages persistent application state
>>>
>>>Obviously, with all the HiveMind changes, the utility of the engine is
>>>evaporating into a soup of HiveMind services and configurations. This
>>>is good for lots of reasons, including plans to support the Portlet
>>>API as well as the Servlet API.
>>>
>>>I'm nearly done with changes such that the engine is completely
>>>divorced from persistent application state. The engine will no longer
>>>be serializable or stored in the HttpSession. Each application state
>>>object will be stored in the session under a unique key.
>>>
>>>What's an application state object? It's the visit object and the
>>>global object. In 3.1, you can have as many as you want, stored in
>>>whatever scope you want (application, session). You can even define
>>>your own scopes. For backwards compatibility, visit and global will
>>>be maintained (for a while).
>>>
>>>My question to the community ... how many people subclass BaseEngine,
>>>and for what reasons?
>>>
>>>
>>>
>>>
>>I subclassed Engine, but only to access Spring. Obviously there'll be
>>other ways to do it now...
>>
>>Btw, this is not really related, but I keep meaning to ask (and
>>apologies if somebody else has brought this up). With all these changes
>>to Tapestry, is this release really appropriately called v3.1 vs. let's
>>say 4.0?
>>
>>Colin
>>
>>
>>---------------------------------------------------------------------
>>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: [3.1] Engine deprecated
Posted by Howard Lewis Ship <hl...@gmail.com>.
This seems to happen on every release. 2.4 became 3.0. I don't know
that there's a marketing advantage to using 4.0 over 3.1.
I think for the majority of end users, the differences between 2.3 and
3.0 will be greater than the differences between 3.0 and 3.1. For
power users, there will be a lot of new differences, hopefully
improvements.
On Fri, 28 Jan 2005 15:50:38 -0500, Colin Sampaleanu <co...@exis.com> wrote:
> Howard Lewis Ship wrote:
>
> >The way I'm headed right now, the engine will be deprecated in a later
> >release of Tapestry.
> >
> >The engine has three main purposes:
> >1. Runs the request cycle
> >2. Allows different subsystems to locate each other
> >3. Manages persistent application state
> >
> >Obviously, with all the HiveMind changes, the utility of the engine is
> >evaporating into a soup of HiveMind services and configurations. This
> >is good for lots of reasons, including plans to support the Portlet
> >API as well as the Servlet API.
> >
> >I'm nearly done with changes such that the engine is completely
> >divorced from persistent application state. The engine will no longer
> >be serializable or stored in the HttpSession. Each application state
> >object will be stored in the session under a unique key.
> >
> >What's an application state object? It's the visit object and the
> >global object. In 3.1, you can have as many as you want, stored in
> >whatever scope you want (application, session). You can even define
> >your own scopes. For backwards compatibility, visit and global will
> >be maintained (for a while).
> >
> >My question to the community ... how many people subclass BaseEngine,
> >and for what reasons?
> >
> >
> I subclassed Engine, but only to access Spring. Obviously there'll be
> other ways to do it now...
>
> Btw, this is not really related, but I keep meaning to ask (and
> apologies if somebody else has brought this up). With all these changes
> to Tapestry, is this release really appropriately called v3.1 vs. let's
> say 4.0?
>
> Colin
>
>
> ---------------------------------------------------------------------
> 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
Professional Tapestry training, mentoring, support
and project work. 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: [3.1] Engine deprecated
Posted by Colin Sampaleanu <co...@exis.com>.
Howard Lewis Ship wrote:
>The way I'm headed right now, the engine will be deprecated in a later
>release of Tapestry.
>
>The engine has three main purposes:
>1. Runs the request cycle
>2. Allows different subsystems to locate each other
>3. Manages persistent application state
>
>Obviously, with all the HiveMind changes, the utility of the engine is
>evaporating into a soup of HiveMind services and configurations. This
>is good for lots of reasons, including plans to support the Portlet
>API as well as the Servlet API.
>
>I'm nearly done with changes such that the engine is completely
>divorced from persistent application state. The engine will no longer
>be serializable or stored in the HttpSession. Each application state
>object will be stored in the session under a unique key.
>
>What's an application state object? It's the visit object and the
>global object. In 3.1, you can have as many as you want, stored in
>whatever scope you want (application, session). You can even define
>your own scopes. For backwards compatibility, visit and global will
>be maintained (for a while).
>
>My question to the community ... how many people subclass BaseEngine,
>and for what reasons?
>
>
I subclassed Engine, but only to access Spring. Obviously there'll be
other ways to do it now...
Btw, this is not really related, but I keep meaning to ask (and
apologies if somebody else has brought this up). With all these changes
to Tapestry, is this release really appropriately called v3.1 vs. let's
say 4.0?
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Markus Wiederkehr <ma...@gmail.com>.
On Fri, 28 Jan 2005 15:22:57 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> My question to the community ... how many people subclass BaseEngine,
> and for what reasons?
Currently I override:
setupForRequest()
createDataSqueezer()
handleStaleSessionException() for redirecting to the login page
restart() to remove a stateful session bean
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Mikaël Cluseau <nw...@nwrk.dyndns.org>.
Le vendredi 28 janvier 2005 à 20:01 -0500, Howard Lewis Ship a écrit :
> If you can grok the HiveMInd descriptors, you'll see how there are
> non-sublcassing approaches to overriding and changing this kind of
> behavior.
>
> I don't think these changes under the surface will affect most people
> too terribly. Of course, most every Tapestry app does override
> activateExceptionPage(), etc. Under 3.1, it'll be more a matter of
> slipping in a new object to handle exceptions.
>
> Having the new ways ofmoving data around besides OGNL is great ...
> great for performance, great for expressiveness. It will allow whole
> new ways of specifying behavior.
>
> In case you can't tell, I'm very jazzed on all this; Tapestry 3.1 is
> now coming together rapidly. There's still tons to do:
>
> Documentation, including the component reference, is lacking.
>
> I think we want to have a good number of short How To pages.
>
> Still need to address the testing issue better.
>
> Portlet support.
>
> Stabilize HiveMind 1.1.
>
> OGNL 3.0.
>
> More component testing! Lots of component code still has 0% code coverage.
>
> I slopped a bunch of code into tapestry.services that I'm thinking
> belongs distributed into many packages (some existing, some new). And
> some things were given WierdHowardNames that need ProperNames (yes, I
> get the naming wrong too often).
>
> I'm beat! There's so much to work on.
I'll have some hours (5-10 approx) a week for 5 months. What do I need
to know to help Tapestry 3.1 development?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Howard Lewis Ship <hl...@gmail.com>.
If you can grok the HiveMInd descriptors, you'll see how there are
non-sublcassing approaches to overriding and changing this kind of
behavior.
I don't think these changes under the surface will affect most people
too terribly. Of course, most every Tapestry app does override
activateExceptionPage(), etc. Under 3.1, it'll be more a matter of
slipping in a new object to handle exceptions.
Having the new ways ofmoving data around besides OGNL is great ...
great for performance, great for expressiveness. It will allow whole
new ways of specifying behavior.
In case you can't tell, I'm very jazzed on all this; Tapestry 3.1 is
now coming together rapidly. There's still tons to do:
Documentation, including the component reference, is lacking.
I think we want to have a good number of short How To pages.
Still need to address the testing issue better.
Portlet support.
Stabilize HiveMind 1.1.
OGNL 3.0.
More component testing! Lots of component code still has 0% code coverage.
I slopped a bunch of code into tapestry.services that I'm thinking
belongs distributed into many packages (some existing, some new). And
some things were given WierdHowardNames that need ProperNames (yes, I
get the naming wrong too often).
I'm beat! There's so much to work on.
On Sat, 29 Jan 2005 10:53:32 +1100, Richard Lewis-Shell
<rl...@mac.com> wrote:
> >> My question to the community ... how many people subclass BaseEngine,
> >> and for what reasons?
> >
> >
> > I have in every Tapestry application. In lucenebook.com, I override
> > activateExceptionPage (to log and throw a ServletException which I
> > manage at the container level).
>
> We also override activateExceptionPage for this kind of purpose.
>
> > In my day work, I override createVisit (to populate the Visit from some
> > cookies) and createGlobal (to instantiate it with a configuration
> > parameter from property source).
>
> Ditto!
>
> From where I sit, the 3.1 changes look bigger than any changes Tapestry
> has seen in my time with it. Which is to say that the way I think about
> using Tapestry has changed little since the 0.2.x days, but '3.1' looks
> like it will force something of a re-think - for the better.
>
> I would hate to see 'backwards compatability' stifle the flow on these
> changes. Perhaps we would be better off with migration tools for 3.0 ->
> 4.0 rather than a backwards compatible 3.1...
>
> Richard
>
> ---------------------------------------------------------------------
> 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
Professional Tapestry training, mentoring, support
and project work. 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: [3.1] Engine deprecated
Posted by Richard Lewis-Shell <rl...@mac.com>.
>> My question to the community ... how many people subclass BaseEngine,
>> and for what reasons?
>
>
> I have in every Tapestry application. In lucenebook.com, I override
> activateExceptionPage (to log and throw a ServletException which I
> manage at the container level).
We also override activateExceptionPage for this kind of purpose.
> In my day work, I override createVisit (to populate the Visit from some
> cookies) and createGlobal (to instantiate it with a configuration
> parameter from property source).
Ditto!
From where I sit, the 3.1 changes look bigger than any changes Tapestry
has seen in my time with it. Which is to say that the way I think about
using Tapestry has changed little since the 0.2.x days, but '3.1' looks
like it will force something of a re-think - for the better.
I would hate to see 'backwards compatability' stifle the flow on these
changes. Perhaps we would be better off with migration tools for 3.0 ->
4.0 rather than a backwards compatible 3.1...
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Mind Bridge <mi...@yahoo.com>.
I have mentioned that before a couple of times, I just have not considered
it that important to insist. But yes, +1 from me as well.
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Saturday, January 29, 2005 10:44 PM
Subject: Re: [3.1] Engine deprecated
>
> On Jan 29, 2005, at 12:26 PM, Howard Lewis Ship wrote:
> > Well, it made sense to me at the time. Changing the order is easy
> > enough now ... it's a Chain or Pipeline and changing the order
> > involves just the HiveMind descriptor. Can we establish what the
> > correct order is?
>
> The current order is this:
> .application
> servlet config
> servlet context
> extension property source
> system properties
> built-in configuration defaults
>
> I propose this order:
> system properties
> servlet config
> extension property source
> servlet context
> .application
> built-in configuration defaults
>
> The main thing for me is to put system properties up front allowing me
> to configure an application from the outside, yet still allow
> development-time defaults to be in the .application file. Servlet
> config would rarely be used for such properties, but it makes sense for
> it to be next after system properties as in J2EE rhetoric the
> "deployer" (yeah, right! :) would control this when deploying an
> application. So, system properties and servlet config trump everything
> as someone would be specifically going out of their way to set these.
> Extensions next, allowing custom hooks to control properties in the
> most common scenario of no outside influences. Servlet context would
> also rarely be used, but could allow for some dynamic control (perhaps
> from integration with other web technologies. .application basically
> last - but not least, as all of the other sources would rarely be used.
>
> Thoughts?
>
> Erik
>
> >
> >
> > On Sat, 29 Jan 2005 11:56:59 -0500, Jamie Orchard-Hays
> > <ja...@dang.com> wrote:
> >> YES, PLEASE!!!!
> >>
> >>
> >> On Jan 28, 2005, at 4:57 PM, Erik Hatcher wrote:
> >>
> >>> That reminds me... can we invert the order of property source loading
> >>> in 3.1? The inside-out philosophy of it drives me crazy. Ant
> >>> property immutability-like rules make much more sense to me.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> > Professional Tapestry training, mentoring, support
> > and project work. 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jan 29, 2005, at 12:26 PM, Howard Lewis Ship wrote:
> Well, it made sense to me at the time. Changing the order is easy
> enough now ... it's a Chain or Pipeline and changing the order
> involves just the HiveMind descriptor. Can we establish what the
> correct order is?
The current order is this:
.application
servlet config
servlet context
extension property source
system properties
built-in configuration defaults
I propose this order:
system properties
servlet config
extension property source
servlet context
.application
built-in configuration defaults
The main thing for me is to put system properties up front allowing me
to configure an application from the outside, yet still allow
development-time defaults to be in the .application file. Servlet
config would rarely be used for such properties, but it makes sense for
it to be next after system properties as in J2EE rhetoric the
"deployer" (yeah, right! :) would control this when deploying an
application. So, system properties and servlet config trump everything
as someone would be specifically going out of their way to set these.
Extensions next, allowing custom hooks to control properties in the
most common scenario of no outside influences. Servlet context would
also rarely be used, but could allow for some dynamic control (perhaps
from integration with other web technologies. .application basically
last - but not least, as all of the other sources would rarely be used.
Thoughts?
Erik
>
>
> On Sat, 29 Jan 2005 11:56:59 -0500, Jamie Orchard-Hays
> <ja...@dang.com> wrote:
>> YES, PLEASE!!!!
>>
>>
>> On Jan 28, 2005, at 4:57 PM, Erik Hatcher wrote:
>>
>>> That reminds me... can we invert the order of property source loading
>>> in 3.1? The inside-out philosophy of it drives me crazy. Ant
>>> property immutability-like rules make much more sense to me.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
> Professional Tapestry training, mentoring, support
> and project work. 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: [3.1] Engine deprecated
Posted by Howard Lewis Ship <hl...@gmail.com>.
Well, it made sense to me at the time. Changing the order is easy
enough now ... it's a Chain or Pipeline and changing the order
involves just the HiveMind descriptor. Can we establish what the
correct order is?
On Sat, 29 Jan 2005 11:56:59 -0500, Jamie Orchard-Hays <ja...@dang.com> wrote:
> YES, PLEASE!!!!
>
>
> On Jan 28, 2005, at 4:57 PM, Erik Hatcher wrote:
>
> > That reminds me... can we invert the order of property source loading
> > in 3.1? The inside-out philosophy of it drives me crazy. Ant
> > property immutability-like rules make much more sense to me.
>
>
> ---------------------------------------------------------------------
> 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
Professional Tapestry training, mentoring, support
and project work. 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: [3.1] Engine deprecated
Posted by Jamie Orchard-Hays <ja...@dang.com>.
YES, PLEASE!!!!
On Jan 28, 2005, at 4:57 PM, Erik Hatcher wrote:
> That reminds me... can we invert the order of property source loading
> in 3.1? The inside-out philosophy of it drives me crazy. Ant
> property immutability-like rules make much more sense to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jan 28, 2005, at 3:22 PM, Howard Lewis Ship wrote:
> My question to the community ... how many people subclass BaseEngine,
> and for what reasons?
I have in every Tapestry application. In lucenebook.com, I override
activateExceptionPage (to log and throw a ServletException which I
manage at the container level).
In my day work, I override createVisit (to populate the Visit from some
cookies) and createGlobal (to instantiate it with a configuration
parameter from property source).
That reminds me... can we invert the order of property source loading
in 3.1? The inside-out philosophy of it drives me crazy. Ant property
immutability-like rules make much more sense to me.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [3.1] Engine deprecated
Posted by Howard Lewis Ship <hl...@gmail.com>.
So far, all of these use cases are covered, or will be, in the new paradigm.
In fact, for things like createVisit(), you will have the full power
of HiveMind to create and configure your objects if you wish (or just
specify a Java class name).
On Mon, 31 Jan 2005 10:16:35 +0000, Martin Gladdish
<ma...@egsgroup.com> wrote:
> Howard,
>
> I subclass BaseEngine to override createVisit(IRequestCycle cycle)
>
> I'm integrating Tapestry pages with an existing (large) JSP site, and
> need to initialise my Visit object with properties from the session.
>
> Martin Gladdish.
>
> On 28 Jan 2005, at 20:22, Howard Lewis Ship wrote:
>
> > The way I'm headed right now, the engine will be deprecated in a later
> > release of Tapestry.
> >
> > The engine has three main purposes:
> > 1. Runs the request cycle
> > 2. Allows different subsystems to locate each other
> > 3. Manages persistent application state
> >
> > Obviously, with all the HiveMind changes, the utility of the engine is
> > evaporating into a soup of HiveMind services and configurations. This
> > is good for lots of reasons, including plans to support the Portlet
> > API as well as the Servlet API.
> >
> > I'm nearly done with changes such that the engine is completely
> > divorced from persistent application state. The engine will no longer
> > be serializable or stored in the HttpSession. Each application state
> > object will be stored in the session under a unique key.
> >
> > What's an application state object? It's the visit object and the
> > global object. In 3.1, you can have as many as you want, stored in
> > whatever scope you want (application, session). You can even define
> > your own scopes. For backwards compatibility, visit and global will
> > be maintained (for a while).
> >
> > My question to the community ... how many people subclass BaseEngine,
> > and for what reasons?
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Jakarta Tapestry
> > Creator, Jakarta HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work. http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> >
> Martin Gladdish
> e-Government Solutions (UK) Ltd
> Tel: 020 7539 2823
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. 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: [3.1] Engine deprecated
Posted by Martin Gladdish <ma...@egsgroup.com>.
Howard,
I subclass BaseEngine to override createVisit(IRequestCycle cycle)
I'm integrating Tapestry pages with an existing (large) JSP site, and
need to initialise my Visit object with properties from the session.
Martin Gladdish.
On 28 Jan 2005, at 20:22, Howard Lewis Ship wrote:
> The way I'm headed right now, the engine will be deprecated in a later
> release of Tapestry.
>
> The engine has three main purposes:
> 1. Runs the request cycle
> 2. Allows different subsystems to locate each other
> 3. Manages persistent application state
>
> Obviously, with all the HiveMind changes, the utility of the engine is
> evaporating into a soup of HiveMind services and configurations. This
> is good for lots of reasons, including plans to support the Portlet
> API as well as the Servlet API.
>
> I'm nearly done with changes such that the engine is completely
> divorced from persistent application state. The engine will no longer
> be serializable or stored in the HttpSession. Each application state
> object will be stored in the session under a unique key.
>
> What's an application state object? It's the visit object and the
> global object. In 3.1, you can have as many as you want, stored in
> whatever scope you want (application, session). You can even define
> your own scopes. For backwards compatibility, visit and global will
> be maintained (for a while).
>
> My question to the community ... how many people subclass BaseEngine,
> and for what reasons?
>
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
Martin Gladdish
e-Government Solutions (UK) Ltd
Tel: 020 7539 2823