My latest "I want" is a bit different from my earlier "I wants":
I want to reduce the number of little pieces parts I have to change
to alter the product. Lets say, for example, I want to add a new toolbar
button to one of my forms:
1) Step 1: Add the toolbar gif to the .jwc for the toolbar.
2) Step 2: Put @ImageSubmit on toolbar to reference button.
3) Step 3: Add listener to root page class.
4) Step 4: Modify toolbar .jwc to accept new listener as input.
5) Step 5: Modify all 20 forms where I use this toolbar component to
add the new listener to the input parameters.
That's a lot of pieces-parts I have to tweak to accomplish something
fairly trivial. Each individual step is easy (one of the benefits of
Tapestry), but the sum total is time consuming and error prone e.g. "doh, I
forgot to add the new listener to form x".
Maybe 4.0 offers some relief on this front, but for the last few
weeks, this has been the itch that's I've been scratching the most :).
--- Pat
> -----Original Message-----
> From: Vjeran Marcinko [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 02, 2005 7:50 AM
> To: Tapestry users
> Subject: Re: "Why I Like Annotations"
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
