[Baypiggies] Programming Pattern/Django/Best Practice?
Shannon -jj Behrens
jjinux at gmail.com
Sun Apr 5 02:18:00 CEST 2009
On Sat, Apr 4, 2009 at 11:21 AM, Aahz <aahz at pythoncraft.com> wrote:
> On Fri, Apr 03, 2009, Glen Jarvis wrote:
>> Regardless, this seems to be a fairly common design pattern I've seen
>> over the years. Does it have a name? "Asynchronous web batch process
>> while grabbing final status report at end" is a bit awkward.
> Try something like "long-running background web process".
Aahz is right, and you are right that this is a common scenario. I've
encountered it a few times over the years.
In one situation, I launched a separate thread to do the processing.
Then, I gave the user a page with an automatic refresh of 5 seconds,
i.e. every 5 seconds, the page would refresh. I had user sessions, so
the controller would just look and see if the requisite data was in
the session yet. If not, it would send the user the page to
automatically refresh again in 5 seconds.
If you throw Ajax into the mix, you can get away from refreshing the
entire page, but the controller code is pretty much the same. Instead
of polling the server, you can also use Comet which is an Ajax
technique to get away from polling.
I suggest that you get things working using the refresh approach
first. You can worry about Ajax after everything is already working.
Ajax is like frosting; you need to bake the cake first ;)
I mentioned I used sessions and threads. You can also use a job_id
and processes, or you can mix and match. "RESTful Web Services" talks
about this scenario--"long running requests" or something like that.
I can let you read that part in the book the next time I see you, if
that would help. The main difference is that he uses a job_id instead
of a session cookie. Those RESTful guys tend to hate session cookies
(which I talked about here:
In this life we cannot do great things. We can only do small things
with great love. -- Mother Teresa
More information about the Baypiggies