I Should Have Known

urls

With so many templates in a large project that all link together in creative and complicated ways it can be a pain to keep track of URLs.  Every URL is an address that can also have a number of variables associated with it.  If these need to be changed it can be very tedious to go through every file and replace the hard-coded URLs to reflect the change.  Helping with this, Django has a template feature that will look those URLs up for you and insert the relative URL, without the domain name, into your templates on render.

It’s a waste to have hard-coded URLs in your templates and if you are adhering to the DRY principle, don’t repeat yourself, you’ll not want to have the same hard-coded URL in many places in the same project.  Using the {% url %} tag you can reference a view and no matter what its URL is Django will handle it for you.

Example time:

urls.py

views.py

base.html

This application, Marketing, uses a base.html page that is extended in all sub pages.  This gives the ability to have the same menu across all pages in the app.  I also limit the links based on whether a customer has been selected or not.  Let’s focus on the url tags though.  In the menu we see there are three links; marketing home, overview, and profile.  The first url tag demonstrates the most basic use of the Django url tag.  Simply it in your href and you have a link.  Make sure to have quotations around the view you are referencing, this was an update starting with Django 1.5.

Some URLs take parameters and we will need to pass those on occasion.  This is very easy to do by putting a space after the view and then adding the parameters, in order, with spaces between them.  If you don’t want to use the default ordering of the URL you can call out the variable name in the url tag.  Changing the marketing overview link to use the named parameter it would change to {% url "marketing.views.overview" cus_id=customer.customer_number %}.  Simple enough, right?  You can even reference views used outside of the immediate app like I have done with the Profile link that moves you to the customers application.  Django will handle all of your URL needs.

Hope this clears up how to leverage this great tool from Django.  I know when I first started with Django I didn’t use this as much as I should have but I’m loving it now.

*args and **kwargs

As a recent graduate in computer science, I really probably should have known this, but today I learned.  This morning as the team and I were discussing some new methods and software to write the discussion came up about what were the *args and **kwargs we so often see in method declarations within Python.  Off to the Internet we went and found a perfect explanation from none other than StackOverflow.

Turns out *args and **kwargs are arguments given to a method.  Now, we all knew this to be true, this was not the interesting part.  The interesting thing to me was that you can put these in your method declarations if you want it to accept varying lengths of arguments rather than explicitly defined ones.  Very cool indeed.

Now, I’ve used arguments a lot in computer science especially command line arguments when writing small assignments for classes.  I knew these were passed in as *args but was unsure of what the **kwargs were.  From the StackOverflow answer they are both sets of arguments except the difference is that *args is an ordered list of values while **kwargs is a dictionary key-pair or key word arguments.  So passing in either a list or a dictionary will allow us to use these variables to allow our methods to take any number of arguments.

Probably should have known that.  Probably should have a deeper and better understanding of it.  I’m just getting started.  You learn something new everyday.

-Eric