Re: [Hibernate-devel] Doc Addition + some extra stuff

[Eric E. <ev...@pr...>]

>
> >Third, I'm a IDE kind of guy (OK, I'm a lite-weight) and I never do
> >*anything* using the command line.
>
>I've been thinking about whats involved in making a real GUI tool for
>editing mappings of late. Its not yet near the top of the TODO, but
>it might eventually bubble up there. First I would want to learn
>Eclipse's windowing toolkit (cos' I just hate Swing).
>
>Anyway, I was thinking along the lines of:
>
>1. A window that represents a mapping document visually as a tree and
>allows nodes to be edited in a properties pane.
>2. Menu items:
>(a) generate skeletal mapping from class(es)
>(b) generate class(se) from current mapping
>(c) generate skeletal mapping from database table(s)
>(d) export schema to database
>which would all open up dialog boxes (which would, in turn, delegate to
>our commandline tools).
>
>I must confess though, I've never written an actual GUI application
>in my life. Only commandline and web applications. So this would be a real
>learning experience for me. The one time I had contact with the Swing
>TreeView was painful and scared me off for life....
>
>In a sense this is really just a generic XML editor though. The only thing
>different is that we want to provide some explanatory metadata to nodes and
>attributes. (And the added menu-items which are trivial to do.)
>
>Does anyone know of any XML-editor-frameworks out there ;) hehe. Or
>something opensource that I could just take and bend to my own
>purposes?


Yeah, I had been thinking about this as well.  My ideal tool would extend 
the idea of Hibernate as a service all the way into the build process of 
the business model.  It would include:

-Easy to use editor as you describe
-Ability to set preferences such as default text field lengths, id field 
names, collection types, etc and store them in the generated .xml (or in a 
central file for global settings).
-Ability to automate the mapping and schema gen and include it in the 
business object build process.  If there is a previous version of the .xml 
file, use its values for mappings that haven't changed and use defaults for 
everything else.
-<dream-on>Ability to detect existing tables and generate Alter Table 
scripts that preserve db data</dream-on>

My *ideal* build process would then be:
-Implement a business model
-Do a rough Hibernate mapping w/ the editor
-Tweak the mapping w/ the editor
-Modify business model and rebuild project W/O losing mapping tweaks

One thing I can see happening in this scheme or any editor that saves state 
is that the dtd is going to have to make room for some fluff UI tags.

I had been using the data binding packages that came with JBuilder 
(DataExpress and dbSwing) for this type of work, but they seem to be 
extremely buggy and the source code is not available unless you've got cash 
to burn.  Lately, I've heard of several xml data binding strategies, but I 
haven't had a chance to check them out.  I would certainly be interested in 
pitching in on something like this - let me know when you would like to 
take a stab at it.



> > there is one hitch: The map gen tool creates a doctype declaration like
> > this:
> >
> ><!DOCTYPE hibernate-mapping SYSTEM "DTD_PATH/hibernate-mapping.dtd">
>
>urrrghhh yuck. Theres no good reason to use a SYSTEM ID now anyway.
>I will change this ASAP.

Great - thanks for the tweak.

Cheers,

Eric Everman