On Thu, 2011-12-01 at 18:10 +0100, Malthe Borch wrote: > I use Zope 2 every day. It feels like a confession, but it's also a > symptom: there's nothing quite like it for Python (and there's still > something to it). > > What's Zope 2 got to do with Pyramid? Nothing much, but this morning I > had the idea that Zope 2 is exactly what's missing from Pyramid. And > perhaps, it's also the answer to this statement: "but via pyramid > document, we could not find out the right answer." > > Zope 2's got that warm, fuzzy feeling of an application platform. You > can open up the hood and see what's in it by pointing your browser to > "/manage". Ideally, this will bring up all components in the system > and show how they're connected. > > There's plenty of crazy in Zope 2 though. It has a complicated request > broker, an impossible publisher, a complex security design and very > deep object inheritance systems. Most objects also come with "implicit > acquisition" which is sometimes difficult to wrap your head around. > > Zope 2 is also written in a fairly old dialect of Python. The code > isn't always great. It's convention-driven, but this is only > formalized in actual code. Also, some of the designs are problematic > in terms of site performance (and we're not even talking about "web > scale" here). > > I'd like to elaborate a bit more on the idea before I address the > rather pertinent issue of existing efforts (in particular the content > management systems Ptah and Kotti, both written directly for Pyramid). > > There's a central idea in Zope 2 which is persistent configuration > (encapsulated in components or "tools"). This is very different than > global components which was the big idea in Zope 3 (now "Zope > Toolkit"). While Zope 2 has a strongly hierarchical data model, this > is not so with Zope 3.
This is a total sidenote, but... In Zope 3, the analogue to Zope 2's (really CMF's) tools model is multiple persistent component registries each located at a place in the resource tree. When that place is traversed, that registry becomes "the current registry", temporarily replacing the global registry or the last persistent registry traversed as "the current registry". Registry lookup APIs (like queryUtility) participate in a scheme where each registry traversed plus the global registry is tried in order to respond to that lookup. This approach is clever but tends to encourage folks to solve relatively simple problems with complex machinery. For example, they might place a registration in a persistent registry rather than just put one in a global registry predicated on context type or containment type. This wouldn't be so bad, except complete introspection into the system is difficult when this sort of configuration can live in many places. The original author tends to understand it and find it obvious. But since the code doing the lookups isn't explicit about where it expects the configuration to come from, and there's no "single place" to visit to see complete system configuration, the maintenance programmer is usually befuddled. So Zope 3 really does have an analogue of CMF tools, it's just implemented differently. But I'm not keen on emulating it; I'd much rather see a continued use of a per-application registry and generalize adapter/utility/subscriber lookup so each could use arbitrary predicates (like Pyramid view lookups do now). > Pyramid's component registry sits somewhere in-between these designs. > It directly supports named utilities and encourages their use. It's > not difficult to imagine a management interface equivalent to Zope 2's > ZMI which has a component registry as its site root. > > There's a great potential in bringing the various technologies > together in an application server that we can build upon and expand. > > What we've got now is a lot of code and little effort to integrate it. > Any content-based application needs: user management, search, content > factories, unique id service, mail service, cache control, transience > (temporary objects), message queues, logging, statistics, support for > software upgrade, database maintainance, alert systems, etc. > > Let's not reinvent the wheel more than we have to: integrate this once > and define it as the application server. > > What about Ptah? > > https://github.com/ptahproject/ptah > > First, what exactly is Ptah: It's a "fast, fun, open source high-level > Python web development environment". In more concrete terms, it's a > content management system that has been somewhat deconstructed into > "library code". The fact that it's only somewhat deconstructed means > that you can very quickly reconstruct the system. There's even a > tutorial included that does exactly this. > > It's still early days. It's clear that documentation was an > afterthought, but there's some formal documentation in the repository > (as restructured text). It's mostly missing from the actual codebase. > > While a substantial effort has gone into the project, it's a hard sell > without any prose to lure you in. > > It also comes as a single package that spans a lot of functionality > including a complete forms library. It has decided to reinvent quite a > few wheels, although some of them have been ported over and simplified > from the Zope Toolkit. > > Note that Ptah also wants to be an "environment" and it has to compete > on those terms: > > - Where's the design defense? > - Why isn't the codebase littered with excellent prose that might > justify its design? > - Where's the call for collaboration? > > That said, I think there's a lot of good code in there. It might > benefit from being based on the platform I dream about. > > What about Kotti? > > https://github.com/dnouri/Kotti > > Kotti's a small content management system built on SQLAlchemy and Pyramid. > > I think Kotti could sit very comfortably on top of the application > server that I've dreamed up as my Zope 2 on a Pyramid scenario. > > It doesn't want to be an environment as such and that's why it might > be comfortable on top of one. That way, it might focus simply on being > an application and the extension story would be for someone else to > tell. I don't have much to say here except +1 for higher-level systems written using Pyramid. At least very-good-ones-not-written-by-me. ;-) What defines "very good"? It's not particularly technical I think: it needs to have very good docs, lots of tests, and needs to be able to attract and sustain a community of contributors. I'd personally be most attracted to systems that buy in to Pyramid's core configuration concepts like add_view/add_route, view/route predicates, renderers, application settings that are not global, configuration-as-methods-of-Configurator, and use of the config.include mechanism, use of config.settings for deployment settings, and when configuration decorators are used have them be Venusian decorators to defer configuration actions. It'd also be nice if those systems bought in to some of Pyramid's not-so-core configuration concepts like use of scaffolding, use of "paster serve", and the debug toolbar. Bonus points for reusing an existing form library and choosing a single existing templating system rather than inventing more stuff. I have no opinion on data storage. I will note, however, it's more likely to be successful to base an extensible system on traversal-over-persistent-objects rather than URL dispatch and a separate data model, because it's usually easier to extend a tree to add system functionality than it is to shoehorn your way into an ordered route lookup. My personal tastes are likely unimportant to such a system's larger success, however. More important is marketing and docs. - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
