myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <simon.kitch...@chello.at>
Subject Re: myfaces-builder-plugin
Date Wed, 04 Jun 2008 20:36:21 GMT

On Mon, 2008-06-02 at 20:05 -0500, Leonardo Uribe wrote:
> 
> 
> On Sun, Jun 1, 2008 at 4:33 AM, simon <simon.kitching@chello.at>
> wrote:
<stuff about template vs subclass modes removed>
>         
>         By the way, what does the JSFComponent.parent attribute do?

> In conclusion, "superClass" and "parent" are different concepts.
> "parent" is a component defined on the model, so the component defined
> by @JSFComponent annotation inherits properties. "superClass" is used
> in the template.

If I understand this right, there are now two quite different concepts
of inheritance:

(a) inheriting logical sets of jsf properties
(b) normal java inheritance (inheriting type and methods)

If this is the case, then I think it is the wrong way to go.

We need this plugin to be *simple* and *understandable*, both for people
who use it and people who maintain it. Otherwise the code will bitrot
and die, just like all the previous attempts at code generation. No-one
maintained the original myfaces generator, and it is now dead. *You*
have a good understanding of the trinidad-faces-plugin, but just about
no-one else does. And MyFaces shouldn't be in a place where it depends
entirely on you for its continued existence.

That's why using *normal* java inheritance to drive the meta-data makes
sense. It's something that every Java programmer understands.

This templating stuff is unfortunately necessary, due to the TCK rules.
But I think it would be best to still emphasise the other ways of using
the builder *first*, then make this templating stuff an "extra". Unlike
the way it currently is, where templating is effectively the default and
you have to explicitly set superClass in order to use the more easily
understandable subclass-generation approach.

And setting up a completely separate concept of inheritance in order to
group JSFProperty definitions seems a really bad idea. It seems that
this was introduced only to solve problems in Tomahawk. So maybe that
means that some Tomahawk class hierarchies are actually wrong. If we
need to introduce a couple of new interfaces that existing classes
implement, or insert some new abstract base classes into existing
components to fix what are currently broken hierarchies, then let's do
that rather than hacking up the builder plugin to use some concept of
inheritance that is NOT normal java inheritance.

Regards,
Simon
> 


Mime
View raw message