Re: [Modeling-users] Customizing autogenerated classes

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

On 03/27/03 12:18, Sebastien Bigaret wrote:

[wholesale snip]
 
> > 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?
> 
> 
> Following Mario's arguments, I don't think exposing a base class in the
> description of entities is a good idea; but that's a detail however,
> because the general idea of generating only baseclasses is the good one,
> and the one I use and recommend. Here are the details of the technique I
> currently use:
> 
>   Suppose we design a model AuthorBooks with entities Author and Books.
> 
>   1. design your model, name it 'AuthorBooksGeneration'
> 
>   2. design your entities, name them AuthorBase and BookBase
> 
>   3. generate the code: you get the package with the classes, plus
>      model_AuthorBooksGeneration.xml
> 
>   4. in the same package, write class Author in module Author.py:
> 
> ------------------------------------------------------------------------
> from AuthorBase import AuthorBase
> class Author(AuthorBase):
>   def __init__(self):
>     AuthorBase.__init__(self)
>     #...
> ------------------------------------------------------------------------
> 
>      Same for Book
> 
>   5. drop the compile_model_AuthorBooks.py included at the end of the
>      message in the package and execute it (adapt it to your own needs)
>      It produces a new model, AuthorBooks, pointing to the subclasses
>      Author and Book.
> 
>   6. Modify __init__.py so that the loaded model is AuthorBooks, not
>      AuthorBooksGeneration
> 
> 
>   Now you have classes Author and Book that won't be overriden when
>   generating your classes again, using the original model
>   AuthorBooksGeneration. The only thing you'll have to do after each
>   re-generation is step 5. & 6. --obviously you still need to backup
>   __init__.py if you added code to it.
 
Indeed. This seems like a reasonable and conveniently
backward-compatible solution. I'm pretty lazy though, so I'd like to
invest some time with others developing the framework's core to
automate this process and make it transparent to the user.
      
> *PLEASE* backup your work before giving it a try, I've no time by now to
> double-check that there is no risk at all and I do not want you to lose
> your work just because I forgot some points in the procedure...
> 
>   This technique demonstrates that the model is really used at runtime
>   to find out which classes it should use, here: not the base classes,
>   but the subclasses. This is somehow a derivation of the 1st FAQ entry
>   (section 2.6).

I agree that it's probably better to just Do The Right Thing, rather
than have the user care about having to define a bunch of baseclasses
in the model to avoid code destruction.

[snip]

> Further comments on this:
> soif> I think i will modify the bricks to handle this, during the week i
> soif> hope.
> 
>   Now I agree that this could/should be handled at generation time,
>   because this problem is a generic one. We should be able to offer the
>   users an example of such an architecture, as soif suggested it, with a
>   different python "brick". Soif, if you're going to study this maybe we
>   could discuss that a bit --I'll suggest however not to modify the
>   existing python brick, but to derive a new one for this purpose. For
>   example, the following code-generation process could be implemented:
> 
>   - take an existing model (no 'Generation', no 'Base'), say AuthorBooks,
> 
>   - modify it to generate AuthorBooks.Base.AuthorBase and BookBase,
>     where package AuthorBooks.Base is where live all the files that will
>     be overriden unconditionally when re-generating the model (including
>     the model) --we could simply use the existing python brick for that
>     purpose.
> 
>   - Last, generate the modules/subclasses Author & Book in package
>     AuthorBooks if and only if the modules do not already exists.
> 
> 
>   What do you think?
 
Works for me. :)

-- 
Brad Bollenbach
BBnet.ca