[TransWarp] making progress using current PEAK features.

[Phillip J. Eby]

At 04:24 PM 1/30/03 +0100, Ulrich Eck wrote:

>In your MailExample (storage/tests/xmi.py) you use the
>"referencedType" attribute of features, looking up the type
>in the acquisition-tree of your Model.
>
>Because i split of all those classes (from those the model
>is composed) into submodules, i ran into trouble with
>the lookupComponent. (i do not use setupModule ..
>i import the child-classes from another module into the
>model, so these child-classes parents are the
>sub-modules themselfs)
>
>to bring back the ability of typeObjects i introduced a
>new naming-provider "wxtype:String" for example that is
>used for datatype-lookup.
>
>i configured this provider with a local peak-config-file.
>
>all this works very well.
>
>does the above sound basically right to you ??

Pretty much, yes.  Of course, you can also just use 
"import:pkg.module:class" strings to reference classes defined in other 
modules, if you don't need any special indirection.  I think I've mentioned 
this before, but I thought I should make this reminder note in case anybody 
thinks they have to create a naming provider just to deal with classes 
being in another module!

In fact, you don't even need to use "import:" strings if you don't want, as 
long as the module imports the thing you want to look up.  Example:

# someModule.py

from peak.api import *

class something(model.Element):

     class aFeature(model.Reference):
         referencedType = 'someOtherType'
         referencedEnd  = 'inverseFeature'

from someOtherModule import someOtherType



# someOtherModule.py

from peak.api import *

class someOtherType(model.Element):

     class aFeature(model.Reference):
         referencedType = 'something'
         referencedEnd  = 'aFeature'

from someModule import something


The above two modules will import OK, because they import their referenced 
type *after* they have defined the type they want to export.  And, each 
class considers its module to be its parent component, so it can acquire 
the imported class, whenever you actually try to use the feature and it 
looks up the name.

So really, you don't even have to use "import:" string references if you 
don't want to, for relatively simple cases.  But it's probably easier to 
use "import:", since it would eliminate the "from..import" statements 
above, replacing the referencedType strings with 
'import:someOtherModule:someOtherType' and 'import:someModule:something' 
respectively.  And of course such strings are unambiguous in context.