on 5/8/2000 11:26 AM, Sean Legassick <[EMAIL PROTECTED]> wrote:
> Indeed - I've got a dirty perl script that generates Obj/ObjPeer classes for
> me from a short spec file. At the moment it's far too much of a kludge to
> be useful to anyone else, but I have been thinking about redoing it properly,
> i.e. written in Java, driven by the db map XML file etc.
I already did this...
look in the map package.
GenerateMapBuilderTask.java and MySQLSchemaToDatabaseMap.java. Doing
OracleSchemaToDatabaseMap.java would be trivial...
in fact, doing any sort of parser here is trivial, the point is to build a
functional and defined DatabaseMap in memory and then output it in some
way...
> In fact your WebMacroEmail gave me an idea for this - I knew doing it
> properly would have to mean Java not Perl, but how to do the text generation
> without loads of string buffer hassle? Of couse - WebMacro could even do this!
> Not sure if I'll have a chance to spend time on this soon though as my dirty
> perl is working for me right now :)
Na...look at the code above...it works very well. I'm using it to generate
the database maps for Scarab's 47 tables now. it even builds the javadoc.
:-) Since it isn't done in a servlet, but is more just code generation,
speed isn't important...although just for metrics, the code above generates
the classes for the 47 tables in about 1.5 seconds tops.
I even wrote up some documentation for it...yes, i need to move this over to
Turbine's documentation at some point...
<http://scarab.tigris.org/generate_mapbuilders.html>
> Definitely - I hadn't looked at scarab before, but I've checked it out now
> and there's definitely some nice up-to-date examples of how to write good
> Turbine code in there. Cool stuff :)
bingo. :-) it will be the next poster child. :-) after i'm done with scarab,
i will go back and re-do Jyve to use the same techniques (unless someone
beats me to it of course... :-)).
> However this is a good example of what I was saying. The overall logic of
> the UpdatePermission action is applicable to pretty much any kind of data
> object (delete/edit/save functionality) but if I've got 15 types of data
> object I've got to write 15 UpdateXXX action classes. Granted at least
> with ActionEvent that's 15, not 15 * <number of form buttons>, which is cool
> in and of itself, but if I want to add a new button to every one of these
> forms (I dunno, say a 'Rollback to last version' button) then that's 15
> classes to make identical modifications to.
right, but i don't see that as a bad thing because in web applications like
scarab, almost every single page has some sort of twerk that makes it
slightly different from the next one.
> What I'm trying to design is a structure where I write one UpdateDataObject
> action and pass in as a POST parameter which class of data object I operate
> on.
> That's what I wanted ParameterParser.setProperties for. Of course it all
> depends what one is doing, like I said my interface is pretty much a straight
> DB front end so the functionality *is* pretty much identical across all types
> of data object.
In that case, then what you are doing is perfect. If you can generalize it
and make it re-usable enough, please consider contributing it.
> If I was dealing with less types of data and more variance in functionality
> then this would be overengineering and I would do things more your way with
> specific action classes dealing with specific types of data.
right...and that is the direction i feel i need to go right now in order to
have the most amount of flexibility on a page-by-page basis. it is not that
hard to go back later and generalize things because you are simply removing
duplication, but IMHO it is harder to un-generalize things because that is
adding stuff. :-)
thanks,
-jon
--
Java Servlet Based - Open Source | Collab.Net
Bug/Issue Tracking System |
<http://scarab.tigris.org/> | <http://Collab.Net/jobs/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
