well. using a template form another project is simple since we are
using the dot notation (project.templates.file). however, you can do
.template.file and it will look in the current project. adding an
config option for that would be a no brainer.
On 5/25/07, Kevin Horn <[EMAIL PROTECTED]> wrote:
> Has anyone considered how to support multiple apps sharing the same
> templates? This would make it easier to combine multiple apps and get the
> same "look and feel". I have seen this requested several times on the TG
> MLs.
>
> Could we make the templates directory a configurable option in the config
> file, which defaults to the standard templates directory? I haven't thought
> the full implications of this through, but it seems like a (relatively)
> simple option that might get us moving towards achieving this goal.
>
> Any major problems with this strategy?
>
> Kevin Horn
>
>
> On 5/24/07, Alberto Valverde <[EMAIL PROTECTED] > wrote:
> >
> >
> > On May 22, 2007, at 11:07 PM, Alberto Valverde wrote:
> >
> > >
> > >
> > > On May 21, 2007, at 10:53 PM, Ian Charnas wrote:
> > >
> > >>
> > >> So are we still on for a TurboGears sprint this upcoming saturday?
> > >> How do we do this? Do we all jump on IRC at a certain time and
> > >> decide
> > >> what to do?
> > >
> > > It'll be probably be good to open up a page in the docs.tg.org wiki
> > > to make some planning...
> > >
> > > I'll be in to work on a new test infrastructure to eventually port
> > > all failing controller tests to put TG back in the "green" zone. The
> > > other big task needing work is poring the config module to CP3's new
> > > config system . Some coordination between my work and the "config
> > > team" is needed since a pre-requisite to my part is to have a TG app
> > > nicely wrapped in a WSGI app (possibly with a paste.app_factory entry-
> > > point implemented) since I'm planning to use paste fixture for the
> > > testing.
> > >
> > > Some notes + brainstorming:
> > >
> > > CP3 uses the Application object to create the mentioned WSGI app
> > > which receives the app's config as a constructor's parameter so we'll
> > > have to agree on how we create initialize this object. Maybe
> > > something like this:
> > >
> > > - add a new wsgiapp.py module inside quickstarted apps which
> > > implements the paste.app_factory entrypoint to return a TG/CP3 app.
> > > This module uses some helper functions inside TG's startup.py (or
> > > even a TGWSGIApp Application subclass) to initialize and stack TG's
> > > specific middleware (none ATM, expect EvalException, but we need to
> > > leave room for future growth).
> > >
> > > - This entrypoint could be called by PasteScript's paster passing a
> > > paste.deploy config file which would override config parameters
> > > defined in well knownt app.cfg et al. tg-admin should grow a new
> > > "serve" commad (which delegates to paster serve) which loads a TG app
> > > with no paste.deploy config and mounts it at /. This new "serve "
> > > commands deprecates good 'ol start-myapp.py (which can be left as a
> > > backwards compatibility artifact which simply delegates to tg-admin
> > > serve).
> > >
> > > A quick mental topological sort leaves tasks in this way:
> > >
> > > 1) wrap TG apps with CP3's Application object
> > > 1.5) (at this point I can start migrating the testing framework)
> > > 2) this Application object receives an app config dict so... adapt
> > > current config.py so it can load TG' config and pass it to the
> > > Application constructor. The "config" team could work on a rewrite of
> > > the config module so it produces a properly formatted config dict to
> > > feed to Appliaction)
> > > 3) implement the paste.app_factory entry point which can receive a
> > > *possible* paste.deploy config or a dummy one that points to app.cfg
> > > and returns this WSGI app object. The possible paste.deploy config
> > > should override values in app.cfg if present.
> > > 4) implement the tg-admin "serve" command
> > > 5) glue all this together so "tg-admin serve my.config" launches a TG
> > > app and start-myapp delegates to this
> > >
> > > Sorry for my poor communication of this ideas.... I'm speaking from
> > > memory and it has been months since other work has displaced this
> > > task from the foreground of my badly multi-tasking brain ;)
> >
> >
> > Yesterday I comitted some changes on the trunk implementing these
> > ideas. Some comments:
> >
> > - turbogears.config is now a paste.config.DispatchingConfig which
> > provides conetxtual config for each TG app mounted in the same
> > process. It preserves the original inteface (update_config, update,
> > get) plus, being a proxy to a dict, has now other useful methods like
> > items, __getitem__, __setitem__, etc ("items" will be specially
> > useful in view.load_engines to dump all available template engine
> > options to each engines, no need to "cherry-pick" them one by one.
> > It's structure is something like this:
> > {"/": {config options for the current app, this key is accessible at
> > cherrypy.request.config during a request},
> > "tg_widgets": {tools.staticdir.on: True, tools.staticdir.dir:
> > "some_dir"},
> > ....}
> >
> > The preferred method of accessing app configuration is through
> > turbogears.config which proxies to the dict that was merged with the
> > apps config at the app factory. cherrypy will use each path's key
> > when calclating which tools to apply depending on the path.
> >
> > - The WSGI app is built inside the users app at
> > myapp.wsgiapp:WSGIApp.app_factory.
> >
> > This is the paste.app_factory entry point. Most work is done in the
> > superclass (defined in turbogears.wsgi) but, being the final subclass
> > available inside the users app it allows for easy customization, eg:
> > * __call__ can be overriden to execute per-request actions, branch to
> > other wsgi apps, etc... This function has the WSGI app signature
> > (environ, start_response) so the full flexibility of WSGI is
> > available at this point.
> > * app_factory can be extended to further wrap the app in middleware
> > between the resuting TG app (and all its middleware) and the server
> >
> > def app_factory(self, global_conf, root=None, full_stack=None,
> > **app_conf):
> > app = super(...).app_factory(....)
> > app = MyMiddleWare(app, ...)
> > .....
> > return app
> >
> > Note that middleware stacked here will be outside TG's context
> >
> > * __init__ can be overriden to stack middleware below the TG app.
> > This middleware will be inside the context of the TG app:
> >
> > def __init__(self, root=None):
> > super(....).__init__(root)
> > self.wsgiapp = MyMiddleware(self.wsgiapp, ....)
> >
> > Note that this middleware can also be declared in the CP3 config file
> >
> > - There are some architectural changes needed to allow for multiple
> > apps per process:
> >
> > * We're making heavy use of module globals for customization
> > (view.variable_providers, view.loadBases, scheduler, database.engine,
> > etc...) This should be modified because these globals will be shared
> > by all instances of TG apps used in the same process, extension
> > authors should pay special attention to this...
> > The solution I've comed up with is to provide a proxy at
> > turbogears.globals which proxies to app.globals (a globals object
> > bound to the WSGI app that wraps the root controller). This way all
> > these globals will be in the context of the WSGI app that configured
> > them during a request. I've implemented view.engines this way (so
> > each app can have it's own kid.defaultoutput, etc...) but others
> > still need to be ported/rewritten (database.engine, scheduler, etc)
> >
> > - Since the app_factory ep is implemented, paster can already be used
> > to launch a TG app. I've made the changes needed to the quickstarted
> > template so you can try it out like this:
> >
> > $ paster serve depoly_cfg.ini
> >
> > Which should have the same effect as calling start-myapp.py (I've
> > rewritten start_turbogears so 1.0 startup scripts remain compatible).
> > start-myapp.py should be deprecated so all apps are loaded using the
> > paste.deploy API. Since the minimal deploy ini config file is so
> > simple, "tg-admin serve" could emulate what it does when no
> > deployment config is specified, so when you run "tg-admin serve"
> > inside a projects egg it should start up the app automatically. If a
> > deployment config is passed as a parameter, it should use that
> > instead. Some cool things you can already do with this:
> >
> > [DEFAULT]
> > [server:main]
> > use= egg:PasteScript#cherrypy
> > host = 0.0.0.0
> > port = 8080
> >
> > [composite:main]
> > use = egg:Paste#urlmap
> > / = app1
> > /app2 = app2
> >
> > [app:app1]
> > use = egg:TestApp
> > app_id = app1
> > tg.config_file = %(here)s/dev.cfg
> >
> >
> > [app:app2]
> > use = egg:TestApp
> > tg.config_file = %(here)s/dev.cfg
> > app_id = app2
> > kid.encoding = iso-8859-1
> > kid.outputformat= xhtml
> >
> > This will mount the same TG app at / and /app2 but with different
> > configuration settings (they could even use different dev.cfg and
> > dev2.cfg) and serve it with CP3's wsgi server (swap it with Paste's
> > if you feel inclined to for didactical purposes)
> >
> > Please note that multiple apps per process is still broken since we
> > use so many module globals. I haven't tested it yet but, for example,
> > I believe both apps would share the same db engine... this needs to
> > be sorted out.
> >
> > Some low hanging fruit we need need to address:
> >
> > * rewrite view.load_engines so it all template plugin confg options
> > can be used. Maybe even replace the whole view module and implement
> > it as a class we can instantiate and bind to turbogears.globals so
> > each app has it's own configured set of engines. This is implemented
> > in TW as the EngineManager... maybe we can take ideas from there, or,
> > better still, factor it out into an independent egg both TW and TG
> > can share.
> > * Move the scheduler to turbogears.globals, so each app has it's own
> > scheduler
> > * Ditto with database.engine
> > * more I'm failing to recall....
> >
> > Some more complex stuff:
> >
> > * Move all module globals: view.variable_providers,
> > turbogears.call_on_startup, etc so they're bound to each app. This
> > will require a change to the extensions API to work properly,
> > however, a proxy can be left at the original location for backwards
> > compatibility. This allows for a smooth degradation: non conforming
> > extension will still work in a single app per process scenario, but
> > will break when multiple TG apps cohabitate the same process.... this
> > will put some pressure on extension authors to upgrade them ;)
> > * Write the new testutils using paste fixture to port all TG
> > controller tests.
> > * more I'm failing to recall....
> >
> > Well, gotta run now... comments welcomed :)
> >
> > Alberto
> >
> > PS: Looks like Saturday's sprint is going to be lots of fun! :)
> >
> > > >
> >
>
--
cheers
elvelind grandin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" 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/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
