---- Mario Ivankovits <[EMAIL PROTECTED]> schrieb:
> Hi Simon!
>
> First, my intention was/is to find a solution. I don't think that we
> manage to create an all new generator stuff. We had plenty of time in
> the past to make this thing fly, but failed.
Only two attempts have been made. And the fact that people didn't stick with
the old generator possibly means that it just wasn't the right solution.
> So, while I'd really support your idea about a annotation driven
> generator, I don't think that we will see it even in the mid future. We
> all have too much work to do - and unhappily no time.
Yeah, where's that time-machine :-)
>
> >> can you investigate into the suggestion by Mario - I think this will
> >> be even better (and easier to achieve) then generating the components
> >> into the source-tree, as the old MyFaces component generator did.
> >>
> >
> > 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.
> >
> For sure, I thought we can generate the stuff and then commit the
> generated files, so no need to regenerate for each build, just when
> something in the component config changed.
Ah - so you mean effectively going back to the old myfaces 1.1 solution, where
the generated classes get written into the *source* tree (not the target tree)
and are then checked in to svn? And that only when the base configuration
changes do new source files need to be generated and checked in?
Yes, I could live with that. Still intimidating for making API changes, but at
least normal bugfixing works in the usual manner.
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 :-(.
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.
> 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.
>
> 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...
>
> > 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.
Sigh, not enough hours in the day..
Cheers, Simon
