Tapestry works by identifying the points at which a variable is read or updated and often replaces that with a method invocation that does something more complicated (such as persistent field values or component parameters).
If the field is private, Tapestry is able to make the changes within a single class. If we supported non-private members, it gets a couple of orders of magnitude more complicated. You can no longer perform the instrumentation on a class-by-class basic; instead you have to identify every possible class and perform all the instrumentations at once. This is more like how APT or AspectJ works and isn't feasible for Tapestry, since by design, many of the instrumentations are only known about, or implementable, at runtime. On 5/4/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
I hope that's not the only reason. ...The framework should be working hard - not the users. ;) On 5/4/07, Massimo Lusetti <[EMAIL PROTECTED]> wrote: > > On 5/4/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > I wonder why this is as well, it's happened at least a couple times now > - > > at least enough that this idea may need to be re-evaluated. (I can help > if > > it's just reflection stuff) > > This way the framework (inner javassist stuff) only need to 'scan' for > private instances. > > -- > Massimo > http://meridio.blogspot.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
-- 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
