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
