-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 19 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Templates - Freemarker context, exporters and importContext
PostPosted: Sat Sep 02, 2006 12:42 pm 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
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:
Quote:
cfg = org.hibernate.mapping.Configuration
pojo = PojoClass
c2j = Cfg2JavaTool
c2h = Cfg2HbmTool
version = tool version number
date = DateTool
templates = used to e.g. create a file from a ftl template

importContext is something that is very much exporter and context dependent and not something that should be "global".
e.g. pojo's importContext is for that class and not for others. so if you need an additional importcontext you just create one.


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:
Code:
   public BasicPOJOClass(MetaAttributable ma, Cfg2JavaTool c2j) {

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

Code:
   public POJOClass getPOJOClass(Component comp) {
      return new ComponentPOJOClass(comp, this);
   }

   public POJOClass getPOJOClass(PersistentClass comp) {
      return new EntityPOJOClass(comp, this);
   }

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
Code:
public String asFinderArgumentList(Map parameterTypes, PersistentClass clazz);

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:
Code:
   public Cfg2JavaTool(String basePackage) {
      importContext = new ImportContextImpl(basePackage);

   }

Another one could be useful:
Code:
   public Cfg2JavaTool() {
      importContext = new NoopImportContext();
   }

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 1:03 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
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.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 1:38 pm 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
Quote:
the methods are not static because then they are not proper visible/available via freemarker etc.

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.

Quote:
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.


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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 1:42 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
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.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 1:57 pm 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
Quote:
furthermore if they are made static users can't redefine/inherit them which is the idea for most of the methods in the tooling.

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

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

and ? what benefit ?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 2:13 pm 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
what about :

Code:
   public Cfg2JavaTool(MetaAttributable clazz) {
      this(getPackageName(clazz));
   }


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 2:16 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
what benefit does it have to put the importcontext in c2j ? who would use that instead of just putting one in the context directly ?

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 2:36 pm 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
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:
Quote:
allowing to shorten class names relatively to *current* package, eventually different from pojo's.

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 ?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 4:44 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
Rocky Road wrote:
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 ;) ?


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.

Quote:
Let me quote myself again:
Quote:
allowing to shorten class names relatively to *current* package, eventually different from pojo's.



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!

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


if they put state into c2j then probably no ;)

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 6:07 pm 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
if c2j is intended to be subclassed, its role and responsability should be clearly stated.

for now it just looks like a hack.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 02, 2006 6:31 pm 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 03, 2006 1:44 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
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.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 03, 2006 1:46 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
Rocky Road wrote:
if c2j is intended to be subclassed, its role and responsability should be clearly stated.


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

Quote:
for now it just looks like a hack.


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

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 03, 2006 3:02 am 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
so you don't intend to fix HBX-748 ? You suggested me to open it !


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 03, 2006 3:33 am 
Newbie

Joined: Thu Aug 24, 2006 4:42 am
Posts: 15
Quote:
c2j is for "global" methods; e.g. how to get a java type out of a property etc.

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

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


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 ?


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.