copied these questions from HBX-747:
Quote:
you wrote:
>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.
That's exactly what I'd like to talk about (tell me if your means were different):
* The exporter is given a filepattern, which, in case of java classes generation, may imply a specific destination package.
yes and also any initial path so cannot be used as direct mapping to the package/classname.
Quote:
* 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
yes, i've thought about adding another mean of choosing between per-class or per-configuraiton generation.
Quote:
* 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).
not necessarily true.
Quote:
* 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).
for more flexible package/class names we would need more templating for the class name.
Quote:
* or to an model-wide tool, accessing whole hibernate class mapping. For example the DAOFactory from Christian Bauer (
http://www.hibernate.org/328.html).
yes?
Quote:
So, the java import context may well be different from the pojo context, whilst it may be related to.
yes, and what is the question exactly ? :)
Login
FAQ
Search
