reference to app
Eric Lemoine
From a controller can I get a reference to the app (i.e. what's
returned by middleware.make_app)?
Thanks,
--
Eric Lemoine
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex
Tel : 00 33 4 79 44 44 96
Mail : eric.l...@camptocamp.com
http://www.camptocamp.com
Wyatt Baldwin
> Hello
>
> From a controller can I get a reference to the app (i.e. what's
> returned by middleware.make_app)?
Right before `return app`, you could do `app_globals.app = app` (in
fact, I think the docs for 1.0 say to do `config.app = app` anyway).
However... there's a potential issue here in that if you define
filters or a pipeline in your paste config, the app returned by
make_app will be wrapped with those other apps, so the one you saved
won't be the "root" app, which may or may not matter for your
scenario.
Having said that, it seems to me that there *must* be another way to
get at the "root" app, but I didn't dig very hard. I also ended up
rewriting the code I had that utilized `app`. I'm not sure, but it
might be a bad practice to use/need `app` in that way.
Mike Orr
<wyatt.le...@gmail.com> wrote:
> On Mar 17, 10:27 am, Eric Lemoine <eric.lemo...@camptocamp.com> wrote:
>> Hello
>>
>> From a controller can I get a reference to the app (i.e. what's
>> returned by middleware.make_app)?
>
> Right before `return app`, you could do `app_globals.app = app` (in
> fact, I think the docs for 1.0 say to do `config.app = app` anyway).
I think Pylons did that as a kludge because it needed access to the
app. (The config initialization was reorganized to make it friendlier
to nested applications, and apparently that severed the direct link
between the app and some part of Pylons.) I'm not sure if I like
setting ``config.app`` that way, but I'm not sure it's necessarily bad
either. ``config`` is where I'd look for the app if I were trying to
find it.
> However... there's a potential issue here in that if you define
> filters or a pipeline in your paste config, the app returned by
> make_app will be wrapped with those other apps, so the one you saved
> won't be the "root" app, which may or may not matter for your
> scenario.
>
> Having said that, it seems to me that there *must* be another way to
> get at the "root" app, but I didn't dig very hard. I also ended up
> rewriting the code I had that utilized `app`. I'm not sure, but it
> might be a bad practice to use/need `app` in that way.
Not sure about this. Paste.composite is outside the realm of what the
application code should be caring about?
--
Mike Orr <slugg...@gmail.com>
Eric Lemoine
In my case I think I'd like the root app. Here's what I am up to:
create a controller responsible for live-testing the application. So I
was thinking about something like that for this test controller:
class CheckerController(BaseController):
def index(self):
# creating test app
app = config["map"] # ???
app = TestApp(map)
# test entry controller
response = app.get(url(controller='entry', action='index'))
assert "app.js" in response
# test print controller
response = app.get(url(controller='printer', action='info',
var='printCapabilities'))
assert 'printCapabilities' in response
assert '"scales":[' in response
return "green"
Maybe I'm not taking a good direction, and I'd rather use urllib or
something and do actual HTTP requests to the application.
What do you think?
Mike Orr
I'm not an expert on test fixtures or composite apps. But given that
you're trying to do live testing on the same application, it may be as
good approach as any if it works.
Although I would tentatively argue that the standard config.app in
setup_app() should access only the application defined there, not some
root application beyond it. That you would put the root application
somewhere else to confusing people who may look at/maintain the
application later.
--
Mike Orr <slugg...@gmail.com>
Wyatt Baldwin
> On Wed, Mar 17, 2010 at 11:24 AM, Wyatt Baldwin
>
I was thinking more of filters or a pipeline of filters, but that's a
good point. The thing is, it's not necessarily clear where middleware
should be defined... Or, maybe it is: it's probably best to put
*required* middleware in `make_app` and only optional middleware
should be defined in a config file. I think back when I was asking
about this same thing, I was getting that wrong--i.e., putting things
in a config file that really belong in `make_app`.
Mike Orr
I'd rather put all middleware in Python code rather than in a config
file. That way if anything goes wrong you'll have a straightforward
traceback rather than having to debug a config file.
Generally, variables go into the config file if they might differ in
different deployments, or into environment.py if they're the same for
all deployments or if the application would break if they're not set
to a certain value. But it also depends on the type of variable: the
config file can represent only a few types.
--
Mike Orr <slugg...@gmail.com>
Jonathan Vanasco
my app/__init__.py file always has this bit:
====
import sys
appdir= sys.path[0]
appexternals= "%s/##APPNAME##/lib/externals" % appdir
sys.path.append(appexternals)
import OpenSocialNetwork
OpenSocialNetwork.appname= '##APPNAME##/'
====
osn is a microframework that's in lib/externals ( as are various other
modules ; i find it easier to maintain apps like this ) ; this code
does nothing special, other than stashing the appname -- however once
that's done, it makes life a whole lot easier trying to access
different modules within the app from the microframework , which is
what I think you're trying to do ?