[Zope-PTK] Portal content wherever you want it

[Phillip J. Eby]

At 04:05 PM 5/21/00 -0400, Kevin Dangoor wrote:
>
>Thanks for the updated docs. When do you think 0.4.0 will be ready?

Dunno, it needs at least a few days hacking and testing.  When I get to
spend those days will be dependent on other factors, since I have other
projects at my job that need attention with a capital "A" right now.  I've
mostly been hacking ZPatterns at home or in other off time lately, although
I've been doing design discussion with Ty mostly at the office.


>Maybe the Zope root should eventually be replaced with an InjectionFolder.
>Or maybe we should set up objects to work regardless of whether there is a
>DataInjector above them.

I currently plan for DataSkins to use a default, no-op DataManager if they
can't find one above them.  It will include an AttributeProvider that makes
them work like a regular Zope object.

(Side note: Ty and I had an amusing discussion the other day about how
amazing it will be when all this magic can actually simulate how things
already were before ZPatterns...  He was telling me how Penn Gillette (of
Penn and Teller) once found himself using sleight-of-hand with cups and
balls to simulate ordinary non-magical reality.  Similarly, it will be
possible to use the magic of ZPatterns to simulate everything being the
same as it ordinarily is.  :) )


>Here's what I'm ultimately thinking: wouldn't it be neato if I could create
>a Document object in one part of the ZODB, and it doesn't get cataloged or
>anything. In another part, I configure a DataInjector for Document so that
>an IndexingAgent will catalog it and a RuleAgent will email people about the

>addition.

That's the idea.


>> This all sounds rather complex, but that's probably due more to the funky
>> names than anything else.  In all probability the front-end name of
>> "DataInjector" will be "Customizer", and InjectionFolder will be "Folder
>> w/Content Customizer Support".  So, in plain English...  You put your
>> portal content objects somewhere underneath a folder with customizer
>> support if you want to customize them.  You add a customizer to that
>folder
>> for each kind of thing you want to customize.  And you put things in each
>> customizer for each data management, indexing, rule-handling, or other
>> customization you want to make.
>
>This is great! What happens in a scenario like this:
>
>InjectionFolder A
>  DataInjector for Documents
>  InjectionFolder B
>    DataInjector for Links
>    Document
>
>Will the Document in B be handled by A's DataInjector? In other words, are
>DataInjectors acquired?

Yes.  To be precise, DataSkins acquire a _getDataManagerFor() method, which
they call.  The default definition of InjectionFolder._getDataManagerFor()
will look in a dictionary of meta-types registered by the InjectionFolder's
DataInjectors to see if it has one for that kind of object.  If so, it's
returned.  If not, it tries to acquire a parent _getDataManagerFor()
method, and passes the ball on to it, if so.  And so on up the line until a
suitable injector is found or the hierarchy top is reached.


>Also, do you forsee any big performance penalty for all of this wonderful
>flexibility?

I am particularly wary about performance, so I have tried to optimize the
architecture for "runtime" performance at the occasional expense of "design
time" performance.  Thus, adding, removing, and changing injectors,
providers, and agents often has a fair amount of computational overhead to
set up registries and pointers and hooks.  The intention being that at
"runtime" (i.e., use of the DataManagers), things can be looked up in a
dictionary and called right away.  Also, DataSkins only look for their
DataManager when they are retrieved from a container, and usually one
doesn't keep retrieving the same object over and over again in a typical
Zope transaction.

However, the thing that has struck me most about performance as I go along,
is that the thing which will dominate run-time performance is the access to
external data sources (e.g. SQL), not the extra dictionary lookup or two
and extra Python calling level here and there.