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]
