Re: specifying objects' class

        Hi,

  Your claim is understandable, and indeed, even when using cvs,
frequent re-generation of modules and thus, frequent merge to keep the
busineess logic in generated files can be a real pain.

  That's the reason why the -B switch exists in the script
  mdl_generate_python_code.py ;)  Extracted for the --help:

<< 'base' scheme: adds a sub-module 'MDL' within the generated package. All
       files within MDL/ are ALWAYS overwritten when the python code is
       regenerated, while others (in the root package) are never overwritten
       if they exist.  This is probably the one you want to use if your model
       changes often. >>

So with the 'base' generation scheme you'll be able to have the business
logic in a module with the generated stuff in an other one, separated,
just as you describe (except that you'll get the business logic in
package 'luca', and the mdl stuff in sub-package 'luca.MDL').

  About the point on how classes are retrieved at run-time: this is
  described here:
  http://modeling.sourceforge.net/UserGuide/faq-change-class-location.html
  This basically mean that the classes are searched from the information
  enclosed in the model --and the model at runtime needs not be the
  exact same one than the model that is used for generation (esp.
  regarding the package, module and class' names).

A little remark: this is a little different than just inheriting from
the mdl-generated class: when inheritance comes in, e.g. for Employee
deriving from Person, you don't want to have:

    Employee <|-- EmployeeBase
                      ^
                     /_\
                      |
                      |
      Person <|-- PersonBase.

  rather you want:

    Employee <|-- EmployeeBase <|-- Person <|-- PersonBase

  so that Employee inherits from the business-logic defined in Person,
  as expected.


Last, you might be interested in testing the dynamic creation of
classes. It is available through patch #814055 at:
https://sourceforge.net/tracker/index.php?func=detail&aid=814055&group_id=58935&atid=489337

and has been discussed there:
https://sourceforge.net/mailarchive/forum.php?thread_id=3151927&forum_id=10674
https://sourceforge.net/mailarchive/forum.php?thread_id=3233626&forum_id=10674
https://sourceforge.net/mailarchive/forum.php?thread_id=3239464&forum_id=10674

  Shortly said, this means no code-generation, with the ability to just
  define your business logic, with the mdl-specific stuff automatically
  generated at runtime (you'll want to use the metaclass approach
  then).  Additionally, new-style classes makes things run quicker ;)
  Note that while this is not integrated into the main trunk yet, this
  will shortly be. In fact, it should already be there, if only I have
  had the time for it...

-- Sébastien.


John Lenton <[email protected]> wrote:
> Hi all again.
> 
> We'll be using Modeling for a large(ish) database shortly, and we'd
> like to have to make minimal changes to the generated files, to
> minimize the work required upon a schema change, given that we'll
> probably have a lot of them during the initial developement.
> 
> In other words, we'd like to be able to put the business logic in one
> tree ('luca', for example), and have the Modeling stuff in another
> tree ('mdl'), with any given class in luca inheriting from its par in
> mdl. That's pretty easy to do, except that we're concerned that things
> like
> 
>    person.getAddresses()
> 
> (to borrow from Sample) would return objects from the 'mdl' tree, and
> not our own.
> 
> Maybe we're just being too lazy, but we fear that, if we don't find a
> way to do this at least semi-automagically, the worked involved will
> be tedious, and thus error-prone.
> 
> -- 
> John Lenton ([email protected]) -- Random fortune:
> 25 de Diciembre, Doom, Doom, Doom.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn