TG App Bootup tasks

60 views
Skip to first unread message

ozwyzard

unread,
Sep 14, 2012, 6:03:41 PM9/14/12
to turbo...@googlegroups.com
I have a scenario where I need to kick start app tasks (e.g. send reminded email with URLs in it) upon re-start of a TG app.  The stale tasks need the tg.url in the context.  I also have a "pure" tgscheduler instance that I start when the app starts.  I cannot call the app task from the tgscheduler instance since it chokes on (TypeError: No object (name: url) has been registered for this thread).  Further searching tells me that request context is not setup in my pure tgscheduler instance.

Question:  Should I schedule bootup tasks in/around make_app() ?

Thanks.

ozwyzard

unread,
Sep 14, 2012, 7:09:57 PM9/14/12
to turbo...@googlegroups.com
More info:

I am using the following entry in app_cfg.py to invoke an init routine that starts the tgscheduler..

# scheduler
base_config.call_on_startup = [sched_init]

Alessandro Molina

unread,
Sep 14, 2012, 7:17:47 PM9/14/12
to turbo...@googlegroups.com
As tg.url generates urls using the HTTP request that is serving to
retrieve things like the domain and where the app is mounted it is
actually not possible to call it outside a request.

You should probably write somewhere the domain which the links you are
generating should point to and make urls from that one using something
like: '?'.join((mydomain, urllib.urlencode(params))
> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/turbogears/-/ZRsYIyTtRrMJ.
> To post to this group, send email to turbo...@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears?hl=en.

ozwyzard

unread,
Sep 14, 2012, 10:22:44 PM9/14/12
to turbo...@googlegroups.com
Thanks.

For now, I might just reassign an existing base-url-variable in the exception handler.

Ideally, I'd like tg.url to do the work of deducing the base_url of the app; else I'd have to deduce it programatically by rummaging through config vars like base_config and app_conf.  I could write the base_url in a global variable, but if I were to use tg.url, it would require at least 1 incoming request.  Is there a way for me to figure out the mount point without using tg.url (e.g. poke somewhere in pylons)?

Thanks.

Michael Pedersen

unread,
Sep 18, 2012, 1:04:34 AM9/18/12
to turbo...@googlegroups.com
On Fri, Sep 14, 2012 at 10:22 PM, ozwyzard <ozwy...@gmail.com> wrote:
> Ideally, I'd like tg.url to do the work of deducing the base_url of the app;
> else I'd have to deduce it programatically by rummaging through config vars
> like base_config and app_conf. I could write the base_url in a global
> variable, but if I were to use tg.url, it would require at least 1 incoming
> request. Is there a way for me to figure out the mount point without using
> tg.url (e.g. poke somewhere in pylons)?

Okay, I'm trying to catch up, so can't dig too deep for the full
answer to this right now. I can tell you that you're going to be
limited in your ability to do this the way you want.

If you go through WSGI, you'll find that a WSGIScriptAlias gets set
up. You can use that to get the relative path to the top of the web
server. However, that does still leave you with an open question: What
domain is being served up for this? So far as I can tell, WSGI doesn't
provide the domain, so you are not able to use any code to determine,
programmatically, the domain to use. That's only resolved by issuing a
request to that domain.

This can help, but you're still going to have to have something,
somewhere, to tell you the domain for the links to send out.

--
Michael J. Pedersen
My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen
Google Talk: m.ped...@icelus.org -- Twitter: pedersentg

ozwyzard

unread,
Oct 12, 2012, 8:37:19 PM10/12/12
to turbo...@googlegroups.com

No worries.  I dealt with the issue a while back by a try-except block that tries to use tgurl, and falls back to either a config.get() value or a hard-coded URL value.
Reply all
Reply to author
Forward
0 new messages