django question

Igor Korot ikorot01 at gmail.com
Sun Jan 5 19:06:59 EST 2014


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



More information about the Python-list mailing list