Reworking the URL Structure

I like to learn by mistakes, as I think that is the most efficient way. Obviously, learning from the mistakes of other people is even better. So I deliberately introduced something that is not really a mistake but could be called a flaw in the design, and left it up to this point in the chapter.

If you've been carefully following all the code examples, you must have noticed one thing: that, although functionally our code is perfect, it just does not feel right. Guessed it yet? Go on, take a second look at all the examples of templates and view functions. What is quite common that you notice there?

Yes! We've been using relative URLs in both the templates and the view functions. It was quite a simple trick to do, and it works perfectly well most of the time, especially in small projects. It even works with decoupled applications, because when you use relative paths address resolution works from the other end, so effectively it doesn't matter at what depth your application URLs start.

The trouble is, with so many class models and functions, it becomes quite difficult to memories the structure of your URLs for each model. We've set very strict rules about formatting the URLs (remember, it's always <model>/<object>/<method>), and with a limited number of methods (so far it's only add, delete, modify, and implicit display'), we were coping quite easily. However, with a growing number of models and URLs it becomes more difficult to manage and maintain all URLs. Why would you ever need to change the URL structure? There are many reasons—restructuring the site, adding new applications into the hierarchy, or simply fixing a mistake in the development process.

While we're talking about changing URL structure, I need to mention now that I let another "bug" creep in. Remember talking about the <model>/<object>/<method> URL structure? Again, I violated it a bit by always using networkaddress/ at the beginning when referencing DHCP network and DHCP Pool models. What I should have done is used dhcpnetwork and dhcpaddresspool prefixes, respectively.

Now that we have a really valid reason for reworking or fixing the code, how should we approach it? It would be ideal if there were a facility or functionality that allowed you to obtain a URL for any object you want to link to.

Was this article helpful?

0 0

Post a comment