Django - 013 - URLconfs and loose coupling

Now's a good time to highlight a key philosophy behind URLconfs and behind Django in general: the principle of loose coupling. Simply put, loose coupling is a software development approach that values the importance of making pieces interchangeable. If two pieces of code are loosely coupled, then changes made to one of the pieces will have little or no effect on the other.

Django's URLconfs are a good example of this principle in practice. In a Django web application, the URL definitions and the view functions they call are loosely coupled; that is, the decision of what the URL should be for a given function, and the implementation of the function itself, reside in two separate places.

For example, consider our current_datetime view. If we wanted to change the URL for the application - say, to move it from /time/ to /current-time/ - we could make a quick change to the URLconf, without having to worry about the view itself. Similarly, if we wanted to change the view function - altering its logic somehow - we could do that without affecting the URL to which the function is bound. Furthermore, if we wanted to expose the current-date functionality at several URLs, we could easily take care of that by editing the URLconf, without having to touch the view code.

In this example, our current_datetime is available at two URLs. It is a contrived example, but this technique can come in handy:

urlpatterns = [
                        url(r'^admin/', include(admin.site.urls)), 
                        url(r'^hello/$', hello),
                        url(r'^$',my_homepage_view),
                        url(r'^time/$',current_datetime),
                        url(r'^fileInfo/$',read_file_info),
                        url(r'^another-time-page/$',current_datetime),
]

URLconfs and views are loose coupling in action. I'll continue to point out examples of this  important philosophy throughout the book. 

Django - 008 - Regular Expressions

Regular Expressions (or regexes) are a compact way of specifying patterns in a text. While Django URLconfs allow arbitrary regexes for powerful URL matching, you will probably only use a few regex symbols in practice. Below table lists a selection of common symbols:

Symbol	Matches
. (dot)	Any single character
\d	Any single digit
[A-Z]	Any character between A and Z (uppercase)
[a-z]	Any character between a and z (lowercase)
[A-Za-z]	Any character between A and z (case insensitive)
+	One or more of the previous expression (for example, \d+ matches one or more digits)
[^/]+	One or more characters until (and not including) a forward slash
?	Zero or one of the previous expression (for example, \d? matches zero or one digits)
*	Zero or more of the previous expression (for example, \d* matches zero, one or more than one digit)
{1,3}	Between one and three (inclusive) of the previous expression (for example, \d{1,3} matches one, two or three digits)

For more on regular expressions, see the Python regex documentation, visit: https://docs.python.org/2/library/re.html

Django - 005 - The Model-View-Controller (MVC) design pattern

MVC has been around as a concept for a long time, but has seen exponential growth since the advent of the Internet because it is the best way to design client-server applications. All of the best web frameworks are built around the MVC concept. It is of popular opinion that if you are not using MVC to design web apps, you are doing it wrong. As a concept, the MVC design pattern is really simple to understand:

1. The Model (M) is a model or representation of your data. It is not the actual data, but an interface to the data. The model allows you to pull data from your database without knowing the intricacies of the underlying database. The model usually also provides an abstraction layer with your database, so that you can use the same model with multiple databases.
2. The View (V) is what you see. It is the presentation layer for your model. On your computer, the view is what you see in the browser for a web app, or the UI for a desktop app. The view also provides an interface to collect user input.
3. The Controller (C) controls the flow of information between the model and the view. It uses programmed logic to decide what information is pulled from the database via the model and what information is passed to the view. It also gets information from the user via the view and implements business logic: either by changing the view, or modifying data through the model, or both.

Where it gets difficult is the vastly different interpretations of what actually happens at each layer-different frameworks implement the same functionality in different ways. One framework guru might say a certain function belongs in a view, while another might vehemently defend the need for it to be on the controller.

We, as budding programmers - who Gets the stuff done, do not have to care about this because, in the end, it does not matter. As long as you understand how Django implements the MVC pattern, you are free to move on and get some real work done.

Django follows the MVC pattern closely, however, it does use its own logic in the implementation. Because the Controller (C) is handled by the framework itself and most of the excitement in Django happens in models, templates and views. Django is often referred to as an MTV framework. In the MTV development pattern:

M stands for Model - the data access layer. This layer contains anything and everything about the data: how to access it, how to validate it, which behavior it has and the relationships between data.
T stands for Template - the presentation layer. This layer contains presentation related decisions: how something should be displayed on a web page or other type of document.
V stands for View - the business logic layer. This layer contains the logic that accesses the model and defers to the appropriate template(s). You can think of it as the bridge between models and templates.

This is probably the only unfortunate bit of naming in Django, because Django's view is more like the controller in MVC, and MVC's view is actually a template in Django. It is little confusing at first, but as a programmer getting a job done, you really won't care for long. It is only a problem for those of us who have to teach it.