But a lot of this presupposes that the method names are going to change, which they are not (with the new committment to backwards compatibility).
On 12/21/06, D&J Gredler <[EMAIL PROTECTED]> wrote:
Comments inline: On 12/21/06, Massimo Lusetti <[EMAIL PROTECTED]> wrote: > > On 12/21/06, D&J Gredler <[EMAIL PROTECTED]> wrote: > > > Massimo - > > > > I'm talking about things like quickly finding all the places you hook > into > > the SetupRender / BeginRender / xxx phase, automatically refactoring > these > > methods up or down a level, etc, all without requiring intimate > knowledge of > > the framework or project. Kent and Jeff have made this point elsewhere > in > > this thread. > > Couldn't this be achieved by you have your own interface and/or base > classes? Yep, but this thread is about the framework defaults. We're not just talking about "I want to do this" or "he needs to do that", we're talking "this is the option that will save hundreds of developers thousands of hours in the aggregate". I just happen to be one of those developers ;-) > I like the "convention over configuration" approach, but is flagging a > > method with an annotation really configuration? Maybe, but barely. > You're > > asking people to code in Java (rather than Python or Ruby or Groovy), > but > > you want them to (partially) give up some of the biggest benefits of > > strongly-typed languages. That sounds like an uphill battle to me. I > think > > you're going to have to be very clear with the users on what benefits > they > > can expect to see in exchange for this sacrifice. > > > > The obvious answer, of course, is that users do not have to make this > > sacrifice if they do not wish to, since they will always have the option > of > > flagging their methods with annotations. I'd argue, however, that (a) > > requiring the developer to make this choice initially, and (b) requiring > him > > to continue to be aware of both options, possibly mixing them, is much > more > > of a cognitive load on the developer than just requiring him to flag his > > methods with annotations. "Convention over configuration" isn't an end > in > > and of itself, it's a means to an end -- namely the ease of use that > leads > > to lower development costs and higher quality. > > I've to admit I've had the same feeling as you about loosing some > compile time checks, but as long as there's still Annotation based i > feel safe. > At the end i think that if you want to work with a framework or > library you should first know as much as you can about it, even if you > work in a team, there should be a person which is in charge of knowing > that specific part of the whole project, so i don't consider valid > statements the ones like "all without requiring intimate knowledge of > the framework or project.". I simply don't find it feasible :) As far as I'm concerned, that's the utopian goal, and the closer Tapestry is to achieving it, the better off we all are. Take care, Daniel
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
