Re: [Modeling-users] Customizing autogenerated classes

[Mario R. <ma...@ru...>]

Hi there,

> 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 also have the same question, and so I suggest that a recommendation
of how this is best handled should be added to the users guide...

> 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.

I feel this (4) would be the better way to go. However, I would suggest
_not_ to expose baseclass of the Entity, i.e. each Entity will have
a private basecalss that is regenerated each time. The declared class
will be generated if it does not exist (or if overwrite is specified), 
but
is not overwritten otherwise. Simpler, instead of inventing private
baseclass names for declared classes, just have a private "sub-package"
to the declared package, e.g. _mdl. And in that package have the
always-regenerated base classes -- using the same class names
declared in the model.

mario

> -- 
> Brad Bollenbach
> BBnet.ca
>