I'm coming from an iOS background to Django. As an app developer, I'm used to clearly defined MVC architecture. My storyboard contains my views. My view controllers contain my logic, and my model exists in an object-relational mapper (ORM) framework or database.
On the web, the separation of responsibility seems less clear cut. Sure, databases and ORMs exists. HTML seems to be my views. Django Models seem to be just that. But where is the controller?
Where does my business logic live?
As the Django FAQ itself points out, Django doesn't quite follow an MVC approach, at least not in a straightforward way. (They argue that Django itself is the controller, but that's not really how I think about MVC.)
The "controllers" in Django are basically what Django calls views. So you have your model classes, which are the M obviously. The templates/HTML are basically the V in MVC. Django views (either functions or classes) are effectively callbacks that run for a particular URL, and they tend to be where a lot of the logic is. So for example, you'll have a Django view called get_foo_bar that runs when someone makes a GET request to /foo/bar, and the Django view effectively becomes the C in MVC.
So long story short, your logic often goes in your Django views.
Django has controllers that are stored in views.py files, this naming leads to some confusion for newbies with some sort of MVC background, you can read about it here: https://docs.djangoproject.com/en/1.8/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names
Related
I've been working with web2py during the last time, but for my new web application I want to experiment with Django. However, I've found that trivial CRUD forms require a lot of boilerplate. I understand that generic views give me all the logic for input to or output from a model, but I still have to do heavy HTML work and add my own logic to support filters, ordering, pagination, etc.
For example, in web2py I can just use the following code (consider it as the function-based view in Django's world) to get a feature-rich and highly-customizable CRUD view.
def manage_users():
grid = SQLFORM.grid(db.users)
return {"grid": grid}
Is there any de-facto way (apart from the admin application) or library you Django folks use to reduce the boilterplate of writing ~200 lines of code to achieve the same thing that web2py gives you for free?
Note: this is not a web2py vs. Django question. I understand they propose different philosophies and that Django is much more flexible than web2py, while web2py gives you more features out of the box. I'm just asking how is this resolved in the Django world.
Thanks in advance guys!
Every Django tutorial/book I've seen approaches Django projects from what I am going to characterize as an ad-hoc database design method. A project ends-up being a bunch of little apps, each with it's own models, view, etc.
I am trying to locate a resource that covers how to structure a Django project when you do, in fact, start with a traditional DB design process.
For example, let's say that this is the starting point:
And a document describing it:
LEAD Database Guide
How does one approach this so that the various Django apps access a single "global" (bad word) db model that covers the entire schema rather than a bunch of models spread across a bunch of apps?
Are there any resources (books, pdf's, tutorials) that cover this approach rather than the piece-meal approach most commonly seen?
A corollary to this question might be: Is there a, perhaps automated, way to go from an SQL (or MySQL Workbench) schema definition to the equivalent Django ORM?
You can use the inspectdb command to generate models.py from database:
http://docs.djangoproject.com/en/dev/ref/django-admin/#inspectdb
Then, you can treat the models as a single app, and add more features/tables into new apps in the future.
In django, https://docs.djangoproject.com/en/dev/topics/db/queries/#lookups-that-span-relationships, span relationships provide an easy way in django to do a JOIN. Is there a way in the template to do this (using template tags)?
You could do that, I think, because when you write a custom template tag you can import models and run queries on them just as you can anywhere else. But it violates the separation of business logic and presentation that Django's model-view-controller (or model-view-template) design works hard to preserve. Why not do your query in a view and pass the results to a template via the template's context?
If you are asking whether Django comes with a pre-built way to do this, the answer is no. The people who created Django want you to run queries in your views.
Has anyone implemented their own AdminSite? How easy/hard was the basic implementation?
I'm in the midst of building a "cms" that's going to be quite large and decently complex in some areas and I'm wondering if using something like AdminSite would save some time. I'd rather not have to make my own implementation for admin actions and inlines and the like (I know I can just use inline forms but that's not as simple as inlines = [Foo]).
When using a custom AdminSite, is further customization equivalent to customizing the standard Django admin?
You've read the admin site docs. It's a lengthy document, but two main hooks for adding custom functionality is through custom urls and modified standard views in your own AdminSite and ModelAdmin objects. Once you hook those in and the urls get mapped, it's just like building any other Django application, only that the templates aren't yours, so they're are a bit hard to manage and take getting used to. But it allows you to do additional gymnastics, like adding a form wizard to the admin site or splitting everything into multiple forms and rendering them in a single HTML form element in the templates, doing custom handling of GET/POST requests, etc.
I've used it in the past to create views for displaying custom reports and to create custom editing scenarios for the staff. My opinion is that you should KISS as much as possible. The admin site is all about generic views and generic presentation. Do expand, but be cautious if you override template blocks and think twice before you override something that's not wrapped in a block. Certain admin site features have certain presentation assumptions and the JS client app that's shipped with Django makes some too (that's what I've figured when working with adding dynamic inline models way back), so it'd be quite an undertaking if you'd like to roll a completely different presentation.
The answer in any case is YES! The admin site will provide you with more features for managing your model data interactively. I don't know how extensively you'd need to customize the admin, but there are CMSs, dedicated admin apps and admin integrated apps that are a real eye-opener. Django CMS, as I recalled, has been praised as the best open-source Django CMS out there and from what I can see it rolls it's own cust change/list views. Rosetta is an admin site only app that allows you to edit your translation files interactively and has an exhaustive admin interface! If you shop around on bitbucket and github you'll find many more examples, it should help you figure out best how much effort you'd need to put into it.
Both
If you are OK with it not doing exactly what you want its pretty much done for you automatically. If you need fine grain control over certain things it can be hard to customize without knowing the internals of the admin code.
the django admin is more of a one size fits all kind of ui which may not be intuitive for use in some cases ..
customizing its look is easy but extending it is some how hard. you are better off designing your own views in that case.
Pretty new to this scene and trying to find some documentation to adopt best practices. We're building a fairly large content site which will consist of various media catalogs and I'm trying to find some comparable data / architectural models so that we can get a better idea of the approach we should use using a framework we've never made use of before. Any insight / help would be greatly appreciated!
"data / architectural models so that we can get a better idea of the approach we should use using a framework we've never made use of before"
Django imposes best practices on you. You don't have a lot of choices and can't make a lot of mistakes.
MVC (while a noble aspiration) is implemented as follows:
Data is defined in "models.py" files using the Django ORM models.
urls.py file maps URL to view function. Pick your URL's wisely.
View function does all processing, making use of models and methods in models
Presentation (via HTML templates) invoked by View function. Essentially no processing can be done in presentation, just lightweight iteration and decision-making
The model is defined for you. Just stick to what Django does naturally and you'll be happy.
Architecturally, you usually have a stack like this.
Apache does two things.
serves static content directly and immediately
hands dynamic URL to Django (via mod_python, mod_wsgi or mod_fastcgi). Django apps map URL to view functions (which access to database (via ORM/model) and display via templates.
Database used by Django view functions.
The architecture is well-defined for you. Just stick to what Django does naturally and you'll be happy.
Feel free to read the Django documentation. It's excellent; perhaps the best there is.
first, forget all MVC mantra. it's important to have a good layered structure, but MVC (as defined originally) isn't one, it was a modular structure, where each GUI module is split in these tree submodules. nothing to use on the web here.
in web development, it really pays to have a layered structure, where the most important layer is the storage/modelling one, which came to be called model layer. on top of that, you need a few other layers but they're really not anything like views and controllers in the GUI world.
the Django layers are roughly:
storage/modelling: models.py, obviously. try to put most of the 'working' concepts there. all the relationships, all the operations should be implemented here.
dispatching: mostly in urls.py. here you turn your URL scheme into code paths. think of it like a big switch() statement. try hard to have readable URLs, which map into user intentions. it will help a lot to add new functionality, or new ways to do the same things (like an AJAX UI later).
gathering: mostly the view functions, both yours and the prebuilt generic views. here you simply gather all the from the models to satisfy a user request. in surprisingly many cases, it just have to pick a single model instance, and everything else can be retrieved from relationships. for these URLs, a generic view is enough.
presentation: the templates. if the view gives you the data you need, it's simple enough to turn it into a webpage. it's here where you'll thank that the model classes have good accessors to get any kind of relevant data from any given instance.
To understand django fundementals and the django take on MVC, consult the following:
http://www.djangobook.com/
As a starting point to getting your hands dirty with ...
"...trying to find some comparable data / architectural models"
Here is a quick and dirty way to reverse engineer a database to get a models.py file,
which you can then inspect to see how django would handle it.
1.) get an er diagram that closely matches your target. For example something like this
http://www.databaseanswers.org/data_models/product_catalogs/index.htm
2.) create an sql script from the er diagram and create the database,
I suggest Postgre, as some MySQL
table type will not have forgien key constraints, but in a pinch MySQL or SQLITE
will do
3.) create and configure a django app to use that database. Then run:
python manage.py inspectdb
This will at least give you a models.py file which you can read to see how django attempts
to model it.
Note that the inspect command is intended to be a shortcut for dealing with legacy
database when developing in django, and as such is not perfect. Be sure to read the
following before attempting this:
http://docs.djangoproject.com/en/dev/ref/django-admin/#ref-django-admin