Leonardo has been very creative here, and I like the approach. Applause!
regards, Martin On Feb 14, 2008 1:59 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > Hi > > > So to work around the "cannot use reflection on package-scoped class" > problem we discussed earlier, you are proposing to make the hand-written > class package-scoped, and generate a public concrete class? > > Yes. In many cases all properties are defined on the generated class, so > for this cases we can put package-scope to the hand written class. > > > That does solve the problem in many cases. But it means that the > hand-written class can never itself define any method in the public API. > Any code that it implements itself will be overridden by the generated > class. > > The solution is create abstract methods to get or set the values. The test > does not show > problems using this approach (using reflection to set or get values). I'm > not tested this > fully with tomahawk and myfaces, so I will test it and see what happens (I > don't believe > that we have problems, since testing this does not show errors) > > The fact is that if we put the generated class on top we should make this > class public. > So if we continue this approach we have to put all generated classes public. > > Putting the hand written class on top allow us to set this class package > scope, and let > the few cases with problems public. > > > That does solve the problem in many cases. But it means that the > hand-written class can never itself define any method in the public API. > Any code that it implements itself will be overridden by the generated > class. > > No if we use component-class-excluded and use an xml to reference the > property. That's what > I'm doing now. > > Any suggestions are welcome. > > regards > > Leonardo Uribe > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
