On Sat, Feb 14, 2009 at 3:53 AM, Thiago H. de Paula Figueiredo <thiag...@gmail.com> wrote: > On Fri, Feb 13, 2009 at 8:24 PM, manuel aldana <ald...@gmx.de> wrote: >> Why was the decision taken that fields must be private for @Property >> (security reasons, so fields can't be changed directly from default >> visibility -> package level)? From testing perspective this is not so nice. > > First of all, OOP recomends private fields for almost any situation. > Regarding @Property, I guess it was a implementation issue. All > Tapestry annotations must be put in private fields. If they could have > another visibility, Tapestry would have to locate all places that use > that field. If they're private, you only have to look at that class.
The AOP aspect of how Tapestry interacts with fields becomes infinitely more complex if you have non-private fields. I suspect that to support non-private fields, you would have to jettison live class reloading and perhaps add a build stage to do the necessary instrumenting. I'm happy with what I've got. In t.1 (and maybe 5.0.18), there are some utility methods on the TestBase class for setting private field values using reflection, suitable for use on non-instrumented classes as part of a test. > > If you use need field access outside the declaring class, use getters > and setters instead of @Property or create package-private methods for > testing purposes like Igor suggested. That's exactly what Tapestry > does in its components. > > -- > Thiago > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
