[TransWarp] component path - property name dualism, does this make sense?

[Phillip J. Eby]

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
>that messy...)
>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:
                 return value
         raise AttributeError(attr)

This should prevent it from trying to create the property map before the 
ConfigDelegate knows its parent.