[
http://opensource.atlassian.com/projects/hibernate/browse/HBX-747?page=co...
]
Michelle Baert commented on HBX-747:
------------------------------------
Thanks for your answer (may be HBX-746 should be deleted then ?)
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.
* 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.
Do you see a path to achieve this?
Exporters : Clarify template context and classes responsabilities
-----------------------------------------------------------------
Key: HBX-747
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HBX-747
Project: Hibernate Tools
Type: Task
Reporter: Michelle Baert
As you said in HBX-745, there's an importContext problem again when trying to use the
query parameter types
from templates.
I built another exporter with an ImportContext field added, and automatic destination
package detection, and tried to see if it couldn't be done directly in Generic
Exporter.
It arises that through the exportClasses() method, the destination package may change
from one mapped class to another.
But difficulties come when confusion is made between referred mapped class and newly
generated referring class.
The freemarker datamodel is filled with tons of properties, objects and methods for which
it is very difficult to find out which deals with what.
My (sub)project of building new templates leads to reverse engineer alone too much of the
*uncommented* code of the actual release.
Maybe defining classes responsabilities could lead to some changes in project
architecture, and allow to clean-up many work-arounds, but, ;) , this is not *my* role .
But it should worth it :)
Best regards,
Michelle Baert
--
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