On Mon, May 08, 2000 at 09:58:50AM -0700, jon * wrote:
> on 5/8/2000 8:32 AM, Sean Legassick <[EMAIL PROTECTED]> wrote:
>
> > This is a big win for me because I'm developing a very straight forward DB
> > front end but where I have a lot of different types of objects to manage,
> > and I don't want to have to rewrite the same controller logic over and over
> > again for each object type.
>
> that is why we have the Peer/DatabaseMap OR tools. this code can almost be
> fully autogenerated and subclassed.
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.
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 :)
> for example...take a look at some of my Scarab actions...this one is built
> taking advantage of the new ActionEvent system...
[snip code]
> nice and clean.
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 :)
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.
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.
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.
Sean
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
