[Modeling-users] Customizing autogenerated classes

[Brad B. <br...@bb...>]

Hello,

I sent this message to Sebastien who in his current busy state didn't
have much time to provide a complete answer today, but in the meantime
recommended I forward it on to the readers of the list.

Feel free to comment! :)

----- Forwarded message from Brad Bollenbach <br...@bb...> -----

Date: Wed, 26 Mar 2003 13:55:23 -0600
From: Brad Bollenbach <br...@bb...>
To: sbi...@us...
Subject: Customizing autogenerated classes

Hi Sebastien,

First off, the obligatory praise for giving the Modeling framework to
the Open Source community. It's not only cool and useful, but the code
is immensely instructive and well-written (IMHO)...so thanks. :)

Now, onto my question:

How do I customize the business logic validation routines without my
customizations getting blown away the next time I autogenerate the
Python package (e.g. when I decide two months down the line that the
app needs to be extended and five more tables need to be added)?

I've read through many of your unit tests, and a few relevant bits of
the code and come up with what I see being the four realistic options:

1. The obvious one: add code directly to autogenerated Python
code. The problem here though, is that it's difficult to do the whole
backup-and-merge dance when I autogenerate again in the future. It's
also tedious to take the other route of only exporting the XML model
every time, and maintaining the classes (and/or adding new ones, if
applicable) to keep up with it.

2. Write an adoption utility function, e.g. def adoptByClass(adopter,
entities) that will iterate over a list of entities (e.g. those
fetched from an editing context) and map them to the class specified
as the "adopter". The "adopter" could be a class that I've created
that inherits from one of the auto-generated classes and overrides its
validation methods with my custom logic. It's good because I can
autogenerate again and again, but it's bad because then I'm always
making calls to adoptByClass.

3. Manually validate (e.g. using MySQLdb directly). This would ignore
a significant piece of functionality that's already been created as
part of the Modeling framework, so this isn't reasonable.

4. Change an Entity's description so that it can have, perhaps both a
baseclass *and* class attribute, where the baseclass attribute is the
one that will get autogenerated and the class attribute is the only
that I will code myself, overriding and extending the baseclass's
methods as necessary.

From the point of view of the person that designed this framework,
what do you think of each of these options? Have I missed any?

----- End forwarded message -----

-- 
Brad Bollenbach
BBnet.ca