Discussion:
[Middlegen-user] what's up?
a***@netcom.no
2001-12-18 22:03:02 UTC
Permalink
hello

just a short message to tell you i have by no means abandoned middlegen, but
been busy with xdoclet development (the new xjavadoc module. see xdoclet
devel list for more info).

my next major plan for middlegen is to make it generate the various gui
configuration panels from an xml based file. this file will contain the
required information to build proper gui. this xml file will be
automatically generated during the building of the xdoclet sources. i'm
planning to add special @tags to the xdoclet sources and use xdoclet itself
to generate the xml file required by middlegen.

i'm also waiting for hsqldb (sf project, tiny java based RDBMS) to provide
proper metadata support, so i can include a sample database with relations
in the distro. makes it easier to get up to speed with middlegen.

if anybody has thoughts and comments about this, please comment.

aslak
a***@netcom.no
2001-12-19 12:13:02 UTC
Permalink
Hi!
The stuff you describe sounds interesting, could you elaborate on
these GUI
panels? Are these middlegen pannels or end-user application pannels ?
I was thinking about middlegen panels. XDoclet is moving ahead very fast,
and it's difficult to keep up whith what it has to offer. (EJB, App servers,
Struts, Webwork, JMX...). Lately a lot of new xdoclet tags have been added,
and middlegen doesn't know about them, or is maybe even incompatible. If
XDoclet can provide meta info about what tags it supports in a meta-info
fashion (some XML format we'll have to design), Middlegen could create its
configuration GUI panels based on that information. That means when somebody
adds xdoclet support for, say pramati's App server, Middlegen would
instantly know how to generate a gui that lets modify the pramati tags. This
would be fantastic!
Will xjavadoc give us some possibility to implement merging of
the generated
code? I thought I read about XML based representation of the xdoclet
metadata, that would simplify source code merging process. Merging would
definitely be great.
Merging of the generated code with what? xjavadoc will provide an API like
getClass( "foo.Bar" ).getMethod( "hello" ).appendComment( "@mytag blabla" );
or getClass( "foo.Bar" ).appendMethod( "public void doIt() {
System.out.println( \"hello\"); } " );

Xjavadoc will have classic javadoc-like functionality (already has that)
with code mutation support (will be added soon). You can add comments,
fields and methods to exisitng code.
What I am missing from middlegen (except of merging) is slightly
different.
Maybe I will be successful in making someone interested and getting
I am trying to extend the middlegen functionality to also
generate jsp pages
for editing and browsing db tables. In short middlegen with
doclet would be
able to generate complete (although quite dumb) db application: jsp pages,
struts forms, and persistence using ejb cmp. I need it for the
application
I am writing. This would be roughly equivalent of what Oracle
Forms or Power
I think XDoclet would do the job of generating jsps better than middlegen.
It's a powerful code generation engine. Middlegen isn't. Basically I want
middlegen to generate as little source code as possible. It should primarily
be a tool used to insert more tags into existing code and let XDoclet
generate the rest, like for example jsps or taglibs. For your case, this
would mean inserting some @jsp tags into the entity bean's source, and write
an XDoclet template to do the jsp generation.

Middlegen will also be used for other types of classes than entity beans.
The entity bean java code generation will not insert any tags at all. The
tag insertion will be done afterwards, in the same fashion as with any other
class that can have xdoclet tags in it. The keywords here are xjavadoc and
the automatically generated panels.
Builder used to provide out of the box. I somehow feel that in case of the
small db applications J2EE is big step back from C/S days. Small
application
you could develop in .5 day on C/S tools can take a week in the J2EE.
Granted that J2EE was designed to address different problems, but nowadays
most organizations standarize on J2EE and use it for everything.
Michael
----- Original Message -----
Sent: Tuesday, December 18, 2001 7:00 PM
Subject: [Middlegen-user] what's up?
Post by a***@netcom.no
hello
just a short message to tell you i have by no means abandoned middlegen,
but
Post by a***@netcom.no
been busy with xdoclet development (the new xjavadoc module. see xdoclet
devel list for more info).
my next major plan for middlegen is to make it generate the various gui
configuration panels from an xml based file. this file will contain the
required information to build proper gui. this xml file will be
automatically generated during the building of the xdoclet sources. i'm
itself
Post by a***@netcom.no
to generate the xml file required by middlegen.
i'm also waiting for hsqldb (sf project, tiny java based RDBMS)
to provide
Post by a***@netcom.no
proper metadata support, so i can include a sample database
with relations
Post by a***@netcom.no
in the distro. makes it easier to get up to speed with middlegen.
if anybody has thoughts and comments about this, please comment.
aslak
_______________________________________________
middlegen-user mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-user
a***@netcom.no
2001-12-19 12:17:05 UTC
Permalink
It's a good idea.

-But you'd have to provide some defaults. Right now I'm doing that with
system properties, which is rather nasty. Do you have an opinion about a
better way to provide these defaults? I'm talking about JDBC url, whether or
not to use automatic pk generation, ..... anything that middlegen can't
possibly make an assumption about. Maybe a simple properties file would do?

Aslak
-----Original Message-----
Sent: 19. desember 2001 03:08
Subject: RE: [Middlegen-user] what's up?
A really nice thing would be to be able to script everything
rather than having to go through the GUI.
Jeff Finger
Loading...