Hi all,
Mario Ivankovits napsal(a):
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.
I was probably last to "play" with old generator (in Tomahawk core), but
it was VERY painful with the current components' code.
After providing patch to JIRA it was said that old generator is
abandoned in favor to new maven-gen.
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.
This was "core" of the original generator - generating code inline way
and commiting resulting, generated files to SVN.
New maven based generator is IMO great for Trinidad and MyFaces Core
1.2, but it will fail badly for few Tomahawk's components in their
current form :(
@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.
Shouldn't it be possible to get ALL object members through the spec's
internal HashMap ( method getAttributes() of
javax.faces.component.UIComponentBase) ?
To extend that - why don't JSF implementationS use that map at all?
(it's being serialized by default AND it's documentation states that
properties can be used WITHOUT setter/getter pair)
Zdenek
Hmm ....
Ciao,
Mario
