[TransWarp] component path - property name dualism, does
this make sense?
Phillip J. Eby
pje at telecommunity.com
Tue Aug 19 13:17:22 EDT 2003
At 06:45 PM 8/19/03 +0200, Matthias Drochner wrote:
>pje at telecommunity.com said:
> > it may be that the peak.model package offers better tools for the job
>Would this give me the flexibility to quickly define new
>configuration variables for an object, eg to switch on
>behaviour variations? (Well, the mechanics of the spectrometers
>has its kinks - that's one reason my original program grew
>A too strict scheme, and too many files to edit would
>be bad in real live.
Probably not. The peak.model package is designed for creating domain model
classes from a relatively stable design model (e.g. a UML model).
> > Also, here's a slightly cleaned up alternative to your original post:
> > [use delegateTo]
>Here I'm running into differences between 0.5a2 and current CVS:
>With 0.5a2 the "ruleSuffix" in the config file is not defined,
>but as long as I define all parameters in the config file, they
>are looked up as expected.
0.5a2 doesn't support 'ruleSuffix'.
>With the CVS version, the component path within the
>ConfigDelegate:propertyMap() method is just "/", so nothing works.
>For the former, there is an entry in the CHANGES file. The latter
>looks like a bug...
Hmmm. It's probably a bug in my attempt to solve your problem. I'm
guessing that what's happening is that __getattr__ is being called at some
point *before* the object has a parent component, and so it's considered a
root component. Try this:
def __getattr__(self, attr):
if self.__objectsToBeAssembled__ is None:
value = self.propertyMap.get(attr,NOT_FOUND)
if value is not NOT_FOUND:
This should prevent it from trying to create the property map before the
ConfigDelegate knows its parent.
More information about the PEAK