[Baypiggies] Programming Pattern/Django/Best Practice?

Robert Zuber rob at adperk.com
Fri Apr 3 19:06:36 CEST 2009


I'm not so sure that ajax is the silver bullet in your situation.  It  
will probably be a UI improvement and there are great reasons to use  
it, but the django implementation will end up being fairly similar.   
 From my understanding of what you are asking, the subprocess on the  
server side could run for longer than any reasonable timeout for the  
ajax response, so you're still going to want to return a success  
response just to tell the user that the request was submitted.  After  
that, returning a json (or xml) response via django to subsequent ajax  
requests will be no different than returning an html page.

The good news is that either solution should be pretty simple using  
the standard django framework.

Your urls.py entry doesn't have to be dynamically generated, you would  
just pass a unique job_id in the url, with a urls.py entry like:

(r'^status/(?P<job_id>[0-9]+)$', myapp.views.status)

and an associated entry in myapp/views.py like:

def status(request, job_id):
     # here's where you get the status of job_id

The view can easily return whatever content you like, as long as you  
set the content-type header.  There are some decent encoding utilities  
for json included in django.

Unless I've misunderstood your requirements, it all looks pretty  
standard and inside the box from a django perspective, as long as the  
subtasks  / subprocesses are well-behaved in reporting their status  
"somewhere" that your django instance can fetch the info.  And if  
you're concerned about load / scale / redundancy, you'll want to make  
that "somewhere" a place that the instance of django reporting on the  
status doesn't need to be the one that started the job.  A Job model  
would probably be where I'd start, although I obviously don't have  
that much info on your app.  Fwiw, I've found using the django models  
and framework in a separate, non-webserver process to be quite  
straightforward as well.

Hope that helps,

On Apr 2, 2009, at 1:40 AM, Glen Jarvis wrote:

> I need a little help. Anytime I find myself walking off the well  
> worn path I have to ask myself "I bet someone has been here  
> before.... let me see what they did in this situation."
> I have a program pattern that goes something like this:
> 1) Special event occurs, causing a page to be loaded, and therefore  
> Django to process an event.
> 2) The initial processing is executed very quick/simple
> 3) Depending upon step 2, a different Python routine will be  
> executed (maybe not even in Django/Maybe as a subprocess)
> 4) The page is displayed to the user who triggered the event in step  
> 1.
> 5) User can click a 'link' in the page displayed in step 4 to check  
> on status of event triggered
> 6) If the process has not completed, this new page will indicate  
> this; User can reclick and go to step 5. If it has, the new page  
> will be the results of that process. The process is complete.
> Now, thus far, timing has not been an issue - but I've not tested  
> under a heavy load, so I'm sure it will be over time. Steps 1, 2 and  
> 4 can be done in very reasonable time and the user sees no real delay.
> I have two [now 3] approaches I am considering, but both feel very  
> hackish....
> Approach #1
> -----------------
> a. In step 2 above, a guaranteed unique new static page is generated  
> (e.g., 534d423d.html). The contents of this page is "Not complete.  
> Click to check again." The link is the page itself (e.g.,  
> 534d423d.html)
> b. Whenever the Python routine in step 3 is complete, it replaces  
> the page (i.e., 534d423d.html) with the results data information and  
> the process is over
> The strength of this approach is that we're now only dealing with  
> static pages. Efficiency is high. And the process is simple.
> The weakness of this approach is that there's no way to clean up  
> these 'unique' pages except at a later time (by comparing timestamps  
> from when the file was created). I see capacity planning problems  
> with this.
> Approach #2
> ------------------
> A similar approach but with dynamically created urls for this  
> guaranteed uniqueness. I don't know how this can be done truly  
> dynamically since urls.py is not something we want to reinterpret  
> each time. The more I think about the strengths and weaknesses of  
> this approach, the less I see a benefit of doing it this way. I also  
> predict Django will not play nicely with me when I step outside 'the  
> box' with this one.
> Approach #3 (Discovered right before sending)
> -----------------
> [Doh! Ajax would be a very simple solution here.]
> This seems to be a fairly common 'cycle' in web programming. I've  
> seen the pattern many times before in clumsier days with clumsier  
> tools. Does this have a name? Is there any standard approach anyone  
> takes? Best yet, is there a python module already out there that  
> someone knows about that facilities and manages approach #1?  Is  
> there a third  approach I hadn't considered?  [DOH! Just before  
> sending this, I hit myself in the forehead and think of an Ajax  
> approach]. I *must* have this disconnect at step 3 because I cannot  
> guarantee any timely response from the routine to be executed. In  
> fact, some of these routines will be written by others in the  
> future... it's a configurable system where the routine can be  
> plugged in via an API.
> You've already been helpful for being a sounding board comparing  
> these approaches.
> Cheers,
> Glen
> --
> 415-680-3964
> glen at glenjarvis.com
> "You must be the change you wish to see in the world." -M. Gandhi
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies

More information about the Baypiggies mailing list