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]
