tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <br...@transmorphix.com>
Subject Re: Tapestry 3.1 compatibility with 3.0?
Date Sat, 26 Mar 2005 02:11:01 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I believe this type of 'safety net' would be the best approach. I've
been looking at the two barriers for wider adoption that have been
brought up and how they are really of the same cause: 'why adopt now if
things are going to be incompatible soon', and 'we need more robust
components' (or more components, or whatever phrasing you choose to
use). This was my primary motivation with 'make it deprecated'. As you
said, Tapestry can't wait to be 'perfect' - and this long between
releases is too long. We all know there will be bugs, and we all know
where Tapestry 'can' go to be closer to 'perfect', but if we can chop up
~ the work into managable units, it seems like it shouldn't be necessary
to wait so long between releasing 'not entirely new, but definitely
improved' code.

What about... [donning flame retardant suit and praying readers read
every version number through a cloud of wine and merriment] (and this
only lists the 'vision' points from "Next Generation"/"POJO" list)

3.1
Improve all code to be streamlined but leave the original API intact
with deprecation notices where appropriate, leave original functionality
where API isn't the problem. ['safety net']
Remove anything useless

3.2
Use ClassLoader/bytecode enhancement to convert page and component
POJOs into Tapestry-aware classes on the fly (like JDO, but at
runtime) If it's not possible pre 1.5, hold off until 4.0+
Remove anything useless

4.0
Change all the naming, WITH care for backwards compatibility -
deprecate/document
JDK 1.5 - as much as I'd personally love this now, I know it isn't
viable across the board and 'across the board' is where I'd like to see
Tapestry going
Servlet API 2.3? 2.4? Required.
Remove anything useless

4.1
No page or component specs!  Just annotations.  (Or specs optional)
Remove anything useless

5.0
Fix all the naming, with no care for backwards compatibility
Remove anything useless

Hope this isn't just noise, but I'd really like to see releases and
adoption of the technology going faster and in lieu of generating more
hours in a day, cutting down what's in a release and holding on to user
processes is about the only way.

Howard Lewis Ship wrote:
| On the side of compromise:
|
| Restore IRequestCycle.getRequestContext().  Supply a streamline
| RequestContext for gaining access to the HttpServletRequest,
| HttpServletResponse.
|
| Convert AbstractComponent getMessages() and getComponentId() into
| concrete implementations (that return null).  The enhancement
| operation will *override* these implementations (instead of suppling
| implementations for the abstract methods).
|
| In other words, create a "safety net" for 3.0 -> 3.1.
|
| I don't think Tapestry can wait to build the "perfect" technology.
| Tapestry 3.1 has already  taken a year longer than I'd have liked.
| Progress has been rapid and radical of late, but it would be much
| better to stabilize 3.1 and start building super components for it.
|
| Looks like Erik and I are in aggreement, except possibly for the
| number (I still prefer 3.1 to 4.0).  If the numbering is very
| important, put it to a vote.
|
| As I've been thinking of Tapestry 4.0/5.0 (aka Tapestry POJO, aka
| Tapestry Next Generation) I've been thinking we should go WHOLE HOG:
| - JDK 1.5 required
| - Servlet API 2.3? 2.4? Required
| - No page or component specs!  Just annotations.  (Or specs optional).
| - Use ClassLoader/bytecode enhancement to convert page and component
| POJOs into Tapestry-aware classes on the fly (like JDO, but at
| runtime)
| - Fix all the naming, with no care for backwards compatibility
| - Remove anything useless
|
| On Tue, 22 Mar 2005 20:27:00 -0600, Brian K. Wallace
| <brian@transmorphix.com> wrote:
|
| So I'm not the only one that had a Tapestry X thought run through his
| head. ;-)
|
| +1 to a future past 4.0 :-)  *whispers of 'roadmap' through the trees*
|
| Erik Hatcher wrote:
| | Geez Howard.... you ask me to bring it to the dev list, then you blog it
| | up rather than discuss here (and misspell my name several times!).
| |
| | You're getting very hung up on this 4.0 version number thing.... the
| | changes you've made already cause 3.0 apps to require refactoring, and
| | the improvements are dramatic and make it worth it I think.  But there
| | is no need to feel like you have to toss in the kitchen sink just for a
| | label "4.0".  What's wrong with Tapestry 5.0 with the peer and smarter
| | defaults and all that you mention?  The sooner we get to Tapestry X  the
| | better anyway :)
| |
| |     Erik
| |
| |
| | On Mar 22, 2005, at 8:19 PM, Geoff Longman wrote:
| |
| |> Howard just blogged that if the numbering is bumped to 4.0 then he
| |> wants to make even more radical changes. Is this really necessary?
| |> Seems to me that the current set of features is plenty good without
| |> adding more.
| |>
| |> Geoff
| |>
| |>
| |>
| |> On Tue, 22 Mar 2005 10:54:36 -0500, Colin Sampaleanu
| |> <colinml1@exis.com> wrote:
| |>
| |>> +1 on calling it 4.0. This is what I suggested in a thread a month or
| |>> two ago. I just don't see how, given the common perception of what
a 3.0
| |>> to 3.1 release means, that it would be at all appropriate unless
the new
| |>> code was completely or almost completely backwards compatible,
which is
| |>> not the case here. I actually don't see what the big deal is about
| |>> calling it 4.0. It's a major release, with lots of new functionality.
| |>>
| |>> Regards,
| |>> Colin
| |>>
| |>> Erik Hatcher wrote:
| |>>
| |>>> I've been building a new application from scratch using Tapestry 3.1
| |>>> built from CVS (I'll refresh it every few days as commits mandate to
| |>>> stay current).  I've encountered a few things that caused me to
adjust
| |>>> my code.  I see some of these items as pretty big barriers for folks
| |>>> adopting 3.1 sooner rather than later or never.  Pleasantly
Howard has
| |>>> made the 3.0 DTD's work just fine, but I've been converting to using
| |>>> the 3.1-style of specification files in order to learn the new way.
| |>>>
| |>>> The big things I've encountered are:
| |>>>
| |>>>     - classes extending from BasePage must be made abstract, whereas
| |>>> this was not the case in 3.0.  The whole abstract thing has been
a pet
| |>>> peeve of mine for ages and I try to avoid it by using
| |>>> setProperty/getProperty instead of making abstract
getters/setters.  I
| |>>> like that my IDE can allow me to automatically add methods when I add
| |>>> a new interface, but having the class abstract prevents this and adds
| |>>> to the run-time error possibilities.
| |>>>
| |>>>     - IRequestCycle API has changed so that HttpServletRequest is not
| |>>> accessible from it.  I understand the reason for the change, but my
| |>>> apps do leverage that capability in 3.0.
| |>>>
| |>>> If we're going to make these types of incompatibilities then
shouldn't
| |>>> we call this new version 4.0 instead?
| |>>>
| |>>> I have been IM'ing with Howard when I encounter these barriers,
and he
| |>>> suggested I bring these items to the dev list.
| |>>>
| |>>> What do others feel about how compatible 3.1 should be with 3.0?
| |>>>
| |>>>     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
| |
| |
| |
| | ---------------------------------------------------------------------
| | 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





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCRMS1aCoPKRow/gARAmf0AKCVY+usynzW4I5CogJyOtUPQYly5wCg5oif
eBvM69QdXgBpoyo+tW/lQnI=
=+MYs
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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