I am
new to Middlegen and I really enjoy using it and looking at the code. It suits our organization�s way of
working. I look forward to its
continued improvement.
I
address these suggestions to the user list as opposed to the �suggested
features� page since I�m such a new user and may be ignorant of the presence
of certain features.
First
I�d like to be able to include a table for viewing in the GUI, but not
generated. This would be perfect
for �M:N join tables.� I have
such a table in my project now which I need to manually (in ant, anyway)
delete after it�s generated. The
presence of an Entity bean for this table makes my MVCSoft Persistence Manager
(CMP 2.0 engine) very unhappy.
This feature could be accessed from within the table element of the
middlegen task: <table
name=�EntityRole� generate=�false�>
Naturally, the default would be �true.� You could also access it from the
�table panel� in the GUI via a checkbox.
Next,
I�d like to know if it would be OK to allow the user to pick java.util.Date in
lieu of a java.sql class in the �Java type combo� in the �property
panel�. I�d like to take
advantage of the fact that CMP insulates me from the java.sql package. I�ll be using java.util.Date in my
front end and DTOs, why not drive it through to the Entity bean? Is there something I�m missing
here? Have I been doing it
wrong?!
Currently
the preferences.xml file contains a lot of good information. I was actually dragging and pointing
and clicking on all my tables every time I tested my template (I�m working on
an MVC-centric CMP 20 template).
If the users and developers feel it�s appropriate, it may be nice to
save the x and y values of the upper left corner of each of those tables in
the preferences file as well. It
would be a real time saver for those of us with a lot of related
tables.
Speaking
of the preferences file, I have an Entity for which I need to assign the
primary key property�s Java Type to �long� (MVC needs it this way). This is reflected in the preferences
file, but when I ran the middlegen GUI again, the property�s type was back to
java.lang.Integer. Might be a
bug, there.
Sorry
about the long message, but I�ve accrued a lot of comments in the last four
days. Back to
work!
Dean
Des Rosiers
