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() ?
On Friday, September 14, 2012 3:03:41 PM UTC-7, ozwyzard wrote:
> 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() ?
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))
On Sat, Sep 15, 2012 at 12:03 AM, ozwyzard <ozwyz...@gmail.com> wrote:
> 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.
> --
> 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 turbogears@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears?hl=en.
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)?
On Friday, September 14, 2012 4:17:50 PM UTC-7, Alessandro Molina wrote:
> 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))
> On Sat, Sep 15, 2012 at 12:03 AM, ozwyzard <ozwy...@gmail.com<javascript:>> > wrote: > > 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.
> > -- > > 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<javascript:>.
> > To unsubscribe from this group, send email to > > turbogears+...@googlegroups.com <javascript:>. > > For more options, visit this group at > > http://groups.google.com/group/turbogears?hl=en.
On Fri, Sep 14, 2012 at 10:22 PM, ozwyzard <ozwyz...@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.
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.
On Monday, September 17, 2012 10:04:38 PM UTC-7, Michael Pedersen wrote:
> On Fri, Sep 14, 2012 at 10:22 PM, ozwyzard <ozwy...@gmail.com<javascript:>> > 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.
