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 _____
OmniaSoftware ® s.r.l. Fabio Collini (Analista Programmatore) Via Melloni, 29 - 50019 Sesto F.no (FI) Tel. 0554200158 <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] http://www.omniagroup.it/ _____ AVVISO DI RISERVATEZZA Il testo e gli eventuali documenti trasmessi contengono informazioni riservate al destinatario indicato. La seguente e-mail è confidenziale e la sua riservatezza è tutelata legalmente dalle normative vigenti. La lettura, copia od altro uso non autorizzato o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Se si ritiene di non essere il destinatario di questa mail, o se si è ricevuto questa mail per errore, si prega di darne immediata comunicazione al mittente e di provvedere immediatamente alla sua distruzione. Le dichiarazioni contenute nel presente messaggio, nonché nei suoi eventuali allegati, devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da Omnia Software s.r.l.; le medesime dichiarazioni non impegnano Omnia Software s.r.l. nei confronti del destinatario o di terzi. Omnia Software s.r.l. non si assume alcuna responsabilità per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. PRIVACY NOTICE The information contained in this transmittal, including any attachments hereto, are confidential and privileged, and intended solely for the specified addressee(s). This e-mail has a confidential nature which is protected by the Italian law. Moreover, the recipient(s) may not disclose, forward, or copy this e-mail or attachments, or any portion thereof, or permit the use of this information, by anyone not entitled to it, or in a way that may be damaging to the sender. If you are not the intended addressee, or if you receive this message by error, please notify the sender and delete this information from your computer. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of OMNIA SOFTWARE s.r.l. Besides, The contents of this message shall be understood as neither given nor endorsed by OMNIA SOFTWARE s.r.l. OMNIA SOFTWARE s.r.l. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof. _____ Da: Jeff Butler [mailto:[EMAIL PROTECTED] Inviato: martedì 28 agosto 2007 14.48 A: [email protected] Oggetto: Re: Abator factory extension - best practices Abator generates an anemic domain model. For this reason, I don't consider the Abator generated classes to be "domain" objects. Rather, I consider them to be low level transfer objects. In my use of Abator, I almost always develop a more rich domain model and then write a simple translation layer between my rich domain model and the Abator generated objects. I end up using the generated inserts, updates, and deletes quite frequently, the selects less so - because I can usually write a join query that more closely matches my rich domain model. This is kind of like the Hibernate usage pattern where there is a 1-1 mapping between objects and tables, with some higher level domain model and mapping layer. Of course, sometimes a "rich" domain object is close enough to a row in a table that the Abator generated object will suffice with a few modifications. In that case, I make heavy use of <columnOverride> to rename the columns so that the object looks more like a "real" domain object. I quite often add utility methods to the generated DAOs. These methods make use of the generated DAO methods and add more "business rule" value. For example, if I want a list of all open orders after a certain date, I can write a custom DAO method that makes use for the select by example functionality to find these records. I work in Eclipse exclusively - so I have no issue with modifying the classes generated by Abator. I'll re-run Abator many times during a development effort and Abator always saves any modifications I've made to the generated objects. If you're not using the Eclipse plugin, then I'd suggest doing a sub-classing strategy and not modifying the generated java objects. I'd love to hear how others are using Abator - these are just my experiences. As for your last question, I'm very open to improving Abator. I'd be interested to hear more about your ideas for an extensible factory. Jeff Butler On 8/28/07, Fabio Collini <[EMAIL PROTECTED]> wrote: Hello everyone, we are developers of a software factory working on a project using iBatis and the Spring framework and we have found Abator a wonderful tool that really speed up the work. We were wondering which was the best way to use Abator and eventually to extend it. For example: is it best to use Abator to generate mappings and model class only at the beginning and then modify them to fit our needs or use Abator to continually keep the mappings in sync with the database? In this second option how do we avoid to have an "anemic data model"? We thought about a layer of classes that uses the abator generated ones. It is the best choice? Another question is: could we have the option to make integrations and editings to the source code that could be integrated in the source code repository? The other option is: could we ask the Abator developers to add some minor changes to the source code, in particolar we feel to need to have an extendible factory able to generate the classes contained in the package org.apache.ibatis.abator.internal.db. Thank you for the good work bye _____ OmniaS oftware ® s.r.l. Fabio Collini (Analista Programmatore) Via Melloni, 29 - 50019 Sesto F.no (FI ) Tel. 0554200158 <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] http://www.omniagroup.it/ _____ AVVISO DI RISERVATEZZA Il testo e gli eventuali documenti trasmessi contengono informazioni riservate al destinatario indicato. La seguente e-mail è confidenziale e la sua riservatezza è tutelata legalmente dalle normative vigenti. La lettura, copia od altro uso non autorizzato o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Se si ritiene di non essere il destinatario di questa mail, o se si è ricevuto questa mail per errore, si prega di darne immediata comunicazione al mittente e di provvedere immediatamente alla sua distruzione. Le dichiarazioni contenute nel presente messaggio, nonché nei suoi eventuali allegati, devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da Omnia Software s.r.l.; le medesime dichiarazioni non impegnano Omnia Software s.r.l. nei confronti del destinatario o di terzi. Omnia Software s.r.l. non si assume alcuna responsabilità per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. PRIVACY NOTICE The information contained in this transmittal, including any attachments hereto, are confidential and privileged, and intended solely for the specified addressee(s). This e-mail has a confidential nature which is protected by the Italian law. Moreover, the recipient(s) may not disclose, forward, or copy this e-mail or attachments, or any portion thereof, or permit the use of this information, by anyone not entitled to it, or in a way that may be damaging to the sender. If you are not the intended addressee, or if you receive this message by error, please notify the sender and delete this information from your computer. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of OMNIA SOFTWARE s.r.l. Besides, The contents of this message shall be understood as neither given nor endorsed by OMNIA SOFTWARE s.r.l. OMNIA SOFTWARE s.r.l. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.
