[PEAK] ZConfig question

[Phillip J. Eby]

At 08:41 PM 7/27/04 +0200, Roché Compaan wrote:
>* Phillip J. Eby <pje at telecommunity.com> [2004-07-27 18:22]:
> > You can also use [Named Services] to define the factory, so that the 
> schema
> > will only be loaded once:
>
>I don't understand why it will only get loaded once? How is it different
>than to putting the factory in the peak.naming.factories section?

Normally, any property you define in an .ini file will be computed each 
time it's asked for, and may thus be specific to the object you requested 
the property for.  So, if you define it in '[peak.naming.factories]', 
you're just defining a regular property and it is computed each time it's 
needed (unless explicitly cached elsewhere).

But '[Named Services]' lets you define properties that are global to an 
entire service area.  They are computed only once per service area, and 
cached in the service area.  They are in all other respects normal 
configuration properties, it's just that they are only computed once and 
relative to the service area, regardless of what object you asked it to be 
computed for.


>I noticed 'LinkRef' in peak.ini, but my URL omitted 'ref:'. I copied
>what is done with the 'EventDriven' shortcut.

'EventDriven' predates the 'ref:' mechanism, and uses the 'zconfig.schema:' 
URL scheme, which was designed with a different purpose in 
mind.  Specifically, 'zconfig.schema' URLs create "interpreters" that are 
designed to be used in a #! line of a ZConfig file, e.g.:

    #!peak EventDriven

    ...zconfig data goes here...


>To be clear, how is
>"naming.LinkRef('ref:myapp.schema at ....')" different to
>"naming.LinkRef('myapp.schema at ...')"?

Well, the latter one simply isn't going to work, unless you are accessing 
it in a naming context that assumes names to be 'ref:' URLs.  :)

The 'ref:' URL scheme expects a factory name, and a list of '||'-separated 
addresses.  Such URLs are then interpreted as if they were Reference objects.

Your 'myapp.schema at ...' string is not a URL, however, since a URL must 
begin with an alphanumeric scheme identifier and a colon.  (Actually, the 
RFCs allow '+', '-', '_' and '.' to appear in URL scheme identifiers, and 
so does PEAK.)

Since it is not a URL, the naming system interprets it as a *name*, whose 
interpretation is dependent on the context where you are looking it up.  If 
you are looking it up in a context that is initialized for 'ref:' URLs, it 
will work as you expect.  If you are looking it up in say, 
"self.lookupComponent()", it's going to be interpreted as an attribute 
path.  If you looked it up in a 'mailto:' URL context, it might be 
interpreted as an email address.  :)


> > As you can see, though, this gains you little in this context, since you
> > still need to create a LinkRef so the URL can be looked up.
>
>But it is aesthetically pleasing to see everything as an URL ;-)

Perhaps, but since it's roughly the same amount of typing I prefer to be 
explicit, and it takes *much* less computation to process a 
'naming.Reference()' than the various steps needed to parse the LinkRef URL 
and turn it into a Reference.


> > Incidentally, whether you use 'naming.Reference()' or the 'ref:' URL
> > scheme, you can use other URL schemes besides 'file:' as addresses.  For
> > example, you can use 'pkgfile', which lets you refer to a file contained
> > inside a Python package directory, and you can even use http or ftp should
> > you have the need.
>
>Yes, I replaced the absolute filename with "pkgfile:jack/schema.xml":
>
>      peak.naming.factories.myapp.schema = naming.LinkRef(
>          'ref:zconfig.schema at pkgfile:jack/schema.xml')

That's the idea, yes.