Beside noding to all below ... my addition to "I want" statements: ;)
- I want confusing "abstract" keyword to go away, though from what I've read
on your blog some time ago about some benefits of that, it may never even
happen.... :-(
- I want page/component specifications to go away/optional since with 4.0
and annotations I mostly only have page/component class specified in it
-V.
----- Original Message -----
From: "Howard Lewis Ship" <[EMAIL PROTECTED]>
To: "Tapestry users" <[email protected]>
Sent: Wednesday, November 02, 2005 4:16 PM
Subject: Re: "Why I Like Annotations"
My thoughts along these lines and the future fall along these lines:
Tapestry has too much API. I hope to tackle the worst offender,
extending from base classes, in 4.1. Even so, with teh tools we now
have (annotations, bytecode enhancement, IoC, OGNL, aspects), many of
the design decisions I made in January 2000 are out of date. Many
more work, luckily, pretty spot on and have stretched and grown with
the framework.
I want the Tapestry API to disappear as much as possible, using a mix
of annoations and conventions.
In fact, I want three levels of API:
API exposed to typical developers, with real backwards compatibility
XPI (Extension API) used more rarely by developers, to extend core
framework functionality.
SPI (Service Providider API) used internally, never exposed to the
user code, and subject to change on each release.
The first two would have strict backwards compatibility; the last
level would be internal and allowed to change from release to release.
The API and XPI should be as minimal as possible: interfaces, events
and event interfaces, a handful of exceptions, maybe a couple of
convienience base classes. The
Ultimately, I'd like to turn what is, today, a product into a specification.
I would like things to be more code-oriented; I would like XML to be
an add-on, used only in rare cases.
I would like a way of having libraries without namespaces.
I want templates to be XML documents (so that the parser can handle
encoding!) using namespaces for Tapestry elements and attributes. I
want how components are used to determine what they do more.
I want page names and component ids to be class names, or directly
mapped to classes. The current Rube Goldberg machine that is giving
Geoff fits is an artifact of an earlier and, I think, invalid version
of Tapestry. It makes Hello World code-free at the expense of causing
some chaos for real apps.
More than that, I'm thinking that the framework needs to embrace Ajax
and Ajax-techniques head on.
I'm still working my head around how you can keep a Tapestry like
approach, including Block/RenderBlock and other highly dynamic things,
but be able to easily render just portions of a page.
.... but right now, I just want to get 4.0 finished and out the door.
On 11/2/05, Geoff Longman <[EMAIL PROTECTED]> wrote:
My opinion is that the decision to F&$K backwards compatibility is
moot at this point for Tap4. We are too far down the road to RC now.
Any migration tool development that may need to begin would be
starting many many months (a year?) behind the development of T4. T4
has benefitted greatly from months of user feedback, any migration
tool built now would be greatly disadvantaged by not having the same
benefit.
Make the decision and announce that fact for T 4.1 or 5.0 or whatever
the next version will be called. Then it's up front and plain to see
before coding even starts and the discussion/development of migration
strategies, tools, whatever can proceed in parallel.
I think that T both benefits from, and is hurt by it's free form
development methodology. The benefits are obvious as T can change much
faster than the "spec'ed" frameworks can. And that is no barrier to
adoption for the coding junkies like me. But widespread adoption is
hurt if compatibility is broken without a clearly defined way, in
place and bulletproof, to migrate because bigger shops will be loathe
to move to T if they are not sure that they can move with T in the
future.
Make plan, stan, and mitigate the risks to adoption.
Geoff
On 11/2/05, Richard Clark <[EMAIL PROTECTED]> wrote:
>
> On Nov 1, 2005, at 15:55, Howard Lewis Ship wrote:
>
> > Well, if we can get enough of the community to say "Howard! Build us
> > something better, and F**K backwards compatibility!" then I can do
> > that, and maybe just a little bit more :-)
>
> The reality is that if you want to keep serious commercial customers
> (those showcase apps that drive adoption), you need a fairly
> straightforward way to migrate to new platform releases. That could
> be by building a compatibility layer, by keeping "backward
> compatibility", or by a source-to-source translation mechanism.
>
> Right now, the update for the largest app I'm working on would be a
> bit of a stretch, but is doable (and there are aspects of T4 that we
> could use to clean up some inelegant code.) But if the answer was "we
> can't upgrade, and there's no support anymore for what we are using",
> there'd be trouble.
>
> ...R
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Announcement Feed:
http://www.jroller.com/rss/glongman?catname=/Announcements
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31.10.2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
