[Zope-PTK] Portal content wherever you want it

[Kevin Dangoor]

----- Original Message -----
From: "Phillip J. Eby" <pje@telecommunity.com>
To: "Kevin Dangoor" <kid@kendermedia.com>
Cc: <zope-ptk@zope.org>
Sent: Sunday, May 21, 2000 10:52 PM
Subject: Re: [Zope-PTK] Portal content wherever you want it


> 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.

Ahh, OK. I wasn't sure how high this was on your priority queue, or how far
along you were.

> 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.

Excellent! That's what I was hoping for. It seems like one should be able to
add a "Link" object wherever they want, not just under a "Portal".

> (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.  :) )

:)

Makes sense... Zope's design is very useful for many things... don't want to
uproot everything Zope does. ZPatterns just makes it more flexible.

> >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.

This sounds like a good approach. I think it'll work out fine until someone
wants to programmatically add and remove injectors with each hit :)

> 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.

External data source? What's that? With the ability to mount new databases,
I don't expect to be writing any more SQL. (Though I know that I'm in the
fortunate minority that doesn't need to attach to legacy apps.)

Kevin