I thought a bit more about nesting apps. The controller would be set up as:
from myinnerapp.config.middleware import make_app
OuterController = make_app(config["global_conf"], full_stack=False,
**config["app_conf"])
This would push another config onto of pylons.config, but since it's
the same as the parent's config that shouldn't make a difference.
As for the other middleware changes, I was misremembering. The error
middlewares are already under "if asbool(full_stack)". What I had
suggested earlier was that SessionMiddleware and CacheMiddleware also
belong under that 'if' so that the outermost one is used.
RoutesMiddleware, I'm not sure (see below).
On Sat, May 24, 2008 at 12:44 PM, Jonathan Vanasco
<[EMAIL PROTECTED]> wrote:
>
> I *really* like how the modular approach can compartmentalize the
> necessary templates and controllers.
>
> I intensely dislike how the modular approach compartmentalizes the
> routing and model. If something is affecting the routing & model,
> IMHO, it's not a plugin - its a standalone app.
Well, it affects the routing only in the sense that the subapp parses
the rest of the URL -- as it should. If the route is defined as
/subapp/*path_info (a magic name), this should set up PATH_INFO for
the subapp. On the other hand, I'm not sure whether you can nest
RouteMiddlewares and RouteMaps or not. How would url_for know which
set of routes to choose? It just takes somebody to do this and figure
out what works. (The Routes 2 structure I have in mind should help
with this. The middleware puts a request-specific URL generator in
the WSGI environ, which Pylons mounts onto 'pylons.url' -- a
StackedObjectProxy like pylons.request. This should allow the inner
app to see its own URL generator, and the outer app its own.)
As for the model, I forgot about that. That is a bit of a hassle, to
get multiple models to share the same database and connection pool.
Which just means we have to figure out the right standard
configuration for it. One way would be for the top-level
environment.py to set up the engine as normal and then call the
subapp's init_model(). Another way would be for the top
environment.py to initialize its own model, then put the engine in the
config for the subapp to use. That means the subapp would have to
anticpate this happening, though it could check for an engine object
first, and if none was there create its own engine.
> The design we're running with right now... is a core model/
> controller/lib which the main Pylons app inherits.
It will be interesting to see this structure. Certainly, the
controller does not have to use the global templates directory or
render method; if it uses its own templates stored its own way, that
works too.
But then that gets into the issue of the site template. If the inner
app should be shown within the global header and sidebar, then you'd
have to inherit the site template -- which doesn't work well across
apps, plus you'd have to know what variables to set for the site
template. Or the outer app could have a controller ACTION (not a
whole controller) that calls the inner app to get the page content,
and then plugs that into its template. The action could emulate a
WSGI server, possibly using WebOb's application-wrapper for
convenience.
I definitely think there's a huge potential for autonomous Pylons app
components, if we can just figure out the details. Then you could
plug a Pylons wiki or calendar or shopping cart or ticket manager into
a Pylons app in five minutes.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
