Martin Marinschek wrote:
Interesting!
as for the code generation issue:
are you aware that there is some code generation available in MyFaces?
The component getters and setters, as well as the state saving, can
automatically be generated...
how? except via eclipse, does not really matter, the codegens dont bring
you very far.
The main problem is, you have so many artefacts which are all error
problematic to create.
You need a tag class, you need a component class, you need a renderer
class, then you have the tld entries, you have the
faces-config entries which then can split into a renderer entry and a
component entry.
Abosolutely overkill if you have to write all that stuff yourself.
It might be interesting, though, to generate more than just the
component - are you willing to mentor such a project?
principially yes, but the main problem I have is, when should it be
how will the communication be done,
the other problem I have is, I only know xdoclet 1.x, what I did with
xdoclet so far is to use the templating mechanism in 1.x for the
creation of code artefacts upon existing classes, so if you dont mind to
do it in 1.0 and do not write a full plugin just a set of templates
and tags, of course.
xdoclet 1.0 however is slowly deprecated and not that good, and xdoclet
2.0 lacks severely documentation to get started without a good effort of
code reading :-(
the second one - Is that a part of the data-model implementation which
follows the specification, or is that an extended part? If we talk
about specification issues, we can't do anything different there I'd
say.
To me it is more the standard data model, I was banging my head against.
But you are right, there is nothing really which can be done in a summer
project, to much would have had to be reimplemented.
