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

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, but utilities?).

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 singletons?".

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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to