On Fri, Dec 2, 2011 at 7:30 AM, Malthe Borch <[email protected]> wrote: > On 2 December 2011 00:22, Daniel Nouri <[email protected]> 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).
Of course modern CMF apps (based on Plone) have another problem here which is that only a quarter of what's going on is in CMF tools (/manage), the rest is inside of components and code all over the place, so it's kind of a bad example. What you're after is traditional-style CMF where the core set of tools were actually meaningful. >> 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. So one problem here seems to be to know which components are in use. Another to make available more information on these components in the browser for developers/admins. Let's take content types: with Kotti, there is a list of enabled content types in the .INI file already. Now to get the same fuzzy feeling that you describe, we could print that list of content types on the web, and add some extra info, what views are registered for them etc. Sounds like a good idea actually, but not something that we'd have to make massive changes for (i.e. it'll work fine on top of the existing 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). Sounds like a particular requirement to me. (Besides, I never found ZODB's control panel very useful.) > 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). If we want to understand what it takes to create a good abstraction for, say, a user management, and what 'general layer' would be useful to allow convenient reuse between apps, then the best way would probably be to try it out, or better: have a real use. There's 'kotti.get_settings()' which can look up Python objects based on dotted names and thus severs as a simple key/value component registry. Then, Kotti's AbstractPrincipals is an abstraction for a user database that tries to be DB agnostic. And then for the templates I guess you'd have to agree on a standard layout macro. Sounds like this could be useful. Not so useful if no one will use it though. The problem with attracting people to use your layers is still there. Also, the more natural way of developing layers is when people start using your software and then they say 'hey it's great but I need this to work with LDAP' and if you're lucky they'll come back with feedback and you'll be able to build a good abstraction. (Or, you yourself use it in different ways.) Personally, I'll try and put more effort into marketing and improvements that'll hopefully more directly attract users to Kotti. The 'Kotti components introspection' page that came out of this discussion would be one such improvement. Others are probably making it more useful out of the box by adding media upload etc. Daniel -- http://danielnouri.org -- 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.
