Re: [Modeling-users] ModelMasons refactored

[Sebastien B. <sbi...@us...>]

so...@la... wrote:
> On Sun, Apr 20, 2003 at 06:24:35PM +0200, Sebastien Bigaret wrote:
> >=20
> > >   Next step on this will be to integrate the 'Base' generation-scheme,
> > >   as discussed earlier on the mailing-list (with a patch proposed by
> > >   soif).
>=20
>=20
> This is from my first tests. Little things that i don't really
> like :
>=20
> 1) As you proposed in the last discussion about this my previous patch do
>    something like that:
>=20
> mortal
> |-- Objects
> |   |-- Article.py
> |   |-- Base
> |   |   |-- ArticleBase.py
> |   |   |-- FolderBase.py
> |   |   |-- FolderBase.pyc
> |   |   |-- RssFeedBase.py
> |   |   |-- __init__.py
> |   |   `-- __init__.pyc
> |   |-- Folder.py
> |   |-- Folder.pyc
> |   |-- RssFeed.py
> |   |-- __init__.py
> |   |-- model_Mortal.py
> |   |-- model_Mortal.xml
> |   `-- setup.py
> `-- __init__.py
>=20
> as my package name is mortal.Objects, you can see that Base class
> are cleary separated from the class you work on.=20

Ok, seems reasonable.

Mario wrote:
> Just a minor comment, w.r.t. naming of the generated files/classes.
> I feel that:
>=20
> a) "Base" is probably not the best name extension to use, as it has
> a well-known generic meaning, and in addition it says nothing about
> the "volatility" of these generated files/classes. Better names would
> be something like "Auto" or "Gen" or "mdl" or "pom" or "morfy" ...

Reasonable too. What about 'Autogen'? Since we're going this way I guess
that models (xml/py) should be moved to that directory too, so that
everything that is overwritten when generating the code clearly falls in
the dedicated directory.

Mario> b) It is unnecessarily repeated -- what is the point of naming
Mario> all the classes in the "Base" sub-package also with "Base"?
Mario> Wouldn't it be more convenient to name only the sub-package? E.g.
       [...]

No problem; since we forget about 'Base' as a package it's a nonsense to
keep it here.

Back to Soif:
[...]
> This is from the CVS version=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> from FolderBase import FolderBase
> from Modeling.Validation import ValidationException
> from mx.DateTime import DateTimeFrom
>=20
> class Folder(FolderBase):=20
>   """
>   Folders are objects ...
>   """
>=20=20=20
>   def __init__(self):
>     "Initializer"
>     # Note: if you modify this method, it is a strong requirement that
>     # every parameter gets a default value, since the framework needs to =
be
>     # able to instanciate an object with no parameter at all.
>     FolderBase.__init__(self)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
>   --> from Modeling.Validation import ValidationException
>   --> from mx.DateTime import DateTimeFrom
>       twiced imported (in working and in base)=20
>=20
>    the __init__(self).. have a wrong comment isnt'it ?=20
>=20=20=20=20
> this isn't a big trick=20

-> mxDateTime: okay, this should be only in the AutoGen's modules
-> Validation: in the other one (w/ examples of validation methods)

About the initializer/its comment: let me think a little about
this... Mario just posted a question in relation and I have to
double-check some behaviour in the framework before answering.

> >=20
> > Inheritance:
> >=20
> >   The following inheritance hierarchy is generated for
> >   StoreEmployees.Employee/Executive:
> >=20
> >     EmployeeBase <--- Employee <---- ExecutiveBase <---- Executive
> >=20
> >=20=20=20
> >   I applied the old and new schemes to StoreEmployees and AuthorBooks, =
with
> >   success (tests OK). However, here again I'll appreciate if somebody
> >   interested in the topic could test and double-check with his own proj=
ect
> >   (Brad, Soif?)
>=20
> Hum I don't remember how my patch handle inheritance in fact . and i
> don't have a working inheritance here ...=20

There was a little pb in your patch since the ''base'' class was ignored
for an entity having a parent, no big deal.

  If we're okay on the points raised here (apart from initializer) I'll
  make the changes today.

-- S=E9bastien.