Nive cms for Pyramid developers
Pyramid gives you all freedom on how to develop your applications and to choose the building blocks and python libraries you need for your application. So even complex applications only have a few interaction points with pyramid.
In this case these points are:
- view registration and lookup including templates, security
- url traversal
- request handling
- translation catalogue handling
- wsgi app integration
And by the way: the cms does not patch or extend pyramid core functions in any way.
However there is one difference between the cms and pyramid: The cms uses a multisite concept and pyramid does not (at least not explicitly). In other words a single pyramid app could run hundert different cms websites. Technically the solution is quite easy: Each cms uses it's own registry (based on zope.component) to handle local configurations and extensions. And views are assigned view predicate functions to match the multisite requirements before being included in the pyramid configuration. This works cool except that you are likely to run into "Predicate mismatch errors" during development.
The idea behind the multisite concept is not really to run 100 websites in one pyramid app but to build a web portal by integrating several websites or split a large site into smaller ones.
The view configuration / registry mentioned above leads to the second big difference: The cms uses it's own subsystem to define and register views. Now, you're not forced to use it to run and customize a website and can use pyramids view registration options as you please. However the reason for the subsystem is that the cms focuses rather on 'view modules' than single views. These view modules are preprocessed and can be altered, replaced or removed through an event system before being included in the pyramid configuration.
Another reason is to provide a single scheme for all kinds of cms extensions.
The options supported by 'nive.definitions.ViewConf' and 'nive.definitions.ViewModuleConf' are the same pyramids 'config.add_view()'. In the end views are registered in the following way:
view=view.view or viewmod.view,
context=view.context or viewmod.context,
permission=view.permission or viewmod.permission,
containment=view.containment or viewmod.containment,
custom_predicates=view.custom_predicates or viewmod.custom_predicates or (self.AppViewPredicate,),
Finally, unlike many other pyramid examples or applications the cms does not use or support the following options:
Paster ini file configuration
The cms can not be configured using paster ini files. It's good to set up server or debugging options but I think ini files are abolutely unsuitable for complex application configurations. You can however specify the configuration file to be used in the ini file.
There are no view decorators used to register views. So using config.scan() for the nive package on startup is obsolete. The reason not to use decorators is simply to maintain transparency and modular extensibility. However developers can use decorators to customize cms instances.
As conclusion: The theory is that in your projects you can use anything you can use in pyramid. But to create modular extensions you have to use the cms' tools and techniques.