Hello! Thanks Alice, the second idea is pretty simple and nice ;-) I was looking for something like that. Thanks again.
(but maybe anyone else has other solution/idea? ;-)) Regards. On 26 Gru, 23:08, Alice Bevan–McGregor <[email protected]> wrote: > 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.
