Hi all,

Please forgive me for this long post, I hope it can be useful yet.

While talking about the freemarker datamodel provided for use in templates (in JIRA), max wrote:


I'll try to list a few use cases for (ant) hbmtemplate tool
(tell me if where I'm wrong):

• The exporter is given a filepattern, which, in case of java classes generation, may imply a specific destination package.
  
• The template may be applied to differents contexts, each related to a mapped class; this is actually specified by using the "{class-name}" marker in the file pattern
  
• the template may be dedicated to the pojo class definition. Then the destination package is specified in the hibernate mapping (the tool output directory being considered as an element of the classpath).
  
• or (dao example) class-dependant tools, which may be located in different package than the pojo, but maybe related to it (this would be the role of the "{package-name}" marker).
  
• or to an model-wide tool, accessing whole hibernate class mapping. For example the DAOFactory from Christian Bauer (http://www.hibernate.org/328.html).

So, the java import context may well be different from the pojo context, whilst it may be related to.

Now, here's what I understood (from the source code) for the tools we have:

• cfg = org.hibernate.mapping.Configuration
  This gives access to global hibernate configuration as well as individual mappings.
  
• c2j = Cfg2JavaTool
  This provides some methods to help writing java code.
  But since it has no attribute, all methods could as well be static, except ...
  see later ...
• pojo = PojoClass
  This wraps the mapped class or component from cfg, providing some more java-helpers. Amongst others, it holds an importContext attribute,
  which is refered to for the importType() and generateImports() features.
  It is initialized with the mapped class package.
  

I don't understand the semantics of the relationship between Cfg2JavaTool and PojoClass:
The BasicPOJOClass holds an instance of this (attribute-less) Cfg2JavaTool class, which has to be supplied by constructor:

Further, the only non-"static"-able, or instance-dependant, methods of Cfg2JavaTool are those POJOClass factories:


Thus, most Cfg2JavaTool methods could be made static, and the POJOClass could as well drop the association and call class methods instead, couldn't it ?

I believe this state is due to historical reasons; thanks to the hibernate team, the project's code is living :)

*But*, I thought that since the Cfg2JavaTool() class was providing some java type related methods, like

it could as well be the home for the importContext, allowing to shorten class names relatively to *current* package, eventually different from pojo's.
The PojoClass could as well relay the importContext-related methods to its associated c2j.

I tried it, providing a new constructor:

Another one could be useful:
But dangerous as well, because it hides the problem of restoring the default behavior: use the mapped class package.

So the patch is not complete, but I'd like your opinion.

Congratulations for reading ;)

Michelle Baert
Brest, France

the methods are not static because then they are not proper visible/available via freemarker etc.

it would actually be good if only one cg2java were around to hand out the exporter "scoped" PojoClass and ComponentClass opposed to the "always create new instance" everytime.

This is not obvious in my freemarker doc (related to v 2.3.8, maybe featuring interesting improvement since the 2.3.4 you use). I didn't try.



I'm afraid I don't understand. Could you be more explicit ?

it is not obvious but static methods are not without troubles ( i think it might be ok, but you have to toggle a flag or something)


furthermore if they are made static users can't redefine/inherit them which is the idea for most of the methods in the tooling.

everytime you call c2j.getPojoClass(pc) you get a new instance everytime instead of the same instance used within one exporter run.

That what I imagined. Anyway it is not the point, if we associate the importContext to it.


and ? what benefit ?

what about :

what benefit does it have to put the importcontext in c2j ? who would use that instead of just putting one in the context directly ?

Cfg2JavaTool holds many methods related to java types e.g. for building argument list. If types are class names, they are candidates for "importing".
And "java.lang.String" replaced with "String" remember ;) ?

Let me quote myself again:

Also, if you want to restrict users to generate class in the pojo package, just put it clearly.

Anyway the changes I made in my copy are soon compilable and testable.
Are you interested ?

yes, and as i said, put the context as an argument and problem is solved.

Or create a "dao" variable that does it for you.



Yes, but that does not imply c2j should have an importcontext; just that there should be a *another* one you use for your dao's!



if they put state into c2j then probably no ;)

if c2j is intended to be subclassed, its role and responsability should be clearly stated.

for now it just looks like a hack.

You're just telling me I'm wrong, not why you are right instead. No use.
You should know your code better than me.

I believe importContext was in c2j in earlier version, but has moved to BasicPOJOClass for a quick bug fix.

no it was not moved there for a quick fix, it was moved there because it made sense ;)

why does it make sense ? because a template can generate more than *one* file and you should be able to seperate their importcontext's.

And for pojo generation the $pojo is the natural place for a import context to be.

For dao it might make sense to move some of the dao-only methods from c2j to a $dao class together with an importcontext.

c2j is for "global" methods; e.g. how to get a java type out of a property etc.

the *goal* is to allow that or at least allow you to replace it with something that does things differently.



yes and that is why i haven't clearly stated anything in the docs about it.

so you don't intend to fix HBX-748 ? You suggested me to open it !

So why is a specific instance associated with each pojo instance , and required by constructors ?



Do you mean to copy and specialize those "global" methods ??
Also when dao needs to refer to pojo class, it doesn't change its own context ... and pojo's context-related methods become wrong ! should they be copied too ?