Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #63227 > unrolled thread

Re: django question

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: django question Tim Chase <python.list@tim.thechases.com> - 2014-01-05 15:39 -0600
    Re: django question Roy Smith <roy@panix.com> - 2014-01-05 16:50 -0500
      Re: django question Igor Korot <ikorot01@gmail.com> - 2014-01-05 16:06 -0800
      Re: django question CM <cmpython@gmail.com> - 2014-01-06 16:48 -0800
        Re: django question Roy Smith <roy@panix.com> - 2014-01-06 20:57 -0500
          Re: django question CM <cmpython@gmail.com> - 2014-01-06 23:55 -0800
            Re: django question aerojunkemail@gmail.com - 2014-01-07 11:53 -0800

#63227 — 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

[toc] | [next] | [standalone]

#63228

In article <mailman.4972.1388957900.18130.python-list@python.org>,
 Tim Chase <python.list@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.

[toc] | [prev] | [next] | [standalone]

#63245

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 <roy@panix.com> wrote:
> In article <mailman.4972.1388957900.18130.python-list@python.org>,
>  Tim Chase <python.list@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
>

[toc] | [prev] | [next] | [standalone]

#63386

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.

[toc] | [prev] | [next] | [standalone]

#63394

In article <f1732cf8-b829-4162-99e5-91e0d82cc0f2@googlegroups.com>,
 CM <cmpython@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.

[toc] | [prev] | [next] | [standalone]

#63414

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.

[toc] | [prev] | [next] | [standalone]

#63449

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web