Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eighteen months of Django

dangoldin.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Eighteen months of Django

#61

Post by aidos »

porker wrote: post #51
aidos wrote: post #15

Earlier quoted context omitted.

Neither! Actually, as the others have said it completely depends on what you're making. Django is great if you're making a standard cms type website. News feed, blog, etc. There's a bit of a learning curve but it gives you a lot of the scaffolding out of the box (and there are loads of examples to learn from). It has the biggest community (I guess?) so you'll always be able to find answers / libraries / sample code.…

> In terms of the admin I think that the days of writing admin grid and edit screens that post back and forth to the server are numbered (I use REST and Angular now) - so that's not a bit of Django I use either. My feeling too. Are there any projects which are starting to create the boilerplate for this? I'm new to Angular, so looking for where to get started...

Not that I've seen - I'm building a specific admin interface for one of my projects at the moment using this style (but I'm not making it generic). Architecturally the REST api is on one domain, the admin system is static angular on another domain and the front of the site (/sites - 15,000 of them) is a thin layer that makes calls back to the api.

It should be possible to build a completely generic frontend that just has a grid view and an edit view that you could wire to any REST backend. Then you could use flask-restful or Django Rest Framework or whatever else you wanted.

If you were going to go that route there's an angular directive for doing grids that would get you half way there: http://angular-ui.github.io/ng-grid/#/examples

Were I still building CMSs that's the approach I would be looking into.

Re: Eighteen months of Django

#62

Post by porker »

scott_w wrote: post #56
porker wrote: post #52

How well does Django handle complex forms? The kind where "if x = y show fields p-r (and make them required), if x = z jump the next screen)? I've just implemented one of these in PHP using the 'old' Symfony 1.4 and it was painful . I ended up hardcoding most of the frontend, and writing ridiculous modifications for "add another row" and validation. Is Django any better at that? Complex forms have been my pain point…

If I'm understanding you correctly, you want to have the fields on the form depend on the contents of what was entered on the previous form e.g. if user selects name, ask for name, otherwise ask for address. In that case, I tend to use class-based views and set different forms, templates etc. depending on those values. If the form is different enough, it's easier just to send them to a completely different URL.

Not quite - that happens sometimes and I use logic in the controller (ugh) to switch the form class.

This is what I mean: an adaptive form http://screencast.com/t/SutggDU5

The server-side validation has to adapt depending on the data coming from the client-side, and varies a lot.

Perhaps others don't build forms like this much and so web frameworks don't deal with them; I get one like this every few months!

Re: Eighteen months of Django

#63

Post by porker »

vially wrote: post #58
porker wrote: post #52

How well does Django handle complex forms? The kind where "if x = y show fields p-r (and make them required), if x = z jump the next screen)? I've just implemented one of these in PHP using the 'old' Symfony 1.4 and it was painful . I ended up hardcoding most of the frontend, and writing ridiculous modifications for "add another row" and validation. Is Django any better at that? Complex forms have been my pain point…

I've recently (2-3 months) switched to Python/Django and my experience so far has been very positive. Multi-step forms can be implemented in Django using Form wizards [1]. In order to optionally show fields or make them required I think you could build it easily using the WizardView.get_form method [2]. The functionality to skip steps is built-in and it's very easy implement using conditional views [3]. In conclusion…

Interesting, thanks for sharing your experience!

Have you seen anything saying it helps to build adaptive forms like [1]?

[1] - http://screencast.com/t/SutggDU5

Re: Eighteen months of Django

#64

Post by lucian1900 »

aidos wrote: post #15
tesmar2 wrote: post #2

As someone who is thinking about doing a python project, should I learn Django or just go with Flask? Any thoughts on those two?

Neither! Actually, as the others have said it completely depends on what you're making. Django is great if you're making a standard cms type website. News feed, blog, etc. There's a bit of a learning curve but it gives you a lot of the scaffolding out of the box (and there are loads of examples to learn from). It has the biggest community (I guess?) so you'll always be able to find answers / libraries / sample code.…

To be fair to Flask, there are lots of libraries you can add to it (Flask-Script, Flask-WTF, Flask-Auth, Flask-Admin) that replicate pretty much all of the functionality of Django, but in a more modular fashion. For example, I can use Flask-Auth regardless of if I've chosen Flask-SQLAlchemy.

Re: Eighteen months of Django

#65

Post by antihero »

scott_w wrote: post #59

For dealing with packages such as python-psycopg2 and python-mysql, your best bet is to use --system-site-packages. This allows the virtualenv to depend on packages provided by your distro instead of trying to compile its own. Wherever possible, I try to do this with Python packages that require a C compiler to make deployment a little easier and reduce dependencies. Personally, I'm not a fan of Fabric and I much pre…

Absolutely not. An added bit of compile time is the least of your worries and if you really don't want to compile stuff on production, look at packaging your virtualenv as a compiled deb/rpm.

Never ever ever mix/depend upon system packages in your virtualenv. Ever.

Re: Eighteen months of Django

#66

Post by scott_w »

porker wrote: post #62
scott_w wrote: post #56

Earlier quoted context omitted.

If I'm understanding you correctly, you want to have the fields on the form depend on the contents of what was entered on the previous form e.g. if user selects name, ask for name, otherwise ask for address. In that case, I tend to use class-based views and set different forms, templates etc. depending on those values. If the form is different enough, it's easier just to send them to a completely different URL.

Not quite - that happens sometimes and I use logic in the controller (ugh) to switch the form class. This is what I mean: an adaptive form http://screencast.com/t/SutggDU5 The server-side validation has to adapt depending on the data coming from the client-side, and varies a lot. Perhaps others don't build forms like this much and so web frameworks don't deal with them; I get one like this every few months!

Ah, I see now. For certain cases e.g. repeating the same form over and over, you can use formsets, but that doesn't work when you have two different forms.

I still think a solution is to use multiple forms and form types rather than one big form. Perhaps you can prefix the field names on the template and use that to determine which form they go to inside the view. It makes your logic a little simpler in any case.

Re: Eighteen months of Django

#67

Post by scott_w »

antihero wrote: post #65
scott_w wrote: post #59

For dealing with packages such as python-psycopg2 and python-mysql, your best bet is to use --system-site-packages. This allows the virtualenv to depend on packages provided by your distro instead of trying to compile its own. Wherever possible, I try to do this with Python packages that require a C compiler to make deployment a little easier and reduce dependencies. Personally, I'm not a fan of Fabric and I much pre…

Absolutely not. An added bit of compile time is the least of your worries and if you really don't want to compile stuff on production, look at packaging your virtualenv as a compiled deb/rpm. Never ever ever mix/depend upon system packages in your virtualenv. Ever.

You're always depending on system packages somewhere. Compiling isn't the only reason - sometimes it's necessary just to make the damn thing work.

Some examples:

* PIL - Using Pip's version on Ubuntu, you have to hack your directory structure and re-compile the whole thing or PIL doesn't compile in support for your image libraries.

* psycopg2 - This is hit and miss (OS X comes to mind), but depending on the system version guarantees that it has been tested to work with the specific version of Postgres on your system.

* Crypto libraries - Broken packages have ended up on Pip and just cause a bloody headache. The system package is, again, tested and works.

Compiling a DEB/RPM would be a good idea, but it's not a well supported system at all. If there were a simple pip compile --type=deb or something, we would be all over it.

Re: Eighteen months of Django

#68

Post by vially »

porker wrote: post #63
vially wrote: post #58

Earlier quoted context omitted.

I've recently (2-3 months) switched to Python/Django and my experience so far has been very positive. Multi-step forms can be implemented in Django using Form wizards [1]. In order to optionally show fields or make them required I think you could build it easily using the WizardView.get_form method [2]. The functionality to skip steps is built-in and it's very easy implement using conditional views [3]. In conclusion…

Interesting, thanks for sharing your experience! Have you seen anything saying it helps to build adaptive forms like [1]? [1] - http://screencast.com/t/SutggDU5

I'm not aware of any library which could help you build these kind of adaptive forms automatically.

However, the way I would go about building something like that is by using the form wizard (mentioned in my previous comment) with a combination of forms/modelforms [1] and formsets [2]. Formsets are used in situations when you need to display the same form multiple times on the same page (like the multiple addresses/benefits income in your example). However, you would have to implement all the client side interaction yourself since Django does not provide this by default (there are some libraries which are supposed to help with this but I haven't tried them myself [3]).

One thing worth mentioning is that by default, the form wizard only allows you to display either a Form, or a Formset in a step/page. However, there is a ticket open for this [4] which links to a helper class: form_container.py [5] which helps overcome this problem. Hopefully, this will be included in future versions of Django.

Hope this helps.

[1] - https://docs.djangoproject.com/en/dev/topics/forms/modelform... [2] - https://docs.djangoproject.com/en/dev/topics/forms/formsets/ [3] - https://code.google.com/p/django-dynamic-formset/ [4] - https://code.djangoproject.com/ticket/18830 [5] - https://code.djangoproject.com/attachment/ticket/18830/form_...

Re: Eighteen months of Django

#69

Post by masklinn »

scott_w wrote: post #66
porker wrote: post #62

Earlier quoted context omitted.

Not quite - that happens sometimes and I use logic in the controller (ugh) to switch the form class. This is what I mean: an adaptive form http://screencast.com/t/SutggDU5 The server-side validation has to adapt depending on the data coming from the client-side, and varies a lot. Perhaps others don't build forms like this much and so web frameworks don't deal with them; I get one like this every few months!

Ah, I see now. For certain cases e.g. repeating the same form over and over, you can use formsets, but that doesn't work when you have two different forms. I still think a solution is to use multiple forms and form types rather than one big form. Perhaps you can prefix the field names on the template and use that to determine which form they go to inside the view. It makes your logic a little simpler in any case.

Note that one thing you can do is build smaller forms and mix them up. There's no issue with mixing up 3 or 4 smaller (django) forms in the same (HTML) form, quite the opposite.

Re: Eighteen months of Django

#70

Post by jordn »

For those who would like to get started with Django, here's a skeleton project https://github.com/jordn/heroku-django-s3 and guide helps get you set up quickly with:

  - hosting on heroku
  - static files on Amazon S3
  - virtualenv(wrapper) isolated packages
  - environment and security critical variables removed from settings.py and stored as environment variables (following the 12-factor design ethic)
Post reply on HN