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.
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.
>> 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.
>>> @why Trinidad doesn't work with annotations: how would you then
>>> generate restoreState and saveState? And the getters? You don't want
>>> to write all the getters by hand, do you?
>>>
>
> I'd be happy to see normal getter/setter methods in
> component/validator/converter classes. Yes, it is a little more code but it
> is *normal* code, that every java programmer can understand at a glance.
>
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.
> 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.
Hmm ....
Ciao,
Mario
