Martin Aspeli wrote:
Martijn Faassen wrote:
The Zope component architecture is not about seeing explicit calls
into it everywhere. That's not the point of it. The point of it is
about making applications more flexible by allowing people to plug in
components. My approach allows you to do that.
Sure, but I also think that the CA has given us a few very basic, very
flexible idioms (adapters, utilities, subscribers) that permeate any and
all zope 3 applications. Internal consistency is a very good thing in a
A not-quite-global Session variable is another pattern to achieve what
we do elsewhere with global unnamed utilities when we use them as
effective singletons. Having two patterns to do the same thing is not good.
It's not quite the same. While a utility can be scoped per application,
the Session class also takes care of scoping per thread. I'm not sure
whether utilities can be convinced to do so (sites are local per thread,
SA's ScopedSession also takes care of creating and caching individual
sessions for each thread (and application), something utilities don't
really do either. So you'd still have to use ScopedSession and register
that as a local utility somehow, or do some componentry I can't wrap my
head around yet. I have a strong suspicion it'll become a lot more
complicated than my approach (and not more flexible). I'm trying to go
with the flow for *both* frameworks. The code is pretty simple right
now, and this is a good sign.
Put the question another way - a new user may ask, "why don't I have a
global thing with a capital first letter like Session to look up other
A new user won't ask such a thing, as it looks like he's importing and
instantiating a class. Classes are singletons, and they're imported.
I've actually wished for a long time that utility lookups could be made
to look more like imports. :)
It's a question a very experienced user might ask.
Anyway, the balance can come out somewhere else. People are free to
write their own integration approaches, it's just that mine is
actually about trying to make exactly this pattern work in the first
place. Then when I succeed people want it changed. :) Anyway, no
surprise: I knew that some want other patterns, and I'll be curious to
see the other approaches as well.
I'm not saying it's wrong, and I do think "natural" SQLAlchemy is a
strong selling point, since I'd wager there are more SQLAlchemy users
than Zope 3 users out there. I just think we need to be careful about
what patterns we promote and how it fits with the rest of our "story".
I want to promote the "import Session and instantiate it" pattern. :)
If people want to override certain behavior of session creation, *then*
I want to promote the "implement and register a utility that provides
this interface" pattern. I hope to supply the user with enough
pre-implemented IDatabase utilities that this is rare, so that they just
end up registering them. A simple global one, and a local one that
allows for flexible engine configuration somehow.
What the Zope 3 integration I propose changes is how Session is set up.
By using utilities we can offer flexibility to set it up globally or
locally with ZODB-stored configuration. We use SA's mechanism of
actually creating and managing sessions. I think that's a good division
of labor: hook into SA with a bit of Zope 3 component architecture for
configuration and pluggability, and leave the rest to SA.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -