[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-752?page=co... ] Max Rydahl Andersen commented on HBX-752: ----------------------------------------- i'm not super keen on having this since it encourages to put code in the templates...especially code that also require some context (e.g. what is the generated field name and the name or the setter argument). I know we have extra-class code attribute but it does not rely on any context, so is more harmless. ...i don't call the current solution "brute-force" since it feels like the just correct level of customization is there for you to do these things without any problems. in other words, unless someone submits a patch or i bump into an extremely good and widely used usecase for this i'm not going to work on it in the the near future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-752?page=co... ] David Leal commented on HBX-752: -------------------------------- Max and other, With the Max help I have found the solution via template modification, you can see the discussion on forum about that: http://forum.hibernate.org/viewtopic.php?t=964523#2321689 any way this solution, on my opinion has some disavantages: 1. If you have n-pre/post conditions for your classes, you have to define at least n meta-properties. 2. All such preconditions are agglutinated on a template file, so when some one looks into *.hbm file (usually we work on in a team), he/she has to assume that such property is used on a template file (another sintax language: free marker and understand it), unless you document at every place, please look into the following template file in order to finally see what precondition is that. 3. The *.hbm files therefore are not self consistent, you have to look also into some additional template file in order to understand your business particularity about setting a given property, your business is located also on a template file. Now about my approach: 1. You don't have to define n-meta properties if hibernatetools provides the properties: pre-condition, post-condition. 2. All your busines is defined on: *.hbm file. It is self consistent. 3. It is a natural extension to meta attribute class-code, but for the methods. 4. You can add your pre/post condition using only Java, you don't need to know FreeMarker for adding so simple modification to the generated code. 5. It seems to be easy to implement, in a similar way to getExtraClassCode()} method. Note: I can see the contains of POJOClass.java on: http://anonhibernate.labs.jboss.com/trunk/HibernateExt/tools/src/java/org... you get an HTML file instead of java) It is more a conceptual issue about the hibernate tools philosofy rather than a tecnical limitation about implementing this feature. On my opinion if you open the door in order to allow users can add additional source code for classes you should consider also the posibility of adding some minimal modification to the accessor methods (for example pre/post conditions, assert conditions, etc) Thanks for your interest on my suggestion, David P.D.: If I have persuaded to you, it seems to be a hard task, :-), please let me know how to help your for the implementation. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira