[Middlegen-user] WL 7.00;

[Kyle F. Downey]

Good news:

- I tried it out with Ant 1.5 and WebLogic 7.00 and everything worked fine
with minimal changes (just basically added weblogic.jar to the PATH and
removed the fork="yes" line).
Feature request:

- attributes are converted to mixed-case with caps, but table names are
not, so beans end up with underscores- it would be great if you could indicate a table prefix to drop from the
Entity EJB names or even a regular expression to convert them
Infrastructure request:

- a rolled-up, non-CVS source bundle would be nice in addition to the
binary distribution on SourceForge; I can't access pserver-based CVS over
our firewall
Thanks! This is a great project.

--kd

[Aslak Hellesøy]

Hi kd,

-----Original Message-----
Downey
Sent: 5. august 2002 22:20
Subject: [Middlegen-user] WL 7.00;
- I tried it out with Ant 1.5 and WebLogic 7.00 and everything worked fine

I know ;-)

with minimal changes (just basically added weblogic.jar to the PATH and
removed the fork="yes" line).

In the CVS code you only have to edit middlegen/samples/build.properties. No
need to modify fork or PATH.

- attributes are converted to mixed-case with caps, but table names are
not, so beans end up with underscores- it would be great if you

Not in CVS they don't. I tried a YABBA_THE_HUT table (with HsqlDB) and a
bobba_the_fet table (with McKoi), and they become YabbaTheHut and
BobbaTheFet.

could indicate a table prefix to drop from the
Entity EJB names or even a regular expression to convert them

I don't know Regexp, but you're welcome to supply a patch. You could do it
easily by implementing your own subclass of DbNameConverter. See
FooBarConverter and its javadocs for more info.

- a rolled-up, non-CVS source bundle would be nice in addition to the
binary distribution on SourceForge; I can't access pserver-based CVS over
our firewall

Now you can! (See my other mail)

Thanks! This is a great project.

Thanks, I'll add you to my fan club ;-)

Aslak

--kd
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
middlegen-user mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-user

[Kyle F. Downey]

Post by Aslak Hellesøy
In the CVS code you only have to edit
middlegen/samples/build.properties. No need to modify fork or PATH.

Cool. Will try it out when I get home.

Post by Aslak Hellesøy

Post by Kyle F. Downey
- attributes are converted to mixed-case with caps, but table names
are not, so beans end up with underscores- it would be great if you

Not in CVS they don't. I tried a YABBA_THE_HUT table (with HsqlDB) and
a bobba_the_fet table (with McKoi), and they become YabbaTheHut and
BobbaTheFet.

I must have gotten confused, because even 1.0 does this correctly.

Post by Aslak Hellesøy

Post by Kyle F. Downey
could indicate a table prefix to drop from the
Entity EJB names or even a regular expression to convert them

I don't know Regexp, but you're welcome to supply a patch. You could do
it easily by implementing your own subclass of DbNameConverter. See
FooBarConverter and its javadocs for more info.

Okay, will do.

--kd

[Kyle F. Downey]

I'm about to head up a large, EJB2 based project internally here at HBO.
We've looked at a number of options, and thus far Middlegen looks like the
best bet for cutting down on the scut-work of implementing EJB2.
How do you handle (if at all):

1) creating calculated values based on other fields in an entity?
2) adding custom ejbSelects using EJB-QL?
3) enforcing constraints at the Entity EJB rather than the database level,
e.g. cascading vs. non-cascading deletes (referential integrity
constraints), or only allowing values > 0 for a field (value constraints)?
Also, if gui="no," how can you set up the directionality, etc.?

Looking through the source code that comes out, it looks like 85% of what
I'd want for a typical project--but I'd have to hand-edit the last 15% and
thus lose the auto-generation for subsequent schema changes.
Are people using middlegen as a fast start for EJB 2.0 development and
then completing the work by hand or are they using the generated code
exclusively? The comment about "Continuous Integration" seems to imply the
latter, but the data-centric nature of the generated code seems to imply
the former. It seems even a fairly sophisticated session facade on top
can't make up for missing custom queries (#2) even though it could make up
for a lack of #1 and #3 above.
--kd

[Aslak Hellesøy]

-----Original Message-----
Downey
Sent: 6. august 2002 00:32
Subject: [Middlegen-user] mixing in logic; workflow
I'm about to head up a large, EJB2 based project internally here at HBO.
We've looked at a number of options, and thus far Middlegen looks like the
best bet for cutting down on the scut-work of implementing EJB2.
1) creating calculated values based on other fields in an entity?
2) adding custom ejbSelects using EJB-QL?

Both: Use the merge feature. I just added new merge points where you can add
custom code.
You should be aware about this XDoclet bug related to select methods:
http://sourceforge.net/tracker/?group_id=31602&atid=402707&func=detail&aid=5
12180

3) enforcing constraints at the Entity EJB rather than the database level,

Please add an FR on SF's tracker for this:
http://sourceforge.net/tracker/?atid=415993&group_id=36044&func=browse
I'm thinking about GUI support for relations. When
you select a relation. you'll get a panel where cascade-delete (and possibly
other app-server

e.g. cascading vs. non-cascading deletes (referential integrity
constraints), or only allowing values > 0 for a field (value constraints)?
Also, if gui="no," how can you set up the directionality, etc.?

Run the GUI once and set directionality (possibly modifying cardinality
too). Your changes
will be persisted in an XML file, and subsequent invocations (with gui
disabled) will look
for settings in this file. This requires JDK 1.4, since this feature uses
java.util.prefs.

Looking through the source code that comes out, it looks like 85% of what
I'd want for a typical project--but I'd have to hand-edit the last 15% and
thus lose the auto-generation for subsequent schema changes.

With the new merge points and the future implementation of GUI support for
relations, you
should get up to 95% I think.

Are people using middlegen as a fast start for EJB 2.0 development and
then completing the work by hand or are they using the generated code

I don't know how people are using it really. I'd love to hear!

exclusively? The comment about "Continuous Integration" seems to imply the

We're not 100% there yet.

Aslak

latter, but the data-centric nature of the generated code seems to imply
the former. It seems even a fairly sophisticated session facade on top
can't make up for missing custom queries (#2) even though it could make up
for a lack of #1 and #3 above.
--kd
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
middlegen-user mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-user