Return-Path: 
 <dev-return-33017-apmail-myfaces-dev-archive=myfaces.apache.org@myfaces.apache.org>
Delivered-To: apmail-myfaces-dev-archive@www.apache.org
Received: (qmail 679 invoked from network); 4 Jun 2008 20:36:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 4 Jun 2008 20:36:56 -0000
Received: (qmail 62987 invoked by uid 500); 4 Jun 2008 20:36:57 -0000
Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org
Received: (qmail 62943 invoked by uid 500); 4 Jun 2008 20:36:57 -0000
Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@myfaces.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@myfaces.apache.org>
List-Post: <mailto:dev@myfaces.apache.org>
List-Id: <dev.myfaces.apache.org>
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Delivered-To: mailing list dev@myfaces.apache.org
Received: (qmail 62932 invoked by uid 99); 4 Jun 2008 20:36:57 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2008 13:36:57 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [62.179.121.49] (HELO viefep31-int.chello.at) (62.179.121.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2008 20:36:07 +0000
Received: from [192.168.1.101] (really [84.113.196.60])
          by viefep31-int.chello.at
          (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP
          id <20080604203621.RWP7995.viefep31-int.chello.at@[192.168.1.101]>
          for <dev@myfaces.apache.org>; Wed, 4 Jun 2008 22:36:21 +0200
Subject: Re: myfaces-builder-plugin
From: simon <simon.kitching@chello.at>
To: MyFaces Development <dev@myfaces.apache.org>
In-Reply-To: <f6c92360806021805o5e429789vbc72daf7e32859f@mail.gmail.com>
References: <1212262989.9624.19.camel@simon-laptop>
	 <f6c92360805311426s17171856ud08a11015df6506b@mail.gmail.com>
	 <1212312797.11335.19.camel@simon-laptop>
	 <f6c92360806021805o5e429789vbc72daf7e32859f@mail.gmail.com>
Content-Type: text/plain
Date: Wed, 04 Jun 2008 22:36:21 +0200
Message-Id: <1212611781.6229.27.camel@simon-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org


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
>