|
============================================================ Experienced Django programmers click here and skip the basic tutorial below ============================================================ So what is Django?
I'll quote Jacob Kaplan-Moss here, one of the creators of Django to answer that --------------------------------------------------------------------------------------------------------------------- Ok.. Enough fluffing... Lets get to the links. If you don't want to read the rest of the thread and just want to start coding here are your links. Django Website - http://www.djangoproject.com/ Django Download - http://www.djangoproject.com/download/ Django Install - http://www.djangoproject.com/documentation/install/ Django Book (best starting guide) - http://www.djangobook.com/en/1.0/ Reference Materials (always have these in an open window when your starting) - Django Model Refernce - http://www.djangoproject.com/documentation/model-api/ - Django DB API - http://www.djangoproject.com/documentation/db-api/ --------------------------------------------------------------------------------------------------------------------- I'm going to teach you the power of Django and show you how to write a quick piece of blog software at the same time First off. This thread is not about Python. Sorry. If you need to learn Python I highly recommend Dive Into Python a free web based book that will easily give you enough information to start programming in Django. Second off. This thread isn't a primer or a teaching thread about MVC designs. Hopefully you at least already know what it is and why you should be using them. If you are still writing raw SQL code, that looks like SELECT * FROM articles WHERE ID=$_GET['article_id'] in a PHP file that also contains HTML code then you have some reading to do outside this thread. Your welcome to stay and follow along but, you may get lost along the way. If you post questions surrounding a topic like this please don't be shocked when people either: don't respond to you, mock you mercilessly, or just give you links and don't answer your question. Thirdly. I'm gonna dump you off the the Django Installation instructions (Recommended install instructions for Windows Users). Sorry.. I don't really need to rehash everything thats included in the links. I (and other people in this thread) will be glad to help you out in getting the framework installed and running. So you have a functioning and running version of Django up.. Good 1) Lets create a project code:
code:
So lets make sure you configured Django correctly. In the command lets type the following and you should see the following code:
Now lets do what it says. We need to configure Django to use a DB to actually do really useful things. Let's open settings.py and look at the DATABASE_* information. I'm going to use SQLite just for ease of use here but, your welcome to use whatever RDBMS you wish. Django supports postgre, mysql, sqlite3, oracle, and maybe MSSQL soon (I know it was in discussion). Here's what my settings.py looks like now (just the DATABASE_* section) code:
Scroll down a bit in the settings.py file and we'll find the section called "INSTALLED_APPS". We are going to add the folowing line to that tuple: django.contrib.admin to make our INSTALLED_APPS look like the following code:
We need to now sync the database that we told Django about (Django won't create the DB so create it if you haven't already) At the command line code:
code:
code:
code:
code:
http://127.0.0.1:8000/admin Pretty huh... Go ahead and log in with the superuser that you told Django about earlier. Go ahead and poke around and come back when you smiling. If you've developed a web application before you'll soon understand just how drat cool this backend really is in a bit. OK.. So I have a admin screen. Lets actually do something here. Remember when we first started we typed in django-admin.py startapp main? That's an application and our Django project (blog) needs to be told that the application 'main' exists. We do that simply in the settings.py file in the INSTALLED_APP tuple that we added 'django.contrib.admin' to earlier. So lets open settings.py again and add 'main' to the tuple code:
quote:NOTE: MY EXAMPLE USES DEPRECATED CODE READ BELOW Now lets define our data here for our blog. In models.py I'm going to add the following. code:
We have a real simple data model but, I want to wow you before we get into the nitty gritty here so go back to the command line and lets update our database with our new fancy model! (we're going to run python manage.py syncdb again) code:
Click on the humorously named "Categorys". See this? A pre-built CRUD interface. For any type of model that we define. You have a semi-yet? Ok.. It's not quite that cool but, it's gonna be. I promise. First lets fix that stupid "Categorys" things. Django will automatically pluralized all your model names but, doesn't quite work well with 'y' to - 'ie' yet but, we can fix that. Open up models.py again and add the following line to make your models.py looks the same as mine code:
If you haven't already go ahead and create a Category in the admin interface. Heck create 2. We're going to take a quick dive into the python shell and talk about the DB API before we create a more complex model. (You've created 2 categories by now I hope) Let's open the python shell a bit differently than normally here since we want to make sure we get all the needed Django bits. At the command line we are going to type in "python manage.py shell". A normal python shell has popped up but, it has some namespace stuff preloaded in it for our convenience. (Side note.. My copy and pastes are going to look a bit different here since I'm using the iPython interactive shell. I'm note going to use any commands that aren't included in the basic shell.. It just looks different.. Imagine the In[1] is actually >>> and it'll be normal again) In the shell the first thing we want to do is load up the model that we just defined code:
There's a lot of stuff in the Category class that Django put there for us but, most of the time we are going to use the 'objects' part. It has all sorts of real cool functionality. Lets get all of our Categories. code:
code:
Let's play with this object real quick. code:
code:
code:
code:
code:
Now.. All you PHP programmers. I just defined a data structure. Created an admin interface. Managed a list of objects. Altered an object. Created a new object. All without really writing one line of complex code or one smidgin or SQL. You should have a semi-by now. If you don't then your probably a girl and your nipples should be hard then... Lets go define our second model for our blog here. Go back to models.py and we're going to make one quick addition first before defining the new model. We want to able to tell what user wrote what post but, we need to first load the user model into the scope we're working in. Like I mentioned a while back Django won't do some things because it doesn't want to be overbearing and just be everywhere all the time. It's actually quite polite like that. We're going to add the following line to the top of the models.py file code:
code:
code:
Yeah... I guess we're used to this by now. Make a model and sync the DB and wow.. It show up here. Well click into Blog Posts and go create a new one Thats pretty cool right? You start typing in the Title field and the slug gets pre-built. Choose your category pre-populated from a drop down. Choose your author from a pre-populated drop down. Push save! Blog post... All your did was define the data models. Imagine how much time you had spent building back ends to your data models before. Lets create one or two posts here so we have some data. Place them in different categories so there's some differentiation. Lets go back into the Python shell and play for a bit ($ python manage.py shell) We need to load the models that we defined first off code:
code:
[3] We are loading all of the objects in BlogPost into the variable all_posts (this is a list) (it's a list of BlogPost objects) [4] We are taking the first object (index 0) from all_posts and putting it into one_post [5] We can see that the one_post variable is a BlogPost object [6] one_post.Category is a Category object instance (that foreign key reference in the model description) [7] one_post.Category.Name... we can go right into that object and get any attribute we want. This is a very powerful feature. Name was defined in the Category model [8] In the same way we can go into the foreign object Category we can go into the Foreign User object here too [9] Same thing... we can access all the attributes of the foreign related object Let's change the category that the BlogPost one_post lives in. Walking through the code here, we are going to get a new category (BEEES!) and assign it to Category attribute of one_post and save it. code:
We've been able to get all the blog posts with the objects.all() method but, what if we just wanted the posts in the category "bees" that would be useful for our software code:
[18] lets assign a_category to the objects in the all_categories list with the index 2 (which is the beess!! category) [19] just make sure I got that right [20] assign posts_in_category all the posts in 'a_category' using the objects.filter method. --- We are telling BlogPost to find all posts in which the Category is the same as 'a_category' [21] print out posts_in_category Now Python loves lists... Even lists of objects and we can use a for loop to interate through all these. code:
Lets hop back to the Admin interface real quick and look at the list of BlogPost objects. That's not very helpful. Just listing the name there. We have a lot of information in the model but, it's only displaying the name. Well, like I've said before. Django is will only do what you tell it to. How do we get more information here? Lets go back to the models.py and to the BlogPost Model code:
code:
Check out the filters... Especially the date filters. I love that... Ok.. We have all of this but, we still don't have a webpage.. Lets get started on that. This is where we start getting to the meat of a web app. For people who already know Django, I'm skipping generic views here for teaching sake.. Yeah. I know we should use them but, they can be confusing when your first learning. Let's make a really stupid 3 HTML page website. Django's view system and template system can do MUCH MUCH more but, we just want HTML output for right now and this is a really fast way. I HIGHLY recommend you now add basic Django view and urls.py documentation and the Django template reference to your ever growing reading list. Don't worry.. You won't use everything in there at first but, it's good to have a mile-high view before diving in. I'm going use this ridiculously simple HTML example as a basic template for my front page code:
This file is going to be created in our blog project root in a new directory called templates and be called front page code:
This following topic is a bit like skinning a cat. I've never heard anyone tell me, this is the proper way to do this. It's listed as one of the methods in the official documentation and it's the method that I find most flexible but, it's certainly not the only way. Also note that you don't even need to use the built in template system. Just import your own in and use that. Django doesn't care. But, caveat empor..This is my personal method and may not be for everyone. First lets open up urls.py and add a line to make our front page code:
Open up main/views.py and define the front_page view code:
First we need to import the objects that we need. We're going to add these lines to the top of our views.py file code:
Lets take care of that HttpResponse error that Django is still yelling about. We're going to make the function front_page return a HttpResponse object. Here is my views.py file now code:
We want to load the HTML file that we created before as a template so we need to tell Django where to find our templates (remember that subdiectory we created). So open up settings.py and scroll down to TEMPLATE_DIRS. You must use absolute directories and remember when you deploy your app to change this. I've forgotten that a few times and it's a little detail that is easy to overlook. Here's what the TEMPLATE_DIRS portion of my settings.py looks like code:
code:
code:
So the template is now getting feed the categories we need to replace them so they show up. Lets open back up frontpage.html. This is where pre-reading the Django Template Reference is going to come in handy Remember.. the 'all_categories' variable we are passing the template is a list of objects just like in the DB API (remember that for loop?). We can reference that objects in the same way (pretty much, in most cases) in the template engine. So in the HTML code I can say a_category.Name and it prints the name or a_category.id and prints the ID. I can also use the same for loop and loop through the list. So here's my modified frontpage.html now code:
Now we want to print the last 5 posts on the front page (we are going to skip pagination since I'm tired at this point... But, this is just a simple example and I'm running into the 50,000 character limit on a single post... oh god I've written too much) Back into views.py I'm going to load 5 blog posts. code:
code:
Some of the more powerful simple features of Django. Let's quickly go through the next two pages, since hopefully you've caught on here. I'm only going to stop to explain new things from now on The Category page. Alter urls.py to add the line code:
code:
code:
code:
code:
code:
It's a very powerful, and very open framework. You can mostly pull out any component and replace it with whatever you want. ATLbeer fucked around with this message at 23:39 on Mar 7, 2008 |
# ? Mar 5, 2008 23:18 |
|
|
# ? Mar 28, 2024 19:58 |
|
Official Django Resources:
Blogs about Django Development:
Django Powered Websites:
Django Modules:
ATLbeer fucked around with this message at 02:40 on Mar 6, 2008 |
# ? Mar 5, 2008 23:18 |
|
That's one hell of an OP. I'll kick off the stupid questions: I've been coding small Django apps mostly for personal use for a while now and it's awesome. However, I don't think I've ever had cause to use anything other than render_to_response from django.shortcuts. Am I an idiot for using it exclusively? If so, what should I be doing instead?
|
# ? Mar 5, 2008 23:39 |
|
Git posted:That's one hell of an OP. I'll kick off the stupid questions: Like mentioned in the OP... There's a dozen different ways to render out in Django. Or just use an entirely different render engine entirely... So far I've seen - My method of loading the template, loading a context object, using template.render to parse and return to HttpResponse - render_to_response passing in the template and a tuple of objects - the RequestContext handler passing the request, a tuple of objects, and then use the template.render again Honestly.. It doesn't really matter. The variables all get passed to the template in the same manner. I went through all the manners and even though my method is MUCH MUCH more verbose than render_to_response I prefer it merely because it is verbose. I can easily understand the code mostly because I'm a visual person and I tab out my tuples to line them up vertically for easy visual reference. Any way is OK and I have not heard of a "best practices" method around the topic.
|
# ? Mar 5, 2008 23:48 |
|
Git posted:That's one hell of an OP. I'll kick off the stupid questions: Yeah mostly you'll use render_to_response, but what you can also do is return 404 errors or 403 redirects. A nice thing to take advantage of is that you can return other views, just with different parameters, which can be very useful sometimes.
|
# ? Mar 6, 2008 00:17 |
|
Yes, render_to_response() will be used in the majority of situations, especially since you can give it a RequestContext in order to use context processors (although I do this often enough that I tend to write my own render() which is just a 2-line shortcut to doing so). The rest of the time I tend to be returning a Response subclass generated in some non-template-related fashion such as a simple CSV output, or an HttpResponseRedirect; or aforementioned 404/403 via 'raise Http404' or 'raise Http403' (if there is no 403 then I must've made my own at some point, heh).
|
# ? Mar 6, 2008 00:21 |
|
quote:The 'D' is silent dumbass Then why didn't they just name it "Jango"??
|
# ? Mar 6, 2008 00:48 |
|
rotor posted:Then why didn't they just name it "Jango"?? Ask this guy
|
# ? Mar 6, 2008 00:49 |
|
A note about the OP, you define __str__ in your models, however when you query the db using the api it's attributes are unicode, which I believe means you are using svn, and therefore you should have defined __unicode__ instead, let me know if I'm wrong, either way: yay django, and use trunk
|
# ? Mar 6, 2008 00:58 |
|
rotor posted:Then why didn't they just name it "Jango"?? I'm going to laugh if it has to do with the jazz guitarist Django. I forget his full name.
|
# ? Mar 6, 2008 01:02 |
|
king_kilr posted:A note about the OP, you define __str__ in your models, however when you query the db using the api it's attributes are unicode, which I believe means you are using svn, and therefore you should have defined __unicode__ instead, let me know if I'm wrong, either way: yay django, and use trunk Yes.. I screwed up.. Old habits die hard. I literally typed this up in a hurry during a 2 hour lull at work. You are correct. The SVN trunk defines it as __unicode__ I'll edit it to reflect that. genericadmin posted:I'm going to laugh if it has to do with the jazz guitarist Django. I forget his full name.
|
# ? Mar 6, 2008 01:06 |
|
Wikipedia posted:His name is pronounced [dʒɑ̃ŋgo ʀeˈnɑʀt].
|
# ? Mar 6, 2008 01:35 |
|
genericadmin posted:I'm going to laugh if it has to do with the jazz guitarist Django. I forget his full name. Already posted the Wiki link, but, yup. It's because Adrian Holovaty, one of the core dev group members and arguably the founder, really has a thing for gypsy jazz and thought it'd be a neat name vv
|
# ? Mar 6, 2008 02:19 |
|
Don't forget This week in django. An awesome weekly podcast about everything django.
|
# ? Mar 6, 2008 02:27 |
|
I was having a lot of trouble getting Django running on windows until I found this guide which sped things up. The official guide just wasn't saying how to do this installation on windows very well. I am a product of Rails and have been running through a few tutorials here. I am new to this so I'll be back with a few questions later on once I've finished exploring a little more. Impressed with some of the things it does and unimpressed with the difficulty involved in doing them. Perhaps I don't understand the purpose in Django's complexity yet but maybe some alias' are in order, those are just my first impressions. Nolgthorn fucked around with this message at 20:11 on Mar 6, 2008 |
# ? Mar 6, 2008 20:08 |
|
Is there any reason to put your template files outside of the project directory? Specs seem to encourage this, but they also mention that each app of your project is checked for a templates folder just in case. I am for some reason having trouble using generic views with app/templates folders. My project seems to be looking at app/templates/app/template.html, where the second /app shouldn't be there. OP, the admin interface is cool and all but it reminds me of scaffolding in Rails. It's nothing nearly as fascinating as Django's generic views, the automatically generated authentication and permissions system or Django's development web server never needing to be restarted. It's awesome
|
# ? Mar 7, 2008 15:42 |
|
Putting them in separate folders decouples your application from your templates a bit more. For instance, you can release a new version of your application and people who are using it just replace the application folder and the templates stay intact if they are using their own or something. Have you tried explicitly telling Django where the templates are located by adding an entry to TEMPLATE_DIRS in settings.py?
|
# ? Mar 7, 2008 15:49 |
|
Yes, I have. I was curious as to when you would want to use the app/templates folder instead of using the one referenced in settings... Also I was just bringing it up for discussion how generic views don't seem to support the app/templates folders, only the settings referenced ones. The other really cool feature about Django, does it actually go through to figure out exactly what data will be needed then gets it all at once? I don't have to explicitly tell the application ahead of time what all will be needed? I just want to check with you guys to see if that's true, it seems too good.
|
# ? Mar 7, 2008 16:02 |
|
If you mean what I think you mean then yeah, because querysets are lazy. They are only evaluated when evaluating them is absolutely necessary (see QuerySets are lazy) So if you have code:
hey mom its 420 fucked around with this message at 16:11 on Mar 7, 2008 |
# ? Mar 7, 2008 16:09 |
|
You can also use select_related() to be more efficient(for example if you have an Entry model that is fkeyed to a Category model, you can use this to get the categories with the entries, that way you won't have an extra query whenever you access the category attr on the entry).
|
# ? Mar 7, 2008 16:13 |
|
Bonus posted:So if you have In your example would Django not look ahead and see that you wanted 'all_results', therefore only have to hit the database once to get it and return the value of 'result' from that? What if you have code:
Edit: Wait, I think I'm getting it, the reason is that 'my_results' is a model object. As soon as that model is dumped into another variable then the model object needs to contain data. So, it's not as if Django looks ahead to find out what all you are going to be using entirely before hitting the DB. Nolgthorn fucked around with this message at 16:58 on Mar 7, 2008 |
# ? Mar 7, 2008 16:50 |
|
The deal with the per-app template loader is that it throws all the templates into one big namespace (no other way around this given that every request for a template is a single string, e.g. 'index.html' or 'appname/index.html') so if you have two different apps, both with an 'index.html', it'll only pick up the first one it sees. So this basically forces you to 'namespace' your templates no matter which template loader you use. Also, as you saw, the generic views assume this setup by default (i.e. 'appname/templatename.html') so if you're using the per-app loader, you either need to make the extra folder, or override every generic view call with the correct template location (you can do this, by the way - you can just pass 'template_name=blah' to any generic view to override the template it uses). Hope that makes sense, typing this in a hurry
|
# ? Mar 7, 2008 16:53 |
|
Nolgthorn posted:Would the DB get hit twice, or only once? Is what I'm saying too complex for a framework to be able to do... If you derived 'result' from 'all_results[0]' instead of 'my_results[0]', then it wouldn't have to hit the DB twice. Absolutely not - how could it? That's asking the Python interpreter to start making guesses about what you're doing with your code...doesn't make any sense. Put another way, the 'my_results[0]' call comes before the other one - having that line change its behavior when you remove a line farther down the file would just be
|
# ? Mar 7, 2008 16:56 |
|
My psychic nerd head exploder beams are in full effect!
|
# ? Mar 7, 2008 17:00 |
|
Has anyone here with Django experience also used Pylons? I'd previously always written my pages as mod_python extensions and then moved on to using Pylons. Now, after I have my site all set up again using Pylons, I've heard a lot about Django being the better choice for a framework. Reading through this example, I've seen some things I like and dislike about doing things the Django way instead, but the one thing I noticed the most was that it seemed to be a lot more work to set up from scratch. So, any insight as to why Django is a better choice of framework or whether it does take more time to set up?
|
# ? Mar 7, 2008 17:14 |
|
This post makes me want to learn Django... anyone know of a good cheap webhost that supports using it? edit: oh, this place looks solid http://www.webfaction.com/services/hosting anyone have experience? ashgromnies fucked around with this message at 20:22 on Mar 7, 2008 |
# ? Mar 7, 2008 19:13 |
|
ashgromnies posted:This post makes me want to learn Django... anyone know of a good cheap webhost that supports using it? I know MediaTemple has a beta up - http://www.mediatemple.net/labs/grid/gc-django-beta.htm The Django website has a decent list as well - http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
|
# ? Mar 7, 2008 19:20 |
|
ashgromnies posted:This post makes me want to learn Django... anyone know of a good cheap webhost that supports using it? If it is just for learning purposes then I always vote for a local virtual machine. Install VMware Server (free) and slap your favorite *nix OS (free) and set it up. If you already know what you are doing then it's a breeze, if you don't then it will give you good knowledge of how a web server works that will be valuable later on. The ability to take snapshots of your system and roll it back if you royally screw something up is also really nice.
|
# ? Mar 7, 2008 19:26 |
|
ashgromnies posted:This post makes me want to learn Django... anyone know of a good cheap webhost that supports using it? It works on Dreamhost, but a lot of goons hate dreamhost. And it's also not super-easy to get working on Dreamhost either. But I've got my little ToME monster search app hosted on there and it runs just fine for the low volume it has to handle.
|
# ? Mar 7, 2008 20:15 |
|
SmirkingJack posted:If it is just for learning purposes then I always vote for a local virtual machine. Install VMware Server (free) and slap your favorite *nix OS (free) and set it up. If you already know what you are doing then it's a breeze, if you don't then it will give you good knowledge of how a web server works that will be valuable later on. The ability to take snapshots of your system and roll it back if you royally screw something up is also really nice. Nah, I want to write my personal site to run on a Django backend so other people can view it... http://www.webfaction.com/services/hosting looks like they have what I want, but I don't know if I could set up some sort of version control system on there. edit: oooh One-click webdav and subversion repositories (over SSL) this is getting a little off-topic though but they look like they'd be a good Django webhost ashgromnies fucked around with this message at 20:34 on Mar 7, 2008 |
# ? Mar 7, 2008 20:29 |
|
How about going with a VPS? I hear slicehost are really good and also I think legalcondom is offering good and cheap VPS hosting for gunes.
|
# ? Mar 7, 2008 20:46 |
|
Bonus posted:How about going with a VPS? I hear slicehost are really good and also I think legalcondom is offering good and cheap VPS hosting for gunes. Slicehost costs more than I'd like to pay for, though... I can get Webfaction hosting with ssh and svn and all sorts of fun stuff for like $70 a year versus $240/yr for Slicehost... considering my site is just personal and won't have any advertising or anything on it to make money I want a cheap solution
|
# ? Mar 7, 2008 21:49 |
|
ATLbeer posted:Django Web Framework: The 'D' is silent dumbass You umbasses
|
# ? Mar 7, 2008 22:03 |
|
Although I would prefer something that didn't use the negative-space version of the logo, you can buy t-shirts and hoodies with the django logo on it here: http://django.spreadshirt.com/us/US/Shop/ If it was just the text in white I'd totally buy it
|
# ? Mar 7, 2008 22:49 |
|
No Safe Word posted:If it was just the text in white I'd totally buy it I'm going to be at PyCon next week. If I run into any of the Django guys I'll mention it because I want a shirt that looks decent too.
|
# ? Mar 7, 2008 23:25 |
|
ATLbeer posted:I'm going to be at PyCon next week. If I run into any of the Django guys I'll mention it because I want a shirt that looks decent too. See you there! Are you sprinting?
|
# ? Mar 7, 2008 23:34 |
|
king_kilr posted:See you there! Are you sprinting? No.. I'm doing SXSW the first part of the week so I can't take a full 2 weeks off work. Although if anyone has a sprint that is just sickly amazing and I have to, I can probably get permission to stay in the frigid north for a bit more but, it's very unlikely.
|
# ? Mar 7, 2008 23:36 |
|
csammis posted:You umbasses I am using this famework for a project now, and all this time I have been pronouncing it with a D. Duh-Jango However this framework blows everything out of the water in terms of making a content based website. I just wish the template language was a little looser and allowed recursion. Habnabit posted:Has anyone here with Django experience also used Pylons? I'd previously always written my pages as mod_python extensions and then moved on to using Pylons. Now, after I have my site all set up again using Pylons, I've heard a lot about Django being the better choice for a framework. Reading through this example, I've seen some things I like and dislike about doing things the Django way instead, but the one thing I noticed the most was that it seemed to be a lot more work to set up from scratch. I also looked at pylons. Pylons stuff is a bit more modular, while django has a tendency to slowly bleed together in the deployment stages. However for the minor inconvenience you get a actively developed framework, some of the best documentation on a project I have ever seen for free, and the amazing admin interface (thats surprisingly easy to extend). Pylons seems to want to be more like Ruby on Rails, and more for making webapps, as well as being a framework you kind of pick and choose different parts of to piece together your own framework. FUN DEBUGGING TIP: if you throw a print statement into your pages, and you are running the webserver using the manage.py runserver, it will print out to that window what ever you printed. qwertyasdf fucked around with this message at 00:29 on Mar 8, 2008 |
# ? Mar 8, 2008 00:10 |
|
ATLbeer posted:I'm going to be at PyCon next week. If I run into any of the Django guys I'll mention it because I want a shirt that looks decent too. Nice, I think there's going to be more than a few of us there.
|
# ? Mar 8, 2008 00:39 |
|
|
# ? Mar 28, 2024 19:58 |
|
Addict posted:I just wish the template language was a little looser and allowed recursion. It does support recursion, just not straight out of the box. I'm doing it on one of my personal apps and I am reasonably sure I or someone with a similar approach has an item up on djangosnippets.org (which is down right now or I'd try to find it for you). My approach is not well abstracted nor will it gracefully fail if you get it into an infinite recursion scenarion, but is still pretty simple - it simply renders the template given to it, re-binds a single object in the sub-template's context dict, and returns the output. It's the first templatetag in this file and is used on todo item objects (hence the re-setting of 'item' in the new template's context). Needs a 'kickoff' template which calls it the first time, then a 'sub' template which calls it the 2nd through the Nth times, at least in my usage, although I can't think of any obvious reason why they couldn't be the same one (but it has been a while since I whipped that up so I could be wrong). Also, a big to you lucky bastards going to PyCon, I'd love to go (and should go, since we have a Django book coming out soonish which I should be trying to hype) but don't have enough vacation days due to using some of this year's, last year (for my honeymoon though, so it was worth it).
|
# ? Mar 8, 2008 01:07 |