Re: django question
On Monday, January 6, 2014 8:57:22 PM UTC-5, Roy Smith wrote: 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: Nice! 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. Thanks for these points, helpful to see in practice. I'm trying to be more mindful of good coding practices, and this will be helpful as I continue to learn Django and making web applications generally. -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
Django is great On Tuesday, January 7, 2014 12:55:07 AM UTC-7, CM wrote: On Monday, January 6, 2014 8:57:22 PM UTC-5, Roy Smith wrote: 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: Nice! 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. Thanks for these points, helpful to see in practice. I'm trying to be more mindful of good coding practices, and this will be helpful as I continue to learn Django and making web applications generally. -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
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? Do you just keep a modules folder in the Django project folder I guess? Thanks for the tip(s). That's not to say it will be *easy*, but you can certainly make things harder on yourself than they need to be if you don't keep things distinct. Oh, and yes, the django team does a really amazing job on the docs. -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
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
Re: django question
Hi, Tim, On Sat, Jan 4, 2014 at 5:37 PM, Tim Chase python.l...@tim.thechases.com wrote: On 2014-01-04 15:30, Igor Korot wrote: Does anybody here use django? Yes. However there's also a Django-users mailing list[1] for Django-specific questions. Folks there are friendly helpful. Thank you for that. I didn't look too close on the django web site. ;-) Is it possible to display a data grid table with django? The short answer is yes. Basically I am looking for displaying a data from the db table on the web interface thru django or some other web interface. While I prefer Django for larger projects, for a lighter-weight project such as what you describe, I'd be tempted to go with something a little more light-weight unless you need additional interactivity. I've recently been impressed with Bottle[2] for a small clean web framework. CherryPy comes somewhere in the middle, but I can't say it met my needs/wants on the last project where it was chosen (mostly in the documentation department, but it's hard to beat Django's stellar docs). And thank you for those points as well. This piece will be for the proof of concept, which later on will go to much bigger application with reporting, plotting and different types of data presentation. Now would it be easy to switch from either on of them to django? Or is there a better choice for the main application? Thank you. -tkc [1] http://groups.google.com/group/django-users [2] http://bottlepy.org/ -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
On 2014-01-05 00:24, Igor Korot wrote: While I prefer Django for larger projects, for a lighter-weight project such as what you describe, I'd be tempted to go with something a little more light-weight unless you need additional interactivity. I've recently been impressed with Bottle[2] for a small clean web framework. CherryPy comes somewhere in the middle, but I can't say it met my needs/wants on the last project where it was chosen (mostly in the documentation department, but it's hard to beat Django's stellar docs). And thank you for those points as well. This piece will be for the proof of concept, which later on will go to much bigger application with reporting, plotting and different types of data presentation. Now would it be easy to switch from either on of them to django? Or is there a better choice for the main application? Integration is one of the things that Django does particularly well: out of the box, you get a web framework, database abstraction (ORM), templating, out-of-the-box functionality, and PHENOMENAL documentation. The others just bring the web-framework to the table and *you* then have to choose your templating engine (and ORM if you're using one). Some people see this as an advantage, some see it as a disadvantage. If you like a particular templating engine (Mako, Jinja, etc) or ORM (SQLAlchemy, SQLObject, etc), you /can/ use them in Django or other frameworks, but in Django, you'd be fighting the Django Way™ and don't get to take advantage of some of the tight integration in areas where it does some of the hard work for you (such as integration into the admin interface). I haven't found it to be that easy to directly transition projects between Django and other frameworks. Jumping from Bottle to CherryPy might be easier, as the non-framework parts (templating, ORM) would/should mostly stay the same. Depending on the scope of your work, it might be possible to just use something light-weight like Bottle to get a demo up and running, then scrap it and start mostly-from-scratch on a Django project once you've impressed folks with a proof-of-concept. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
In article mailman.4972.1388957900.18130.python-l...@python.org, Tim Chase python.l...@tim.thechases.com wrote: Integration is one of the things that Django does particularly well: out of the box, you get a web framework, database abstraction (ORM), templating, out-of-the-box functionality, and PHENOMENAL documentation. The others just bring the web-framework to the table and *you* then have to choose your templating engine (and ORM if you're using one). Some people see this as an advantage, some see it as a disadvantage. If you like a particular templating engine (Mako, Jinja, etc) or ORM (SQLAlchemy, SQLObject, etc), you /can/ use them in Django or other frameworks, but in Django, you'd be fighting the Django Way⢠and don't get to take advantage of some of the tight integration in areas where it does some of the hard work for you (such as integration into the admin interface). On the other hand, it's all modular enough that it's quite reasonable to plug in your own components. For example, at Songza, we don't use the django ORM at all (we use mongoengine). We also have a number of django-based services which don't use templates at all (we return JSON objects). Neither of these required any major surgery to do this. In fact, for a lot of what we do, all we really get from django is the request parsing, URL routing, middleware scaffolding, and cache interface. But, that's enough to be worthwhile. I haven't found it to be that easy to directly transition projects between Django and other frameworks. 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. That's not to say it will be *easy*, but you can certainly make things harder on yourself than they need to be if you don't keep things distinct. Oh, and yes, the django team does a really amazing job on the docs. -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
Hi, ALL, Well, my employer does not know anything about web programming and I don't know anything about web programming and this is my first job with python. So since django is a well documented framework I guess it will be easier to go with a well documented framework. Thank you everybody for such a good input. Happy New Year and happy coding in this year as well. ;-) On Sun, Jan 5, 2014 at 1:50 PM, Roy Smith r...@panix.com wrote: In article mailman.4972.1388957900.18130.python-l...@python.org, Tim Chase python.l...@tim.thechases.com wrote: Integration is one of the things that Django does particularly well: out of the box, you get a web framework, database abstraction (ORM), templating, out-of-the-box functionality, and PHENOMENAL documentation. The others just bring the web-framework to the table and *you* then have to choose your templating engine (and ORM if you're using one). Some people see this as an advantage, some see it as a disadvantage. If you like a particular templating engine (Mako, Jinja, etc) or ORM (SQLAlchemy, SQLObject, etc), you /can/ use them in Django or other frameworks, but in Django, you'd be fighting the Django Way™ and don't get to take advantage of some of the tight integration in areas where it does some of the hard work for you (such as integration into the admin interface). On the other hand, it's all modular enough that it's quite reasonable to plug in your own components. For example, at Songza, we don't use the django ORM at all (we use mongoengine). We also have a number of django-based services which don't use templates at all (we return JSON objects). Neither of these required any major surgery to do this. In fact, for a lot of what we do, all we really get from django is the request parsing, URL routing, middleware scaffolding, and cache interface. But, that's enough to be worthwhile. I haven't found it to be that easy to directly transition projects between Django and other frameworks. 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. That's not to say it will be *easy*, but you can certainly make things harder on yourself than they need to be if you don't keep things distinct. Oh, and yes, the django team does a really amazing job on the docs. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
On Sat, Jan 4, 2014 at 6:30 PM, Igor Korot ikoro...@gmail.com wrote: Hi, ALL, Does anybody here use django? I have a very basic question about it. Is it possible to display a data grid table with django? Yes, using the django template language. If you learn django (perhaps 2 days of exploring), you would have the skills to do this. Check out the django tutorial Basically I am looking for displaying a data from the db table on the web interface thru django or some other web interface. My main application is in Python, that's why I'd like to explore Python possibilities first. Thank you. -- https://mail.python.org/mailman/listinfo/python-list -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list
Re: django question
On 2014-01-04 15:30, Igor Korot wrote: Does anybody here use django? Yes. However there's also a Django-users mailing list[1] for Django-specific questions. Folks there are friendly helpful. Is it possible to display a data grid table with django? The short answer is yes. Basically I am looking for displaying a data from the db table on the web interface thru django or some other web interface. While I prefer Django for larger projects, for a lighter-weight project such as what you describe, I'd be tempted to go with something a little more light-weight unless you need additional interactivity. I've recently been impressed with Bottle[2] for a small clean web framework. CherryPy comes somewhere in the middle, but I can't say it met my needs/wants on the last project where it was chosen (mostly in the documentation department, but it's hard to beat Django's stellar docs). -tkc [1] http://groups.google.com/group/django-users [2] http://bottlepy.org/ -- https://mail.python.org/mailman/listinfo/python-list
