Thanks for the long response Howard, this sounds like great stuff overall. Couple of thoughts:
Concreteness: I do have one minor concern on the instance variable annotations. It sounds like T5 will bypass my getter/setters for annotated private variables. Since getters and setters can have additional logic besides the actual get and set of the field (dirty state tracking, for instance), how can I guarantee that it will be run when necessary. API: I think you're probably right that the new mechanisms will be better for me, I just hope it's not too late. By the time T5 is ready for production use, Zillow will have a pretty large and well-tested codebase against T4. It's unclear to me whether he benefits of T5 will outweigh the costs of a migration. I suppose that this is simply a plea for a well thought out and documented migration path, even if T5 is not backwards compatible. If it can be done with minimal pain, I'll be happy to use our testing facilities to prove that T5 is not a step backwards in performance or stability. jeff -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Sunday, February 26, 2006 9:06 PM To: Tapestry development Subject: Re: [Discuss]long - Tapestry 5 stuff. On 2/26/06, Jeff Lubetkin <[EMAIL PROTECTED]> wrote: > > - Concrete, not abstract, page and component classes > When bringing a new developer up to speed on Tapestry, I find that there are two areas that they immediately question, and require lots of explaining: abstract class proliferation, and exceptions for redirecting. Concrete classes would be a big help with the first (and queue-based rendering with the second). > > I do see one possible downside to concreteness. The enhancement process, before you understand it, looks like magic. Abstractness makes it obvious where the magic is happening...the abstract methods must turn into something, otherwise the class can never be instantiated. If the magic starts happening to my concrete methods, will it be obvious how and when they're going to change? Will concrete code that I write (say, property getter/setters) be overwritten by T5's enhancement process? In the end, I think I'd take a little confusion here over the current all abstract state of things, but it's something to consider. Most annotations will be in two areas. On (concrete) methods. On instance variables. Method annotations won't change the method, they just clue Tapestry 5 in to when and how Tapestry will invoke the method. The trick will be to describe to the application developer what parameters can be passed in and how (also, what values may be returned and how they are used). Basically, for each method invocation, there will be some amount of data that can be provided, via method parameters, to the method. Tapestry will "sniff" the method to see what parameter types are declared, and provide the appropriate data. I'm hoping it will not be necessary to annotation the parameters themselves, and you'll get errors or warnings when Tapestry can't find value to pass in to the method. It's not too disimilar to what Tapestry 4 does with listener methods. For instance variables, Tapestry will replace the instance variable accesses throughout the code with synthetic methods that, ultimately, access new instance variables. Initially, only private instance variables will be allowed to be annotated. If you have getter or setter methods for those instance variables, that's fine. Tapestry won't care, and won't build new accessors for you. For instance variables that are annotated as any kind of injection, Tapestry will create a writer method that will throw an exception. Tapestry won't use your accessor methods. It won't need to ... it will have backdoor access to everything, via constructors or other methods it adds to your classes. It will be a thing of beauty. > > - Change detection; automatic invalidate and reload of changed objects > > (including Java classes) > Please! We had a requirement to change our templates multiple times per-day, while under load. I ended up writing a replacement template and page loader that could handle this cleanly without simply flushing every cache in the system and bottlenecking. > > > - Vastly simplified API > > - Clear deliniation between public/stable and private/internal/unstable APIs > Noble idea, as long as the implementation of this doesn't make it any harder for me to replace or modify pieces of the infrastructure. One of the reasons I chose Tapestry for Zillow was that it had both 1) a well-written and commented codebase that I could mine and understand, and 2) I could relatively easily replace those pieces that I found wouldn't work for me. I really hope this continues. > I'm pretty sure that drawing clean lines will help you. The key to understanding an API is to limit what you have to see. I think that nearly all the API for Tapestry 5 will be annotations. Everything else will be internal. This will make it very easy to evolve the framework without breaking any existing code ... since annoations tend to be very declarative. > jeff > > -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
