django question

[Igor Korot]

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?
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.

[Joel Goldstick]

On Sat, Jan 4, 2014 at 6:30 PM, Igor Korot <ikor...@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

[Tim Chase]

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/

[Igor Korot]

Hi, Tim,

On Sat, Jan 4, 2014 at 5:37 PM, Tim Chase <pytho...@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

[Tim Chase]

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

[Roy Smith]

In article <mailman.4972.1388957...@python.org>,

Tim Chase <pytho...@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.

[Igor Korot]

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. ;-)

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[CM]

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).

[Roy Smith]

In article <f1732cf8-b829-4162...@googlegroups.com>,

CM <cmpy...@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.

[CM]

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.

[aeroju...@gmail.com]

Django is great