[PEAK] References between models

[Radek Kanovsky]

On Thu, Nov 13, 2003 at 12:09:38PM -0500, Phillip J. Eby wrote:

[...]

> >Is this reasonable? Is there some other solution for such situations?
> 
> There's an easier way to do what you did.  Note that configuration lookups 
> go by way of a '_getConfigData' method on a component.  So, in your 'mylib' 
> package module, you could add:
> 
> protocols.advise(moduleProvides = [config.IConfigSource])
> 
> def _getConfigData(forObj,key):
>     # do something based on key, and return a value or NOT_FOUND
> 
> And once you've done this, you can use PropertyName() instances to link to 
> other elements.

I can make custom _getConfigData() method but this method will be
module specific and it will not know about application that loaded
it. Only if I declare some usage rules for applications. For example,
'__main__' must contain ??app_specific_config?? that _getConfigData()
method interprets some way.

Then I can adapt modules somehow but only if I have one application
per process. And this is problem because there must be possibility to
run more separate applications in one process. Thats why I suggested
ElementTemplate mechanism that has full access to standard configuration
system. Element class itself is not needed at class level in any
component (I mean no classmethod or classAttr computes anything from
Element class). Element class is used only by binding.Component
*instances* that have access to configuration subsystem. So why not
delay Element class construction somehow?

ElementTemplate can cause one problem. Such template can occure in more
than one place: as defaultElement in EntityDM, as formElement in some
WebForm component. It must be some mechanism that will guarantee that
``dm.defaultElement is wf.formElement'', because WebForm component can
lookup DM by Element class.

This leads me to the idea of some Element registry/manager. Every
application can have its own registry or it can obtain default provider
for IElementRegistry. Registry should be responsible for ElementTemplate
substitution and for registering created elements under PropertyNames.
It can be configurable in such way that I can state:

  # Default ``mylib.contact.model.Contact'' provider
  mylib.contact.model:Contact
      implements PropertyName("mylib.contact.model.Contact")
      for PropertyName("*")

  # Special ``mylib.contact.model.Contact'' provider for some
  # dark part of this application.
  otherlib.kontakt.model:Kontakt
      implements PropertyName("mylib.contact.model.Contact")
      for PropertyName("crackerlib.invoice.*")


Then binding.Component can ask: give me "mylib.contact.model.Contact",
I am "crackerlib.invoice.storage.InvoiceDM". And it gets
"otherlib.kontakt.model:Kontakt". Invoice element template can obtain
"mylib.contact.model.Contact" or "mylib.employer.model.Person" for
its features Invoice.subject or Invoice.responsible respectively.

I can work on implementation of this but now it is only idea for
discussion. It resembles me what is inside peak.security
but I am not sure (abstract vs. concrete permission vs. permission
protocol).

> Note that one way you could implement your _getConfigData method is as 
> follows:
> 
> protocols.advise(moduleProvides = [config.IConfigSource])
> map = config.PropertyMap()
> config.loadConfigFile(map, config.fileNearModule(__name__,'peak.ini'))
> _getConfigData = map._getConfigData
> del map

This loads ini file that is firmly binded with module itself so I am
not able to supply application specific configuration for this module.
Maybe ``config.fileNearModule('__main__','peak.ini')'' would work
but it will probably be unreliable.

> To everybody else: DON'T DO THIS UNLESS YOU UNDERSTAND THE 
> LIMITATIONS.  This is *not* really configuration, despite what it looks 
> like.  There's no real "configuration" because everything is a 
> constant.  Obviously, whatever file you load is going to be a 
> constant.  You might think, "well I could get something from the 
> environment, or...".  Stop right there.  Now you're *bypassing* the 
> configuration system, which is based on component context, not on globals.

I don't want to bypass configuration system, just on the contrary,
I want force Elements to use standard configuration that Component
instances use :-)


RadekK