modeling-users — For users: questions, support, announcements, etc.

Re: [Modeling-users] ModelMasons refactored

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

On mardi, avr 22, 2003, at 15:15 Europe/Amsterdam, Mario Ruggier wrote:
> On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret 
> wrote:
>> Mario Ruggier <ma...@ru...> writes:

[snip]

>>>> BTW: Mario proposed that the generated class initializer could be:
>>>>>   def __init__(self,att1=None,att2=None):
>>>> instead of
>>>>>   def __init__(self):
>>>>
>>>>   Are we ok we go for it?

A propos de previous post on KeyValueCoding names -- this proposition
lacks a minor thing, and that is inside the __init__ body, the 
attribute values
should be set using KeyValueCoding, not to bypass any custom code
in the get/set methods for each attribute.

Additional proposal ;)
How about adding __slots__ to all custom objects?
It seems to me that this is exactly the kind of usage that this was
intended for, and will reduce memory usage for cases of *many*
instances of custom objects. Works only for 2.2, but if present should
not affect 2.1 instances in any way.

mario

Re: [Modeling-users] access of custom object properties

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

On jeudi, avr 24, 2003, at 18:13 Europe/Amsterdam, Sebastien Bigaret=20
wrote:
> Mario Ruggier <ma...@ru...> writes:
>> hi,
>>
>> what does everyone do when wanting to systematically access
>> all, or a subset of, property values of a custom object to something
>> else, such as looping to generate html. What is the cleanest and most
>> efficient way to a) know the list of class property names, and b) to=20=

>> loop
>> over them to obtain their value (without having to do dirty tricks=20
>> such as
>> calculating the get method name for the property, and then eval'ing =
or
>> calling that in some way, or accessing directly the instance private
>> attribute for the property).

>   Short answer: Entity.classProperties(), classPropertiesNames(),
>                 classProperties_attributes(),
>                 classProperties_relationships()
>
>             and KeyValueCoding
>
>   i.e.:
>
>>>> from StoreEmployees.Executive import Executive
>>>> from Modeling import ModelSet
>>>> ms=3DModelSet.defaultModelSet()
>>>> #
>>>> # Howto get class properties (given the model)
>>>> #
>>>> executive_entity=3Dms.entityNamed('Executive')
>>>> [a.name() for a in executive_entity.classProperties()]
> ['firstName', 'officeLocation', 'lastName', 'marks', 'toAddresses',=20
> 'toStore']
>>>> executive_entity.classPropertiesNames() # alternatively
> ['firstName', 'officeLocation', 'lastName', 'marks', 'toAddresses',=20
> 'toStore']
>>>> [a.name() for a in ee.classProperties_attributes()]
> ['firstName', 'officeLocation', 'lastName']
>>>> [a.name() for a in ee.classProperties_relationships()]
> ['marks', 'toAddresses', 'toStore']
>>>> #
>>>> # Howto get a value: use KeyValueCoding!
>>>> #
>>>> from Modeling.FetchSpecification import FetchSpecification
>>>> from Modeling.EditingContext import EditingContext
>>>> ec=3DEditingContext()
>>>> fs=3DFetchSpecification('Executive')
>>>> executives=3Dec.objectsWithFetchSpecification(fs)
>>>>
>>>> executives
> [<StoreEmployees.Employees.Executive instance at 0x863c104>]
>>>> [[e.valueForKey(k) for k in=20
>>>> executive_entity.classPropertiesNames()] for e in executives]
> [['John', '4XD7', 'Cleese',=20
> <Modeling.FaultHandler.AccessArrayFaultHandler instance at 0x863a53c>,=20=

> <Modeling.FaultHandler.AccessArrayFaultHandler instance at 0x839b7b4>,=20=

> <StoreEmployees.Store.Store instance at 0x863b16c>]]
>
>
>   Is that what you meant?

Yes exactly. And, apologies as I knew about these methods but forgot=20
they existed!
I had even proposed a renaming for the KeyValueCoding methods... (you=20
see,
names are important!).

Looking at the method names again, i see what seems like an unchecked
proliferation of names:

valueForKey=A0
valueForKeyPath
=A0
setValueForKey 		same as takeValueForKey?
setValueForKeyPath	same as takeValueForKeyPath?

storedValueForKey
setStoredValueForKey 	same as takeStoredValueForKey?

takeValuesFromDictionary
takeStoredValuesFromDictionary

Sorry to pick on this (when there are so many other things on the todo=20=

list),
but, apart from being not pretty, I find this inconsistency confusing,
impractical and not easy to remember. Among the dupilcates, which
ones should be standardized on?

What do people thing to clean-up these names to something like:

getPropValue
getQPropValue # get qualified property value
=A0
setPropValue
setQPropValue

getStoredPropValue
setStoredPropValue

setPropValues # from dictionary
setStoredPropValues # from dictionary

getPropValues # new - returns a dict
getStoredPropValues # new - returns a dict

To accompany this, the KeyValueCoding module should also
probably be renamed to something PropValueCoding or
PropValueAccess. (Also the two module functions...).

To be consistent with rest of naming, I guess we could use
the full "Property" instead of "Prop"... but I prefer shorter names,
especially when the longer ones add nothing to clarity (and often
reduce it, simply because their length reduces their easy distinction).

I am not saying we should do this now -- for now we should at least
add (to the docstrings, and UG) which of the current methods we
should stick to, and which are deprecated.

Any opinions?

mario

Re: [Modeling-users] access of custom object properties

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

        Hi,


Mario Ruggier <ma...@ru...> writes:
> hi,
>=20
> what does everyone do when wanting to systematically access
> all, or a subset of, property values of a custom object to something
> else, such as looping to generate html. What is the cleanest and most
> efficient way to a) know the list of class property names, and b) to loop
> over them to obtain their value (without having to do dirty tricks such as
> calculating the get method name for the property, and then eval'ing or
> calling that in some way, or accessing directly the instance private
> attribute for the property).

  A very quick answer to your first question, I'll answer the second one
  later.


  Short answer: Entity.classProperties(), classPropertiesNames(),
                classProperties_attributes(),
                classProperties_relationships()

            and KeyValueCoding

  i.e.:=20

>>> from StoreEmployees.Executive import Executive
>>> from Modeling import ModelSet
>>> ms=3DModelSet.defaultModelSet()
>>> #
>>> # Howto get class properties (given the model)
>>> #
>>> executive_entity=3Dms.entityNamed('Executive')
>>> [a.name() for a in executive_entity.classProperties()]
['firstName', 'officeLocation', 'lastName', 'marks', 'toAddresses', 'toStor=
e']
>>> executive_entity.classPropertiesNames() # alternatively
['firstName', 'officeLocation', 'lastName', 'marks', 'toAddresses', 'toStor=
e']
>>> [a.name() for a in ee.classProperties_attributes()]
['firstName', 'officeLocation', 'lastName']
>>> [a.name() for a in ee.classProperties_relationships()]
['marks', 'toAddresses', 'toStore']
>>> #
>>> # Howto get a value: use KeyValueCoding!
>>> #
>>> from Modeling.FetchSpecification import FetchSpecification
>>> from Modeling.EditingContext import EditingContext
>>> ec=3DEditingContext()
>>> fs=3DFetchSpecification('Executive')
>>> executives=3Dec.objectsWithFetchSpecification(fs)
>>>
>>> executives
[<StoreEmployees.Employees.Executive instance at 0x863c104>]
>>> [[e.valueForKey(k) for k in executive_entity.classPropertiesNames()] fo=
r e in executives]
[['John', '4XD7', 'Cleese', <Modeling.FaultHandler.AccessArrayFaultHandler =
instance at 0x863a53c>, <Modeling.FaultHandler.AccessArrayFaultHandler inst=
ance at 0x839b7b4>, <StoreEmployees.Store.Store instance at 0x863b16c>]]


  Is that what you meant?
=20=20

-- S=E9bastien.

> Also, is moving to new-style properties foreseen, or are we stuck with
> support for 2.1 for a long time?  Or, is it possible to support both
> new style props, as well as 2.1?
>=20
> Regards, mario
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users

[Modeling-users] access of custom object properties

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

hi,

what does everyone do when wanting to systematically access
all, or a subset of, property values of a custom object to something
else, such as looping to generate html. What is the cleanest and most
efficient way to a) know the list of class property names, and b) to 
loop
over them to obtain their value (without having to do dirty tricks such 
as
calculating the get method name for the property, and then eval'ing or
calling that in some way, or accessing directly the instance private
attribute for the property).

Also, is moving to new-style properties foreseen,
or are we stuck with support for 2.1 for a long time?
Or, is it possible to support both new style props, as well as 2.1?

Regards, mario

Re: [Modeling-users] Roadmap to 0.9 - connectionDictionary

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

On mercredi, avr 23, 2003, at 12:25 Europe/Amsterdam, Sebastien Bigaret=20=

wrote:
>         Hi,
>
> Mario Ruggier <ma...@ru...> writes:
>> While we are making changes to the model... ;)
>>
>> - I really do not like having the connectionDictionary written out=20
>> all over
>> the place in xml files, some of which generated and copied around.
>> Is it possible to externalize this? (Maybe I am missing something?)
>> The connDict should at maximum be written on disk only once (this
>> will automatically be possibly with PyModels...).
>
>   You're right. In fact there is also a problem with PyModels: they=20
> will
>   contain passwords, and be installed in the standard python path. By
>   default, installation will make them world-readable, which is not=20
> good
>   either.

Yes, definately a problem.

>   I suggest a env. variable poiting to a specific init-file read by
> ConfigParser and changing the models' connection dictionary when they
> are loaded --see tests.utils.parseConfigFile_and_updateModel() and
> tests/test.cfg for an example of this technique.
>
>   Does it sound reasonable? This can be easily done, and it will meet
>   the exact requirements you're pointing out. I guess we can make it
>   happen for 0.9.

Would be wonderful way to go. This case will also make encrypting
of password less necessary.

>> Also (a different request) passwords should not be written in the=20
>> clear.
>> Is it possible to send encrypted passwords to the db server?
>
>   I've no idea -- if somebody knows what is possible w/ postgresql and
>   mysql, please tell. Otherwise we'll have to search the official
>   docs. I suggest for we forget this for 0.9, though. Could you fill =
in
>   a RFE?

Do not know what the db's support.
Can wait, and may even not be necessary with the scheme proposed above.
But I will fill a request...

>> - Another minor request, that can wait; would it be possible to make
>> entity/@name the default for both entity/@className and=20
>> entity/@externalName,
>> should these two not be specified in the XML model?
>
>   It's not difficult at all (it's already done in the ZModeler). Now I
> wonder whether it is a good idea to change a model while loading it at
> runtime. Dunno why, but this hurts me a little for xml files, however=20=

> it
> seems to make sense for the coming pymodels... Oh well, I'm confused
> now, let's think a little more about it.

This can definately wait.

>   BTW: the default for entity/@className would preferably be
>        Entity.externalNameForInternalName(entity/@name)
>
>
>         Cheers,
>
> -- S=E9bastien.

mario

Re: [Modeling-users] Roadmap to 0.9 - connectionDictionary

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

        Hi,

Mario Ruggier <ma...@ru...> writes:
> While we are making changes to the model... ;)
>=20
> - I really do not like having the connectionDictionary written out all ov=
er
> the place in xml files, some of which generated and copied around.
> Is it possible to externalize this? (Maybe I am missing something?)
> The connDict should at maximum be written on disk only once (this
> will automatically be possibly with PyModels...).

  You're right. In fact there is also a problem with PyModels: they will
  contain passwords, and be installed in the standard python path. By
  default, installation will make them world-readable, which is not good
  either.

  I suggest a env. variable poiting to a specific init-file read by
ConfigParser and changing the models' connection dictionary when they
are loaded --see tests.utils.parseConfigFile_and_updateModel() and
tests/test.cfg for an example of this technique.

  Does it sound reasonable? This can be easily done, and it will meet
  the exact requirements you're pointing out. I guess we can make it
  happen for 0.9.

> Also (a different request) passwords should not be written in the clear.
> Is it possible to send encrypted passwords to the db server?

  I've no idea -- if somebody knows what is possible w/ postgresql and
  mysql, please tell. Otherwise we'll have to search the official
  docs. I suggest for we forget this for 0.9, though. Could you fill in
  a RFE?

> - Another minor request, that can wait; would it be possible to make
> entity/@name the default for both entity/@className and entity/@externalN=
ame,
> should these two not be specified in the XML model?

  It's not difficult at all (it's already done in the ZModeler). Now I
wonder whether it is a good idea to change a model while loading it at
runtime. Dunno why, but this hurts me a little for xml files, however it
seems to make sense for the coming pymodels... Oh well, I'm confused
now, let's think a little more about it.

  BTW: the default for entity/@className would preferably be
       Entity.externalNameForInternalName(entity/@name)


        Cheers,

-- S=E9bastien.

Re: [Modeling-users] Roadmap to 0.9

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

Mario Ruggier <ma...@ru...> writes:
> > Mario wrote:
> >>> An issue that probably should be resolved before 0.9 is the name of
> >>> the framework. This implies a lot, though...
> >>
> >> 1.0 hopefully ;)
> >
> > I did not read you right, I initially read *after* 0.9
>=20
> Well, in my opinion the longer one uses a name the harder it is to change=
 it.
> So, the sooner the better. But, it implies a lot of little changes, and i=
t is
> up to
> you as whether it should be done now or not. Is there a pressing deadline
> for 0.9, or is the date fixed arbitrarily?

No pressing deadline, it's just that we already have a one-month drift wrt =
the
initial planning :\

  I'll try to summarize the "little changes" and I'll get back on the subje=
ct
  then. We also have the former name proposals in the archives, they can be
  easily collected.

-- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

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

Mario Ruggier <ma...@ru...> writes:
> >> mdl_generate_DB_schema.py
> >> - when creating a table the first time around, all DROP statements fai=
l,
> >> and execution stops unless the -i switch is used. Shouldn't DROP of
> >> non-existant stuff not be treated like an error?
> >
> > Not sure what you mean here:
> >
> > $ mdl_generate_DB_schema.py -C -v \
> >> --admin-dsn=3D"localhost:template1:postgres:" ./model_StoreEmployees.x=
ml
> >
> > does not try any drop statements. Could you be more precise on which
> > situation(s) it annoys you?
>=20
> mdl_generate_DB_schema.py -v -A model.xml
>=20
> Sorry, I was just being too lazy, and wanted to execute the same command
> whether it is the first time creating the table, or early interations of =
the
> model
> (requiring frequent regeneration). Hadn't "registered" the -C switch...

If you *really* want to be lazy, you'll probably find '-R -i' handy :)=20

BTW '-A' does not create the database, but with an existing database
'-A --ignore-errors' will ignore the initial & failing DROP TABLE.

  Related to the topic: I just committed a slight change in
  AbstractDBAPI2AdaptorLayer.AbstractDBAPI2Adaptor which apparently
  solves a annoying pb. w/ postgresql (and maybe mysql as well), where
  the creation of the db can fail when tried just after a 'DROP DB';
  postgresql error is then:

    ERROR: CREATE DATABASE: source database "template1" is being accessed by
           other users

  Obviously this is the case in mdl_generate_DB_schema with option -R.


-- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

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

On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret=20
wrote:
>
> Mario Ruggier <ma...@ru...> writes:
>> Some minor comments, from tests here using the scripts:
>>
>> mdl_validate -v
>> - the -v switch is not listed in the usage info printed by the=20
>> script's -h
>
> Fixed on the cvs main trunk. I also changed a little the options: now
> '-w' discards warnings and info., and 'q' discards info. '-Q' is for
> *really* quiet.

OK.

>> mdl_generate_python_code.py -B
>> - it looks like second time generation does not overwrite anything in
>> the MDL directory. It should?
>
> I can't reproduce that, see e.g.:

Ooops, sorry my misreading of the log output ;-\

[snip]

>> - the switch --overwrite-existing-files seems to have disappeared, =
but
>> to me it still makes sense to keep the option if you want a clean
>> generation, and want to throw away the "working" files...
>
> I understand, however in that case I recommend moving or destroying =
the
> whole package or some files. I was forced to add this option earlier
> (but didn't like it) because it wasn't possible to say in a generation
> scheme which files should be overwritten; now that that's clear I=20
> prefer
> that the user handles this.

OK, fair enough.

>
>> mdl_generate_DB_schema.py
>> - when creating a table the first time around, all DROP statements=20
>> fail,
>> and execution stops unless the -i switch is used. Shouldn't DROP of
>> non-existant stuff not be treated like an error?
>
> Not sure what you mean here:
>
> $ mdl_generate_DB_schema.py -C -v \
>> --admin-dsn=3D"localhost:template1:postgres:" =
./model_StoreEmployees.xml
>
> does not try any drop statements. Could you be more precise on which
> situation(s) it annoys you?

mdl_generate_DB_schema.py -v -A model.xml

Sorry, I was just being too lazy, and wanted to execute the same command
whether it is the first time creating the table, or early interations=20
of the model
(requiring frequent regeneration). Hadn't "registered" the -C switch...


>>> BTW: Mario proposed that the generated class initializer could be:
>>>>   def __init__(self,att1=3DNone,att2=3DNone):
>>> instead of
>>>>   def __init__(self):
>>>
>>>   Are we ok we go for it?
>>
>> My vote is clear.
>
>   :)
>
> -- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

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

Mario Ruggier <ma...@ru...> writes:
> Some minor comments, from tests here using the scripts:
>=20
> mdl_validate -v
> - the -v switch is not listed in the usage info printed by the script's -h

Fixed on the cvs main trunk. I also changed a little the options: now
'-w' discards warnings and info., and 'q' discards info. '-Q' is for
*really* quiet.

> mdl_generate_python_code.py -B
> - it looks like second time generation does not overwrite anything in
> the MDL directory. It should?

I can't reproduce that, see e.g.:

      mdl_generate_python_code.py -B ./model_StoreEmployees.xml2
    Creating directory ./StoreEmployees... no
    File ./StoreEmployees/TODO.txt exists, skipping
    File ./StoreEmployees/README.txt exists, skipping
    File ./StoreEmployees/VERSION.txt exists, skipping
    File ./StoreEmployees/INSTALL.txt exists, skipping
    File ./StoreEmployees/DEPENDENCIES.txt exists, skipping
    File ./StoreEmployees/__init__.py exists, skipping
    File ./StoreEmployees/setup.py exists, skipping
    Creating directory ./StoreEmployees/MDL... no
--> Generating ./StoreEmployees/MDL/__init__.py... done
    Generating ./StoreEmployees/MDL/model_StoreEmployees.xml... done
    Generating ./StoreEmployees/MDL/model_StoreEmployees.py... done
    File ./StoreEmployees/Address.py exists, skipping
--> Generating ./StoreEmployees/MDL/Address.py... done
    File ./StoreEmployees/Store.py exists, skipping
--> Generating ./StoreEmployees/MDL/Store.py... done
    File ./StoreEmployees/Employees.py exists, skipping
--> Generating ./StoreEmployees/MDL/Employees.py... done
    File ./StoreEmployees/Mark.py exists, skipping
--> Generating ./StoreEmployees/MDL/Mark.py... done
    File ./StoreEmployees/Employee.py exists, skipping
--> Generating ./StoreEmployees/MDL/Employee.py... done

> - the switch --overwrite-existing-files seems to have disappeared, but
> to me it still makes sense to keep the option if you want a clean
> generation, and want to throw away the "working" files...

I understand, however in that case I recommend moving or destroying the
whole package or some files. I was forced to add this option earlier
(but didn't like it) because it wasn't possible to say in a generation
scheme which files should be overwritten; now that that's clear I prefer
that the user handles this.

> mdl_generate_DB_schema.py
> - when creating a table the first time around, all DROP statements fail,
> and execution stops unless the -i switch is used. Shouldn't DROP of
> non-existant stuff not be treated like an error?

Not sure what you mean here:

$ mdl_generate_DB_schema.py -C -v \=20
> --admin-dsn=3D"localhost:template1:postgres:" ./model_StoreEmployees.xml

does not try any drop statements. Could you be more precise on which
situation(s) it annoys you?

> > BTW: Mario proposed that the generated class initializer could be:
> >>   def __init__(self,att1=3DNone,att2=3DNone):
> > instead of
> >>   def __init__(self):
> >
> >   Are we ok we go for it?
>=20
> My vote is clear.

  :)

-- S=E9bastien.

Re: [Modeling-users] working in unicode?

[Yannick G. <ygi...@yg...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 22 April 2003 06:38, you wrote:
> One step up, two steps back... but i guess support for this will
> eventually come.  If i understand correctly with postgres, you can
> send a select query in unicode directly, and a case insensitive
> condition should work... But the middle layer does not support this
> unfortunately...

Ah well...

But you were wright, the lack of case-insensitive search is far less
evil than the field length expansion when working with utf-8 encoded
data.  Shouldn't Modeling allocate enough space to store 8 char of any
language if I say that I want 8 chars for some property ?

It should not be the application programmer's job to know all the
technicalities of utf-8 encoding.

That's one of the use we have for comments now, we say the field
intended length and we put the "physical" length in the model...

IMHO, the is a ugly hack.

- -- 
Yannick Gingras
Coder for OBB : Overlooked Biogeographical Backseat
http://OpenBeatBox.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+pSUMrhy5Fqn/MRARAqhIAJ4w7thSD8RZ033RdyfCKh4UsmDxhACeLVXU
BeTPC1XmC+P6/KSzsDkRqEU=
=qabP
-----END PGP SIGNATURE-----

Re: [Modeling-users] Roadmap to 0.9 - connectionDictionary

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

While we are making changes to the model... ;)

- I really do not like having the connectionDictionary written out all=20=

over
the place in xml files, some of which generated and copied around.
Is it possible to externalize this? (Maybe I am missing something?)
The connDict should at maximum be written on disk only once (this
will automatically be possibly with PyModels...).

Also (a different request) passwords should not be written in the clear.
Is it possible to send encrypted passwords to the db server?

- Another minor request, that can wait; would it be possible to make
entity/@name the default for both entity/@className and=20
entity/@externalName,
should these two not be specified in the XML model?

mario

On mardi, avr 22, 2003, at 11:57 Europe/Amsterdam, Sebastien Bigaret=20
wrote:
> Yannick Gingras <ygi...@yg...> writes:
>> On Sunday 20 April 2003 09:05, Sebastien Bigaret wrote:
>>> Last addition: I remember Yannick Gingras saying that it can be
>>> useful to be able to comment on a model -- 1.0 will add a comment
>>> attribute in Model, Entity, Attribute and Relationship.
>>
>> Woohoo !
>>
>
> Obviously I meant 0.9, and this is now done in the CVS (Modeling and
> ZModelizationTool updated)
>
> -- S=E9bastien.

Re: [Modeling-users] Roadmap to 0.9

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

> Mario wrote:
>>> An issue that probably should be resolved before 0.9 is the name of
>>> the framework. This implies a lot, though...
>>
>> 1.0 hopefully ;)
>
> I did not read you right, I initially read *after* 0.9

Well, in my opinion the longer one uses a name the harder it is to=20
change it.
So, the sooner the better. But, it implies a lot of little changes, and=20=

it is up to
you as whether it should be done now or not. Is there a pressing=20
deadline
for 0.9, or is the date fixed arbitrarily?

mario

> Should we choose and apply the new name for 0.9? It seems unreasonable=20=

> to me,
> we have ~one week and yes, this implies a lot.
>
> -- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

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

On mardi, avr 22, 2003, at 01:10 Europe/Amsterdam, Sebastien Bigaret=20
wrote:
>
> Sebastien Bigaret <sbi...@us...> writes:
>
>> Ok, I think we have a problem here w/ the 'base' generation
>> scheme. Consider you modify the StoreEmployees model so that the=20
>> classes
>> Employee, Executive and SalesClerk are in the same module
>> 'Employees'. This would generate:
> [snip]
>>   The problem? It creates an import loop between packages=20
>> StoreEmployees
>>   and StoreEmployees.MDL, and worse, another one between modules
>>   Employees and MDL.Employees (this problem remains even if we forget
>>   about the 'MDL' sub-directory and when all files are dropped within
>>   the same package).
>>
>>   If someone has a solution for this, please share!
>>
>>   I have the feeling that it is enough to state that a class and its
>>   subclass(es) should *not* share the same module when the 'base'
>>   generation scheme is involved. What do you think?

For now it will certainly be enough.
I do not have clear ideas how to best solve this at the moment...

> I've just finished a first proposal for this and committed it under =
the
> branch tagged brch-0_9pre6-1. It solves the problem as long as a class
> does not share the same module than one of its (direct or indirect)
> subclasses.
>
>   This constraint is not implemented yet.
>
> To retrieve the branch: in directory ModelMasons, directly type:
>
>     $ cvs update -r brch-0_9pre6-1-ModelMasons_base_generation_scheme
>
>
>   I successfully applied this on models AuthorBooks and =
StoreEmployees,
>   it would be cool if sb. could check that on his own projects. I also
>   did not pay a very close attention to the generated code (I just =
made
>   sure it works out-of-the-box wrt the tests), hence there can be
>   repetitions, useless portion of codes, etc. in the generated =
modules.

Some minor comments, from tests here using the scripts:

mdl_validate -v
- the -v switch is not listed in the usage info printed by the script's=20=

-h

mdl_generate_python_code.py -B
- it looks like second time generation does not overwrite anything in
the MDL directory. It should?
- the switch --overwrite-existing-files seems to have disappeared, but
to me it still makes sense to keep the option if you want a clean
generation, and want to throw away the "working" files...

mdl_generate_DB_schema.py
- when creating a table the first time around, all DROP statements fail,
and execution stops unless the -i switch is used. Shouldn't DROP of
non-existant stuff not be treated like an error?

Otherwise, I have found no other problem.


> BTW: Mario proposed that the generated class initializer could be:
>>   def __init__(self,att1=3DNone,att2=3DNone):
> instead of
>>   def __init__(self):
>
>   Are we ok we go for it?

My vote is clear.

mario


>     Happy testing!
>
> -- S=E9bastien.

Re: [Modeling-users] Roadmap to 0.9

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

Yannick Gingras <ygi...@yg...> writes:
> On Sunday 20 April 2003 09:05, Sebastien Bigaret wrote:
> > Last addition: I remember Yannick Gingras saying that it can be
> > useful to be able to comment on a model -- 1.0 will add a comment
> > attribute in Model, Entity, Attribute and Relationship.
>=20
> Woohoo !
>=20

Obviously I meant 0.9, and this is now done in the CVS (Modeling and
ZModelizationTool updated)

-- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

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

Sebastien Bigaret <sbi...@us...> writes:

> Ok, I think we have a problem here w/ the 'base' generation
> scheme. Consider you modify the StoreEmployees model so that the classes
> Employee, Executive and SalesClerk are in the same module
> 'Employees'. This would generate:
[snip]
>   The problem? It creates an import loop between packages StoreEmployees
>   and StoreEmployees.MDL, and worse, another one between modules
>   Employees and MDL.Employees (this problem remains even if we forget
>   about the 'MDL' sub-directory and when all files are dropped within
>   the same package).
>=20
>   If someone has a solution for this, please share!
>
>   I have the feeling that it is enough to state that a class and its
>   subclass(es) should *not* share the same module when the 'base'
>   generation scheme is involved. What do you think?

I've just finished a first proposal for this and committed it under the
branch tagged brch-0_9pre6-1. It solves the problem as long as a class
does not share the same module than one of its (direct or indirect)
subclasses.

  This constraint is not implemented yet.

To retrieve the branch: in directory ModelMasons, directly type:

    $ cvs update -r brch-0_9pre6-1-ModelMasons_base_generation_scheme


  I successfully applied this on models AuthorBooks and StoreEmployees,
  it would be cool if sb. could check that on his own projects. I also
  did not pay a very close attention to the generated code (I just made
  sure it works out-of-the-box wrt the tests), hence there can be
  repetitions, useless portion of codes, etc. in the generated modules.

BTW: Mario proposed that the generated class initializer could be:
>   def __init__(self,att1=3DNone,att2=3DNone):
instead of
>   def __init__(self):

  Are we ok we go for it?

    Happy testing!

-- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

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

Ok, I think we have a problem here w/ the 'base' generation
scheme. Consider you modify the StoreEmployees model so that the classes
Employee, Executive and SalesClerk are in the same module
'Employees'. This would generate:

    StoreEmployees
    |-- Address.py
    |-- Employees.py (Employee+Executive+SalesClerk)
    |-- Mark.py
    |-- MDL
    |   |-- Address.py
    |   |-- Employees.py (Employee+Executive+SalesClerk)
    |   |-- Mark.py
    |   |-- Store.py
    |   |-- __init__.py
    |   |-- model_StoreEmployees.py
    |   `-- model_StoreEmployees.xml
    |-- Store.py
    |-- __init__.py
    `-- setup.py


Remember that the inheritance goes like this:
     MDL.Employee <--- Employee <---- MDL.Executive <---- Executive

1. in MDL.__init__, we HAVE to 'import Employees' if we want to be able
   to write in StoreEmployees.Employees:

     class Employee(MDL.Employees.Employee):
       "..."

2. in MDL.Employees we have to write something like this:

     from StoreEmployees.Employees import Employee as EmployeeConcrete
     class Employee(CustomObject):
       "..."

     class Employee(EmployeeConcrete):
       "..."

     class SalesClerk(EmployeeConcrete):
       "..."


  The problem? It creates an import loop between packages StoreEmployees
  and StoreEmployees.MDL, and worse, another one between modules
  Employees and MDL.Employees (this problem remains even if we forget
  about the 'MDL' sub-directory and when all files are dropped within
  the same package).

  If someone has a solution for this, please share!

  I have the feeling that it is enough to state that a class and its
  subclass(es) should *not* share the same module when the 'base'
  generation scheme is involved. What do you think?

-- S=E9bastien.

Re: [Modeling-users] working in unicode?

[Yannick G. <ygi...@yg...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 21 April 2003 07:14, Mario Ruggier wrote:
> I guess case-insensitive matches will not work, as Yannick pointed out
> (thanks!).
> But, case does not really mean much when applied generically to unicode
> (the concept of case is not for all languages?).

I don't know much about Asian languages but there is the concept of
case in the Cyrillic alphabet.  Have a look kcharselect table no.4.
Same for Greek, same for French.  If "S=E9bastien" is encoded in utf-8,
you'll have a hard time to case-insensitively match it...

This is supposed to be managed by the RDMS, it should know how to do a
case insensitive select on utf-8 but life is cruel...=20

  ; )

- --=20
Yannick Gingras
Coder for OBB : Occasional Barricaded Buttressing
http://OpenBeatBox.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+pAsOrhy5Fqn/MRARAho7AJ9AvcMOF0o8UFIBGYHi/v75zzpDyQCeO/es
fi8cKmHkOMgTq4h1wJ+3Lsk=3D
=3D3rc7
-----END PGP SIGNATURE-----

Re: [Modeling-users] ModelMasons refactored

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

Mario Ruggier <ma...@ru...> wrote:
> On lundi, avr 21, 2003, at 15:02 Europe/Amsterdam, Jerome Kerdreux wrote:
>=20
> > On Mon, Apr 21, 2003 at 02:51:46PM +0200, Sebastien Bigaret wrote:
> >
> >> Mario wrote:
> >>> Just a minor comment, w.r.t. naming of the generated files/classes.
> >>> I feel that:
> >>>
> >>> 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 gue=
ss
> >> 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.
> >
> > Hum I want to maintain a reference to the fact that this came from the
> > modeling. Cause i use some ORB here and it generate a lot of code too
> > so 'Autogen' hurt me a little . (same in glade too)
> > I prefer the previous one 'Mdl' or something else.
>=20
> Don't understand. Why does AutoGen give you a problem and Base
> does not, as far as other 3rd party generated code goes ?

I guess Soif prefers to have the AutoGen directory named after the
framework which generated it, since he uses other tools, such as glade,
also generating code.

I personally do not care: I consider the two generation scheme as
example on how things can be done. It's no big deal, however, I guess we
can choose 'MDL'.

> >> 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.
> >
> >
> > Hum i'm not really clear about this, but i think this can generated
> > namespace colision . mainly in the 'working' module
>=20
> Well, it is true if you import it directly into the local namespace.
> However, i fell it is a lot of clutter to keep repeating the prefix (or
> postfix)
> for each file. What is the point of having a namespace if not to avoid
> having to do such things?
> [...]

I agree, I feel like we'll keep it as-is; I too can't see any good
reason why a collision in the namespace could reasonably happen.

-- S=E9bastien.

Re: [Modeling-users] Roadmap to 0.9

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

Mario wrote:
> > An issue that probably should be resolved before 0.9 is the name of
> > the framework. This implies a lot, though...
>=20
> 1.0 hopefully ;)

I did not read you right, I initially read *after* 0.9

Should we choose and apply the new name for 0.9? It seems unreasonable to m=
e,
we have ~one week and yes, this implies a lot.

-- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

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

On lundi, avr 21, 2003, at 15:02 Europe/Amsterdam, Jerome Kerdreux 
wrote:

> On Mon, Apr 21, 2003 at 02:51:46PM +0200, Sebastien Bigaret wrote:
>
>> Mario wrote:
>>> Just a minor comment, w.r.t. naming of the generated files/classes.
>>> I feel that:
>>>
>>> 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.
>
> Hum I want to maintain a reference to the fact that this came from the
> modeling. Cause i use some ORB here and it generate a lot of code too
> so 'Autogen' hurt me a little . (same in glade too)
> I prefer the previous one 'Mdl' or something else.

Don't understand. Why does AutoGen give you a problem and Base
does not, as far as other 3rd party generated code goes ?


>> 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.
>
>
> Hum i'm not really clear about this, but i think this can generated
> namespace colision . mainly in the 'working' module

Well, it is true if you import it directly into the local namespace.
However, i fell it is a lot of clutter to keep repeating the prefix (or 
postfix)
for each file. What is the point of having a namespace if not to avoid
having to do such things?

Besides, instead of:

import AutoGen
class Folder(AutoGen.Folder):
     ...

no-one will ever stop you from doing:

from AutoGen import Folder as FolderBase
class Folder(FolderBase):
     ...

Except yourself, of course ;)

Cheers, mario

Re: [Modeling-users] custom object initialisation

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

Mario Ruggier <ma...@ru...> wrote:
> Is there a particular reason why the __init__ generated for
> custom objects does not allow pre-setting of attribute values?
> I mean, do not we frequently want to initialise an object
> with values, e.g.
>=20
> mo =3D myObj(att1=3D'one', att2=3D'two', ...)
>=20
> instead of having to initialise and then call a setter for each attribute
> we want to set:
>=20
> mo =3D myObj()
> mo.setAtt1('one')
> mo.setAtt2('two')
>=20
>   I.e. instead of something like the following:
>=20
> class myObj(CustomObject):
>    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.
>      self._att1 =3D None
>      self._att2 =3D None
>=20
> why shouldn't we have:
>=20
> class myObj(CustomObject):
>    def __init__(self,att1=3DNone,att2=3DNone):
>      "Initializer"
>      #...
>      self._att1 =3D att1
>      self._att2 =3D att2


There's no particular reason for this: both idioms are completely equivalen=
t.
Another equivalent init could be:

  def __init__(self, **kw):
    self._att1=3Dkw.get('att1', None)
    #...

However, it is true that every single parameter should have a default value.

> I mean, do not we frequently want to initialise an object
> with values, e.g.
>=20
> mo =3D myObj(att1=3D'one', att2=3D'two', ...)

Right. Should we change the default generated code?

-- S=E9bastien.

Re: [Modeling-users] ModelMasons refactored

[Jerome K. <Jer...@fi...>]

On Mon, Apr 21, 2003 at 02:51:46PM +0200, Sebastien Bigaret wrote:
>=20
> > as my package name is mortal.Objects, you can see that Base class
> > are cleary separated from the class you work on.=20
>=20
> Ok, seems reasonable.

Yeah :)=20

=20
> 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" ...
>=20
> Reasonable too. What about 'Autogen'? Since we're going this way I gues=
s
> that models (xml/py) should be moved to that directory too, so that
> everything that is overwritten when generating the code clearly falls i=
n
> the dedicated directory.

Hum I want to maintain a reference to the fact that this came from the=20
modeling. Cause i use some ORB here and it generate a lot of code too=20
so 'Autogen' hurt me a little . (same in glade too)=20
I prefer the previous one 'Mdl' or something else.=20
=20

> 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=
.
>        [...]
>=20
> No problem; since we forget about 'Base' as a package it's a nonsense t=
o
> keep it here.


Hum i'm not really clear about this, but i think this can generated
namespace colision . mainly in the 'working' module=20

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.

[Modeling-users] custom object initialisation

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

Is there a particular reason why the __init__ generated for
custom objects does not allow pre-setting of attribute values?
I mean, do not we frequently want to initialise an object
with values, e.g.

mo = myObj(att1='one', att2='two', ...)

instead of having to initialise and then call a setter for each 
attribute
we want to set:

mo = myObj()
mo.setAtt1('one')
mo.setAtt2('two')

  I.e. instead of something like the following:

class myObj(CustomObject):
   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.
     self._att1 = None
     self._att2 = None

why shouldn't we have:

class myObj(CustomObject):
   def __init__(self,att1=None,att2=None):
     "Initializer"
     #...
     self._att1 = att1
     self._att2 = att2


Thanks, mario