Vjeran, Why do you want spec to go away? F.e. we have some FormPage. It has some concrete DAO injected (f.e. AddressDao) and some TextFields. If we put them into annotations - all extending forms will have this garbage. Specifications give us a possibility to have page-specific data which we don't want to be extended.
Alex VM> Beside noding to all below ... my addition to "I want" statements: ;) VM> - I want confusing "abstract" keyword to go away, though from what I've read VM> on your blog some time ago about some benefits of that, it may never even VM> happen.... :-( VM> - I want page/component specifications to go away/optional since with 4.0 VM> and annotations I mostly only have page/component class specified in it VM> -V. VM> ----- Original Message ----- VM> From: "Howard Lewis Ship" <[EMAIL PROTECTED]> VM> To: "Tapestry users" <[email protected]> VM> Sent: Wednesday, November 02, 2005 4:16 PM VM> Subject: Re: "Why I Like Annotations" VM> My thoughts along these lines and the future fall along these lines: VM> Tapestry has too much API. I hope to tackle the worst offender, VM> extending from base classes, in 4.1. Even so, with teh tools we now VM> have (annotations, bytecode enhancement, IoC, OGNL, aspects), many of VM> the design decisions I made in January 2000 are out of date. Many VM> more work, luckily, pretty spot on and have stretched and grown with VM> the framework. VM> I want the Tapestry API to disappear as much as possible, using a mix VM> of annoations and conventions. VM> In fact, I want three levels of API: VM> API exposed to typical developers, with real backwards compatibility VM> XPI (Extension API) used more rarely by developers, to extend core VM> framework functionality. VM> SPI (Service Providider API) used internally, never exposed to the VM> user code, and subject to change on each release. VM> The first two would have strict backwards compatibility; the last VM> level would be internal and allowed to change from release to release. VM> The API and XPI should be as minimal as possible: interfaces, events VM> and event interfaces, a handful of exceptions, maybe a couple of VM> convienience base classes. The VM> Ultimately, I'd like to turn what is, today, a product into a specification. VM> I would like things to be more code-oriented; I would like XML to be VM> an add-on, used only in rare cases. VM> I would like a way of having libraries without namespaces. VM> I want templates to be XML documents (so that the parser can handle VM> encoding!) using namespaces for Tapestry elements and attributes. I VM> want how components are used to determine what they do more. VM> I want page names and component ids to be class names, or directly VM> mapped to classes. The current Rube Goldberg machine that is giving VM> Geoff fits is an artifact of an earlier and, I think, invalid version VM> of Tapestry. It makes Hello World code-free at the expense of causing VM> some chaos for real apps. VM> More than that, I'm thinking that the framework needs to embrace Ajax VM> and Ajax-techniques head on. VM> I'm still working my head around how you can keep a Tapestry like VM> approach, including Block/RenderBlock and other highly dynamic things, VM> but be able to easily render just portions of a page. VM> .... but right now, I just want to get 4.0 finished and out the door. VM> 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] >> >> VM> -- VM> Howard M. Lewis Ship VM> Independent J2EE / Open-Source Java Consultant VM> Creator, Jakarta Tapestry VM> Creator, Jakarta HiveMind VM> Professional Tapestry training, mentoring, support VM> and project work. http://howardlewisship.com VM> --------------------------------------------------------------------- VM> To unsubscribe, e-mail: VM> [EMAIL PROTECTED] VM> For additional commands, e-mail: VM> [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
