Howdy!
So, i have one project/package named "cms" and many other projects
using cms (pyramid projects site1, site2, site3 etc.). The problem is
that cms need to import information about models (DBSession) from the
current project.
I worked around this problem (associating externaly defined models with
your application's DBSession) in two ways, the first was scrapped after
I had to stop using TurboGears and wrote my own framework.
:: Have a function to gather CMS models and inject DBSession into their
scope, or inject the model into the application's scope.
This is fairly self-explanatory; you use, say, a setuptools entry
point, iterate through them, and monkeypatch your core application's
DBSession in.
The second half of it implies creating a model.py model in your
application that then ends up containing every object ever used by the
CMS in a single module.
The problem here is requiring boilerplate code within applications that
want to use the CMS, and likely some fairly hefty locals() jery-rigging
at the global scope of the model.
:: Utilize multiple database support to make the CMS independant from
your core model.
This has two major benefits:
a) You can, in theory, have no model in your application.
b) It's flexible: You can point the CMS data somewhere else, or the same place.
Though it still needs to be combined with entry point iteration to tie
CMS module models in, that code is central to the CMS library, then,
not embedded in the consuming application's model.py file. (I want my
own CMS to be as easy to use as adding two lines to an INI, importing
the CMS root controller class into your own controller tree, and
creating an instance of the class somewhere.)
This has the (possible) side benefit, in my case, of not actually
requiring a client application at all! The paster INI file can easily
point the root controller at the CMS's root controller; then creating a
new "site" is as easy as writing a single INI file, no more. (I've
used this method quite successfully across a number of projects, with
customizations to the CMS - themes and the like - as separately
installed modules.)
Whether any of this is viable under Pyramid I could only guess; I'm
pretty sure it should be possible, though.
- Alice.
--
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.
