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

Groups > comp.lang.python > #63245

Re: django question

Show key headers only | View raw

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
>

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web