In article <f1732cf8-b829-4162-99e5-91e0d82cc...@googlegroups.com>, CM <cmpyt...@gmail.com> wrote:
> On Sunday, January 5, 2014 4:50:55 PM UTC-5, Roy Smith wrote: > > > One of the things we try to do is put as little in the views as > > possible. Views should be all about accepting and validating request > > parameters, and generating output (be that HTML via templates, or JSON, > > or whatever). All the business logic should be kept isolated from the > > views. The better (and more disciplined) you are about doing this, the > > easier it will be to move your business logic to a different framework. > > I just started playing with Django and hadn't realized that yet. So, > what, you have other modules that you import into Views that you call > functions from to do the business logic? Yes, exactly. There's nothing magic about a django view. It's just a function which is passed an instance of HttpRequest (and possibly a few other things, depending on your url mapping), and which is expected to return an instance of HttpResponse. Within that framework, it can call any other functions it wants. For example, http://legalipsum.com/ is a silly little site I built in django. Here's the view for the home page: from markov import markov files = markov.corpus_files() chainer = markov.from_files(files) @require_GET def home(request): count = request.GET.get('count', 0) try: count = int(count) except ValueError: count = 0 paragraphs = [chainer.paragraph(3, 3) for i in range(count)] ctx = { 'paragraphs': paragraphs, 'selected': str(count), 'pagename': 'home', } return render(request, 'legal_ipsum/home.html', ctx) Notice how the view knows nothing about generating the actual markov text. That's in another module, which lives somewhere on my PYTHONPATH. ALso, the view knows nothing about how the page is laid out; only the templates know that. If I decided to redo this in tornado or flask, whatever, I would need to rewrite my view, but there's not much to rewrite. Most of the logic is in the Markov chainer, and that would cary over to the new implementation unchanged. BTW, my suggestion to keep business logic and presentation code distinct isn't unique to django, it's a good idea in pretty much all systems. -- https://mail.python.org/mailman/listinfo/python-list
