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. 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. Feedback welcome. Thanks, \malthe -- 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.
