Ian Bicking wrote:
> Cool. I think this should mean integration with Paste would involve
> extending paste.server.make_app (which clearly exemplifies the
> switch-statement style that OO is supposed to avoid ;):
>
> if conf.get('publish_quixote'):
> from qwip2 import QWIP2
> app = conf['publish_quixote']
> if isinstance(app, (str, unicode)):
> from paste.util import import_string
> app = import_string.eval_import(app)
> if not isinstance(app, QWIP2):
> app = QWIP2(app)
>
>
> This should allow 'publish_quixote = "quixote.demo.mini_demo"' in the
> server.conf to load the demo. I won't be able to test this until this
> evening, but that's my theory.
What is the purpose of Paste's config file? Is it so the user can link
his application to the webserver and middleware of his choice, and
configure everything regarding the application and its environment? Or is
it to allow only a few details to be set by the user (host, port, server
type)? I'd say make server.py generic, and make the user set an
'application' variable with a WSGI-wrapped application, perhaps using
helper classes from another module. That way people can use a different
application type without having to hack it into server.py, and (for
Quixote) can use this qwip or that qwip or anywhere a qwip-qwip without
being constrained by the server.py assumptions.
There's also middleware. The current Quixote handles its own sessions,
etc. But soon there will be alternate Quixote implementation(s) with
these factored out to middleware, or borrowing middleware from Paste or
other sources. Currently server.py loads a certain stack of middleware
for Webware applications, and the user isn't allowed to choose. He can
wrap additional middleware functions around his application, but he can't
override any of the system-chosen middleware. There's a tradeoff here
between frameworks requiring certain services to function, vs allowing the
user to switch implementations in and out, and (in Quixote's case) using
services built into the Publisher vs in middleware. server.py can't
expand to cover all these possibilities, nor will it necessarily have the
best implementation for a third-party framework, so why not delegate those
decisions to the config file (with plug-in helper classes perhaps)?
Is there a rule that config values have to be strings/numbers, or can they
be perhaps a QWIP object? That would eliminate the need for
'publish_quixote'.
-- Mike Orr <[EMAIL PROTECTED]>
_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users
