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/03/30 19:50:28 UTC
3.0 to 3.1 transition
Although the release number (3.1? 4.0?) is still up in the air, I've
made some changes to ease the transition from 3.0 to 3.1.
IRequestCycle.getRequestContext() is back.
RequestContext is back in a more limited form (all the stuff about
cookies and parameters is gone, it's just a wrapper for access ot
HttpSession, HttpServletRequest and HttpServletResponse).
AbstractComponent.getSpecification() and AbstractComponent.getMessages()
are concrete again, meaning that BaseComponent and BasePage (and
subclasses thereof) don't have to be abstract unless they define
abstract methods (in other words, back to 3.0 status quo).
--
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.0 to 3.1 transition
Posted by Howard Lewis Ship <hl...@gmail.com>.
As I've said, I have a plan, but it's big! My vision is that page and
component classes will be loaded by a special class loader that will
re-write the classes on the fly, adding and removing fields and even
methods (for read-only propreties). There's a lot of magic to do, and
it will mostly be driven by annotations.
On Wed, 30 Mar 2005 13:34:56 -0500, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> On Mar 30, 2005, at 12:50 PM, Howard Lewis Ship wrote:
> > Although the release number (3.1? 4.0?) is still up in the air, I've
> > made some changes to ease the transition from 3.0 to 3.1.
> >
> > IRequestCycle.getRequestContext() is back.
> > RequestContext is back in a more limited form (all the stuff about
> > cookies and parameters is gone, it's just a wrapper for access ot
> > HttpSession, HttpServletRequest and HttpServletResponse).
>
> Is there an issue with bringing it all back?
>
> > AbstractComponent.getSpecification() and
> > AbstractComponent.getMessages()
> > are concrete again, meaning that BaseComponent and BasePage (and
> > subclasses thereof) don't have to be abstract unless they define
> > abstract methods (in other words, back to 3.0 status quo).
>
> Yay!!!
>
> Now if we can just do away with the abstract silliness altogether I'll
> be ecstatic!
>
> Erik
>
> ---------------------------------------------------------------------
> 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.0 to 3.1 transition - deprecations?
Posted by Richard Lewis-Shell <rl...@mac.com>.
>> Although the release number (3.1? 4.0?) is still up in the air, I've
>> made some changes to ease the transition from 3.0 to 3.1.
>>
>> IRequestCycle.getRequestContext() is back.
>> RequestContext is back in a more limited form (all the stuff about
>> cookies and parameters is gone, it's just a wrapper for access ot
>> HttpSession, HttpServletRequest and HttpServletResponse).
>
> Is there an issue with bringing it all back?
It sounds to me (and please correct me if I'm wrong) like there are now
'better' ways of getting at what was in the RequestContext - can all the
methods be brought back as Erik suggests, but with RequestContext
deprecated so that for the next release +1 they can be removed
completely without causing shock/panic in the community?
I guess the more general suggestion is that where possible, API things
that are on the chopping block go through a deprecation cycle for 3.1.
Perhaps the 'I' interface prefixes could be deprecated also?
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: 3.0 to 3.1 transition
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Mar 30, 2005, at 12:50 PM, Howard Lewis Ship wrote:
> Although the release number (3.1? 4.0?) is still up in the air, I've
> made some changes to ease the transition from 3.0 to 3.1.
>
> IRequestCycle.getRequestContext() is back.
> RequestContext is back in a more limited form (all the stuff about
> cookies and parameters is gone, it's just a wrapper for access ot
> HttpSession, HttpServletRequest and HttpServletResponse).
Is there an issue with bringing it all back?
> AbstractComponent.getSpecification() and
> AbstractComponent.getMessages()
> are concrete again, meaning that BaseComponent and BasePage (and
> subclasses thereof) don't have to be abstract unless they define
> abstract methods (in other words, back to 3.0 status quo).
Yay!!!
Now if we can just do away with the abstract silliness altogether I'll
be ecstatic!
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org