Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 68085 invoked from network); 28 Aug 2007 19:53:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Aug 2007 19:53:25 -0000 Received: (qmail 27866 invoked by uid 500); 28 Aug 2007 19:53:18 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 27844 invoked by uid 500); 28 Aug 2007 19:53:18 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 27833 invoked by uid 99); 28 Aug 2007 19:53:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 12:53:18 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jeffgbutler@gmail.com designates 66.249.92.169 as permitted sender) Received: from [66.249.92.169] (HELO ug-out-1314.google.com) (66.249.92.169) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 19:53:14 +0000 Received: by ug-out-1314.google.com with SMTP id h2so246436ugf for ; Tue, 28 Aug 2007 12:52:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uriyh5bXQ9puNwd015UxlFXXYpyOoJUjs+5HMgFsvGg0OGCzdTLu09H7w7FC5g8p7/ArCvg1XZOBYraFvdjWOjniSDbSzIw3lJOR1I931FiGmIBW0M98wWldQVUhgivtbnD/RSGyRox9YhoPTG1vpHdES51QsNs8f06HBWluysc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Sq5Lr6Xjh1OM4xjnsBL4OewT2W1ft3lWn9Fl1fqt/XqwLB8xWGMQkP82w/4C2Tddxtd+NXiaqyfNLYZh+6TQ/EpClt0WkDVpu0R7mRJgeXXFH1GocMNdcO4ZefHf1kdvq5tdg/wWy5Eq0ieEyQFNADFH0paAQPq1uQ3J6L7dpXM= Received: by 10.114.154.1 with SMTP id b1mr2821418wae.1188329148999; Tue, 28 Aug 2007 12:25:48 -0700 (PDT) Received: by 10.115.111.12 with HTTP; Tue, 28 Aug 2007 12:25:48 -0700 (PDT) Message-ID: Date: Tue, 28 Aug 2007 14:25:48 -0500 From: "Jeff Butler" To: user-java@ibatis.apache.org Subject: Re: R: Abator factory extension - best practices In-Reply-To: <20070828131910.2FDD6147145@mail.omniagroup.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_171694_19468641.1188329148947" References: <20070828131910.2FDD6147145@mail.omniagroup.it> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_171694_19468641.1188329148947 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Regarding protected get/set methods...this would be simple to implement on your own. Write a class that subclasses the appropriate JavaModelGenerator you are using, override the "generateClassParts" method, and then specify this class in the Abator configuration as the java model generator. If I were to implement this, I would likely do it as a property to the JavaModelGenerator rather than a column by column override. Seems to me that most folks would want the visibility set the same for every member - not needed on an individual basis. Also, this wouldn't require any DTD changes. But, because these are not "real" domain objects, I think it's kind of an unusual request. Anyone else have comments about this? Regarding the custom comment request, I have heard this request before. What if we did some kind of "CommentGenerator" interface that could be plugged in? Jeff Butler On 8/28/07, Fabio Collini wrote: > > Hello Jeff, > > thank you for your reply. We're glad to hear that the way > you suggest of using Abator is quite similar to what we were > thinking about. The idea of having some factory came > out from the need to generate pojos with properties (get and set) > protected. > > We thought to achieve this with the following steps: > > 1) add a new attribute, visibility, to the xml element "columnoverride" > 2) changing the DTD accordingly > 3) extend the class ColumnOverride to add the new property > 4) extend the AbatorConfigurationParser to handle > columnoverride.visibility property > 5) modify the bean generator to obtain bean with proptected getter/setter > > It's difficult to obtain this because there are explicit costructor > invocation > of the parser and of the ColumnOverride (for example inside the method > AbatorConfigurationParser.parseColumnOverride). > We thought that a factory for the parser and the ColumnOverride object > would solve this problem and make the design > more extendible. What do you think? > > Another question: is it possible to customize the behavior of the > bean/dao/sqlmap generators > so that you can specify your own comment to be inserted? A setComment > method? > > Thank you > Bye > ------=_Part_171694_19468641.1188329148947 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Regarding protected get/set methods...this would be simple to implement on your own.  Write a class that subclasses the appropriate JavaModelGenerator you are using, override the "generateClassParts" method, and then specify this class in the Abator configuration as the java model generator.
 
If I were to implement this, I would likely do it as a property to the JavaModelGenerator rather than a column by column override.  Seems to me that most folks would want the visibility set the same for every member - not needed on an individual basis.  Also, this wouldn't require any DTD changes.  But, because these are not "real" domain objects, I think it's kind of an unusual request.  Anyone else have comments about this?
 
Regarding the custom comment request, I have heard this request before.  What if we did some kind of "CommentGenerator" interface that could be plugged in?
 
Jeff Butler

 
On 8/28/07, Fabio Collini <fcollini@omniagroup.it> wrote:
Hello Jeff,
 
thank you for your reply. We're glad to hear that the way
you suggest of using Abator is quite similar to what we were
thinking about. The idea of having some factory came
out from the need to generate pojos with properties (get and set) protected.
 
We thought to achieve this with the following steps:
 
1) add a new attribute, visibility, to the xml element "columnoverride"
2) changing the DTD accordingly
3) extend the class ColumnOverride to add the new property
4) extend the AbatorConfigurationParser to handle columnoverride.visibility property
5) modify the bean generator to obtain bean with proptected getter/setter
 
It's difficult to obtain this because there are explicit costructor invocation
of the parser and of the ColumnOverride (for example inside the method AbatorConfigurationParser.parseColumnOverride).
We thought that a factory for the parser and the ColumnOverride object would solve this problem and make the design
more extendible. What do you think?
 
Another question: is it possible to customize the behavior of the bean/dao/sqlmap generators
so that you can specify your own comment to be inserted? A setComment method?
 
Thank you
Bye

------=_Part_171694_19468641.1188329148947--