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