On Wed, Apr 9, 2008 at 1:15 AM, Miguel Munoz <[EMAIL PROTECTED]> wrote: > > > Matej Knopp-2 wrote: > > > > Also your approach wouldn't work for things like "property1.property2" > > where property 2 container type depends on result of property 1 > > evaluation. > > > > I can see how it's easy to assume that this can't work, but I tried it, and > I had no trouble at all making it work with chained properties. It works > fine with both getters and setters. There is one caveat: It works only if > the method can be written using direct calls without any casting. So, for > the property chain "student.major.adviser", if you can write this: > > Adviser adviser = thing.getStudent().getMajor().getAdviser(); > > then my approach works fine with property chaining. But if the statement > needs to look like this: > > Adviser adviser = > ((ThesisProject)thing.getStudent().getMajor()).getAdviser(); > > then my approach won't work. (I'm not sure if PropertyResolver will work in > this case, but I suspect it will.) And how is this different to what I've been saying? PropertyResolver will work. It has to. That's why we are caching individual classes only and not entire hierarchy.
-Matej > > > > ----- > There are 10 kinds of people: Those who know binary and those who don't. > -- > View this message in context: > http://www.nabble.com/PropertyResolver-redesign-tp16495644p16576062.html > > > Sent from the Wicket - Dev mailing list archive at Nabble.com. > > -- Resizable and reorderable grid components. http://www.inmethod.com
