3 ms·

Can someone familiar with Grails and Django give their 2c? I've done a fair amount of work in Grails, and when I did a small project in Django I found it somew

by cujo 13y ago

Can someone familiar with Grails and Django give their 2c? I've done a fair amount of work in Grails, and when I did a small project in Django I found it somewhat more difficult to work with. With Django, the quick test runs and startup were wins (although Grails mitigates that a bit these days), but I thought Django's organization (or lack thereof) was a confusing mess and dealing with forms was an exercise in bending the API instead of working with it.

Daishiman 13y ago
The idea in Django is that you really want to break up your project into several apps, with each app having just a handful of models and views. Aside from depending on some conventions such as a models and views file for each app, apps can live anywhere, so you can separate them through subdirectories if that works for you. The forms API is, granted, not super easy to work with initially, but its abstractions are really powerful and bending them to your will is trivial, because everything is overridable.
- cujo 13y ago
  When I used it (forms), it sure seemed powerful in idea, but I ended up with a ridiculous amount of code to generate dynamic forms (different field types depending on the object instance). I will safely assume that as a beginner I was missing some part of the puzzle, but I was never able to track down a good way to do it. Oh well.
  - Daishiman 13y ago
    Well, StackOverflow helps a lot there. The important thing is that the process is standardized and fairly uniform. If you're using a lot of code to generate forms that depend on models, look into ModelForms: they allow you to generate a form that maps to a specific model's fields trivially and allow adding additional validation and persisting the model to the database.
  - mildtrepidation 13y ago
    How useful Django's forms are (and which ones to use) varies widely based on your requirements. I've had projects where the combination of the UI I had to work with and the data that was being manipulated required Form classes to be built and validated manually. Right now I'm working on a project with a fairly complex data set, but everything is falling beautifully into place with generic ModelForms created implicitly via FormViews with only minor tweaking to field visibility. It took me a while to get a solid handle on them, but Django usually does forms very well. The best case is that your UI requirements are fairly loose, otherwise it's likely you'll end up with mostly-custom HTML, but even then you still have the potential to save a lot of Python code with things like ModelForms and/or FormViews.
  - cdjk 13y ago
    Dynamic forms in django are difficult. Personally, I think generalized handling of forms is just a hard problem - I have yet to see a library that handles every case, nor do I know how I'd go about writing one. There is the package wtforms, however, which I've found is more pleasant than django forms.
  - znt 13y ago
    Maybe try these libraries next time: Crispy forms: http://django-crispy-forms.readthedocs.org/en/latest/ http://django-crispy-forms.readthedocs.org/en/latest/ Floppy forms:http://django-floppyforms.readthedocs.org/en/latest/ http://django-floppyforms.readthedocs.org/en/latest/
raverbashing 13y ago
Django has a steep learning curve (but following the tutorial is good, as opposed to some books that are touted as "very good" but only confuse things) The problem with Django is two-fold: the docs are very good but you need to know Django to be able to find the things there Also, Django is "magic" but less magic than people think and sometimes you need to go beyond the "public API" to do what you want (it doesn't mean you're piercing the API, but it is more grained than you think) And sometimes of course the API is faulty and you have to work around it (like password reset emails that are text only and is being fixed in 1.7)
mikewhy 13y ago
while I'm not familiar with Grails, I am familiar with other frameworks besides Django and I've got to say, it seems like lots of the choices the Django developers made are completely backwards compared to how other frameworks manage things. - Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it? - ModelForm._meta knows it's app_label, why doesn't a regular Form - 200-line migration files are just not fun to grok. - ID based migration file names are a pain when multiple devs are involved (Rails / SQLAlchemy solve it using timestamps / SHA1s. South closed it as a wontfix years ago) - Having a user model you're not supposed to touch - urls.py gets way too disconnected from what they are actually routing to - managing 'apps' is silly, making a new directory in python gives you just about the same advantages. - if request.method == 'POST': ... - The `class Meta:` pattern. SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms. Tastypie also makes a lot of dubious decisions. I just really don't see where this framework fits in.
- Daishiman 13y ago
  > Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it? Because Js stuff belongs in the frontend? Django very explicitly does not do frontend logic. > ModelForm._meta knows it's app_label, why doesn't a regular Form Because ModelForms depend on models which depend on apps to function properly. Forms are just plain old classes. > 200-line migration files are just not fun to grok. No, but they allow the migrating class a lot more flexibility by letting you access the ORM within a migration with no concerns about what your current models files look like. > Having a user model you're not supposed to touch 1.5 and on have pluggable user models. Prior to that most of the important stuff was highly overrideable. > urls.py gets way too disconnected from what they are actually routing to That speaks more of the issues with your routes rather than what the framework allows. There are a few well-established patterns which make the routing no less clear than any other framework. > managing 'apps' is silly, making a new directory in python gives you just about the same advantages. Then you're not understanding what a Django app actually is and how it differs from a regular module. > if request.method == 'POST' As opposed to? > SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms Seriously, these are non-issues, they have been touched upon dozens of times, and you clearly have not used the framework's integration capabilities sufficiently to understand its strengths, so either use something else or learn to leverage its unique advantages.

by cujo 13y ago

Daishiman 13y ago

The idea in Django is that you really want to break up your project into several apps, with each app having just a handful of models and views. Aside from depending on some conventions such as a models and views file for each app, apps can live anywhere, so you can separate them through subdirectories if that works for you. The forms API is, granted, not super easy to work with initially, but its abstractions are really powerful and bending them to your will is trivial, because everything is overridable.

cujo 13y ago
When I used it (forms), it sure seemed powerful in idea, but I ended up with a ridiculous amount of code to generate dynamic forms (different field types depending on the object instance). I will safely assume that as a beginner I was missing some part of the puzzle, but I was never able to track down a good way to do it. Oh well.
- Daishiman 13y ago
  Well, StackOverflow helps a lot there. The important thing is that the process is standardized and fairly uniform. If you're using a lot of code to generate forms that depend on models, look into ModelForms: they allow you to generate a form that maps to a specific model's fields trivially and allow adding additional validation and persisting the model to the database.
- mildtrepidation 13y ago
  How useful Django's forms are (and which ones to use) varies widely based on your requirements. I've had projects where the combination of the UI I had to work with and the data that was being manipulated required Form classes to be built and validated manually. Right now I'm working on a project with a fairly complex data set, but everything is falling beautifully into place with generic ModelForms created implicitly via FormViews with only minor tweaking to field visibility. It took me a while to get a solid handle on them, but Django usually does forms very well. The best case is that your UI requirements are fairly loose, otherwise it's likely you'll end up with mostly-custom HTML, but even then you still have the potential to save a lot of Python code with things like ModelForms and/or FormViews.
- cdjk 13y ago
  Dynamic forms in django are difficult. Personally, I think generalized handling of forms is just a hard problem - I have yet to see a library that handles every case, nor do I know how I'd go about writing one. There is the package wtforms, however, which I've found is more pleasant than django forms.
- znt 13y ago
  Maybe try these libraries next time: Crispy forms: http://django-crispy-forms.readthedocs.org/en/latest/ http://django-crispy-forms.readthedocs.org/en/latest/ Floppy forms:http://django-floppyforms.readthedocs.org/en/latest/ http://django-floppyforms.readthedocs.org/en/latest/

raverbashing 13y ago

Django has a steep learning curve (but following the tutorial is good, as opposed to some books that are touted as "very good" but only confuse things) The problem with Django is two-fold: the docs are very good but you need to know Django to be able to find the things there Also, Django is "magic" but less magic than people think and sometimes you need to go beyond the "public API" to do what you want (it doesn't mean you're piercing the API, but it is more grained than you think) And sometimes of course the API is faulty and you have to work around it (like password reset emails that are text only and is being fixed in 1.7)

mikewhy 13y ago

while I'm not familiar with Grails, I am familiar with other frameworks besides Django and I've got to say, it seems like lots of the choices the Django developers made are completely backwards compared to how other frameworks manage things. - Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it? - ModelForm._meta knows it's app_label, why doesn't a regular Form - 200-line migration files are just not fun to grok. - ID based migration file names are a pain when multiple devs are involved (Rails / SQLAlchemy solve it using timestamps / SHA1s. South closed it as a wontfix years ago) - Having a user model you're not supposed to touch - urls.py gets way too disconnected from what they are actually routing to - managing 'apps' is silly, making a new directory in python gives you just about the same advantages. - if request.method == 'POST': ... - The `class Meta:` pattern. SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms. Tastypie also makes a lot of dubious decisions. I just really don't see where this framework fits in.

Daishiman 13y ago
> Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it? Because Js stuff belongs in the frontend? Django very explicitly does not do frontend logic. > ModelForm._meta knows it's app_label, why doesn't a regular Form Because ModelForms depend on models which depend on apps to function properly. Forms are just plain old classes. > 200-line migration files are just not fun to grok. No, but they allow the migrating class a lot more flexibility by letting you access the ORM within a migration with no concerns about what your current models files look like. > Having a user model you're not supposed to touch 1.5 and on have pluggable user models. Prior to that most of the important stuff was highly overrideable. > urls.py gets way too disconnected from what they are actually routing to That speaks more of the issues with your routes rather than what the framework allows. There are a few well-established patterns which make the routing no less clear than any other framework. > managing 'apps' is silly, making a new directory in python gives you just about the same advantages. Then you're not understanding what a Django app actually is and how it differs from a regular module. > if request.method == 'POST' As opposed to? > SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms Seriously, these are non-issues, they have been touched upon dozens of times, and you clearly have not used the framework's integration capabilities sufficiently to understand its strengths, so either use something else or learn to leverage its unique advantages.