whew. thanks for the clarification. I think that's the way to do it for sure.
Geoff On 4/28/06, James Carman <[EMAIL PROTECTED]> wrote:
Okay, my Tapestry 5 warm fuzzy feelings have returned. -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Friday, April 28, 2006 11:41 AM To: Tapestry development Subject: Re: AspectJ and T5 Absolutely! AspectJ will be part of the internal implementation of Tapestry. I'm using it (so far) to enforce basic coding standards and contracts, and to simplify code related to thread synchronization. However, Tapestry 5 applications will not use AspectJ. AspectJ will need to be on the runtime classpath, but Tapestry 5 applications will not ever have to see it. Tapestry 5 application code will not be transformed or weaved or whatever by AspectJ. Tapestry 4 performs aspect oriented operations when it creates an "enhanced" subclass. Tapestry 5 will do something similar, except that it transforms the class as it is loaded. But this Tapestry AOP support is internal to Tapestry (driven entirely off of annotations in Tapestry 5). This is part of the very careful split between Tapestry internal implementation and Tapestry application development, something that's all merged together in Tapestry 4. The goal I'm following is that only the absolute minimum necessary is exposed in the public space. Much of the code is and will be in the org.apache.tapestry.internal package, with the message "hands off" ... even though there will likely be a lot of tested, reusable code in there. Tapestry needs the freedom to change its internals at any time, without breaking any outside code. I may eventually split tapestry-core into a pure API library (mostly annotations, plus a scattering of interfaces and classes), and a seperate implementation library. On 4/27/06, James Carman <[EMAIL PROTECTED]> wrote: > Yes, please don't make us use AspectJ to develop in tapestry. I don't > care if you want to use AspectJ behind the scenes to implement Tapestry, > but please don't make us have to weave aspects into our classes to get > stuff done. Also, we need to figure out how to allow HiveMind to support > aspects the way Spring does. I don't think it's going to be difficult. I > just haven't had the time to sit down and code it up. > > > http://howardlewisship.com/blog/2006/04/gambling-on-aspectj.html > > > > It's a gamble for sure. > > > > Pls reassure me that my 9 team members will never have to look at, > > learn, or understand anything about AspectJ to use T5. Ie. it will be > > am implementation detail of T5 and not a "feature". Also, that any > > mention of AspectJ will relegated to an "appendix" in the > > documentation for T5 that 99.9999% of Tapestry 5 users can ignore. > > > > Geoff > > > > -- -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache 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]
-- The Spindle guy. http://spindle.sf.net Blog: http://jroller.com/page/glongman Other interests: http://www.squidoo.com/spaceelevator/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
