> > > IMO, the best solution is where the code checked in to svn *compiles*.
> IDE auto-completion, refactoring, all the other tools that work only with
> *real* code will then be usable again.
> > >
Ok, why not have the generated base-classes in the source of your compiler?
> However as Martin(?) noted, we cannot change the inheritance hierarchy of
> classes in the api package. And that is where the majority of the problem
> classes are :-(.
for tomahawk, this is not true.
> NB: I'm much less concerned about generated tag classes. People generally do
> not need to debug them, and the rest of the JSF classes compile fine when
> they do not exist.
they too could be in the source tree
> > I am not 100% sure if the typical (if member is not null/else get
> > ValueExpression) is still required, but if it is it is worth generating
> > it, no?
> > On the other hand, with generics and the ValueExpression it should be
> > possible to encapsulate this in a simple utility method.
even without generics, you can write a few simple utility-methods -
still it is easier for them to be generated
> > Said that, I have absolutely no problems in writing them by hand ... or
> > ... to say the truth, let the IDE generate them.
>
> Copy and paste have always worked well for me...
wow, great, you both agree on the value of copy-and-paste reuse ;))
> >
> > > The save and restore state stuff is a bit trickier. Yes, it would be
> nice to avoid writing that by hand as it is error-prone. Personally I would
> be *satisfied* (although not happy) to see the system just *verify*
> hand-written code, if that meant that the stuff checked in to svn is real
> normal compilable code. However I think that some better solution can be
> made, eg by writing
> > >
> > > protected Object[] saveState() {
> > > return StateHelper.saveState(this.getClass());
> > > }
> > >
> > I think it should be
> >
> > StateHelper.saveState(this);
> >
> > as you need access to the state of the current object ;-)
> > Anyway, this requires you to break into the class as you have to call
> setAccessible on the private member fields of the component. I see some
> problems with various installed Security-Managers, at least, I'd not assume
> to being able to make them accessible.
>
> Yes, accessing private properties directly is awkward. But maybe we could
> use the existing getter/setter methods, and have them behave differently
> depending on whether we are in save or restore phase, allowing the local
> data to always be accessed. If we provided a standard helper for property
> accessing, that could be nicely encapsulated. Or maybe generate a
> package-scoped helper class which is needed at runtime, but not at
> compile-time. Again, just hand-waving.
sorry guys - but this discussion is so brrrr.... both code and
performance-wise. Then I would rather change over to the way Trinidad
is doing things (state saved in a map), this would also help with
state-saving.
regards,
Martin
