On 2 December 2011 00:22, Daniel Nouri <daniel.no...@gmail.com> wrote: > Kotti likes to sit as closely as possibly on top of Pyramid, thus > Pyramid itself is its 'environment'.
I have recently had the chance to work on a CMS-like system which was also just built straight on top of Pyramid (although it ran against MongoDB). If you just look at it in isolation, it runs great and was really fun to program. I think the problem is knowledge sharing. The common foundation is made up by Pyramid and the libraries involved (and the database), and not at all the component integration, view codes or even general setup facilities. What I was trying to say with my Zope 2 example is that there is actually some level of knowledge sharing and it's not just for the very smart, or the very involved. Quite a few people know their ropes around a Zope 2 application (or perhaps I mean mostly CMF). > Kotti has many of the things that you feel that any 'content-based > application needs' built-in. It has: > > - user management (including local roles) > - content factories (a CMF-like 'type_info' with add permission and > 'addable to') > - mail service (pyramid_mailer) > - logging (Python's logging?) Yes, but there's not a management tool associated with any of these (in the Zope 2 sense of "/manage"); you can't manage or get numbers out of any of these without looking through log files or writing code (or writing a configuration file). I think it depends whether it's a single-developer scenario or a team-based, long-running project, whether you can benefit from any of this "management" stuff. > I'd argue that for 'database maintenance' you should use the tools > available for the SQL database that you use. (Kotti is also not in > the business of building abstractions on top of SQLA.) True, but if you extend database to mean services that you get data from and need to think about invalidation and what's in memory, then there's probably going to be some maintenance of that in an application-specific way. I think specifically of things like Memcached and ZODB (which also has a memory cache). I definitely don't mean building abstractions on top of these. > I believe that 'pyramid.includes' and the available configuration > mechanisms are a very powerful 'platform' of their own. And I'm happy > I no longer have to deal with in-database hierarchical configuration. Right. I think I'm misunderstood. I'm not trying to advocate that 'pyramid.includes' should go away and be put inside a database. What I'm instead saying is that most apps have persistent utilities in one form or another (e.g. an "object catalog" or simpy, "settings"). If these were written for a layer that would sit between Pyramid and the application – in a database-agnostic way perhaps – this might allow for more reuse and better, richer components (i.e. user plugin system with authentication support and user management). \malthe -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
