This is the first time I've really thought that the form classes were a benefit in Django. Usually it's just annoying that Django doesn't have model validation working yet.

Really, I was surprised (and grateful) that the article went so far beyond the trivial surface issues that people usually bring up - like the automatic admin interface or Python vs. Ruby arguments. I was expecting a flame piece and got a well thought out piece exploring what is good about both frameworks. Well done!

Seriously, ModelForms are pretty much the greatest thing since sliced bread.

Maybe I haven't delved deep enough into it (and I would love if you would correct any misconceptions to what I'm about to write).

* It's kind of a pain to have a form object that deals with multiple models. I always find myself having to put {{ form_for_model_1 }} followed by {{ form_for_model_2 }} in my templates. Maybe it just seems messy to me. I wish there was a way that formset_factory could take forms for different models so that it would all validate together and print together. I guess it isn't such an inconvenience that I should complain so much.

* It would be really nice if I could raise ValidationErrors on the model and have them caught by the form class.

* It's a bit annoying that Django's form library has a CharField which gets <input type="text"> and there's no TextField to give one a <textarea>. Yeah, I know you can specify widgets, but still.

And I guess what I really dislike is dealing with Generic/Polymorphic relationships and forms which is also a pain in Rails. I guess I'm still partial to Rails' <% form_for %>. Partly that's because with Django I can't add random parameters (in the hash of params). Like, I can't do forms.CharField(render_alongside_last=True) in Django since it doesn't take 'render_alongside_last' as a parameter. With Rails and form generators, I can put in directions like that so that I can do more than just the same rendering for each field without having to custom do every field display. Plus, syntactically, it just seems nice as you nest things and such.

And Rails has some nice ways of dealing with related objects and automatically setting the foreign keys and such with accepts_nested_attributes_for :model. Since the ModelForms are separate, they don't get that automatically and you have to add the key from the other object.

Just to reiterate, I would love to be proven wrong on any of these since I'm primarily a Django developer today.

I would love a "Ruby on Rails for Django devs" article too, if anyone has something like that.

So would I - a "Spring for Django devs" article would be pretty useful too.

That would imply writing n(n-1)/2 "X for Y devs" articles, or an O(n^2) complexity.

A much better way would be to have an universal standard, possibly abstract framework with which all frameworks are contrasted. This way, only n comparison articles need be written, giving a linear cost.

Sorry, could not abstain. OTOH, this principle is mighty useful when writing conversion software. Just write converters to and from a standard format.

Having done web development exclusively in Python (Zope,...,Django), I some time feel that I may be missing out on the advances in a large ecosystem like J2EE(Spring etc.,)

I would be eager to read such an article too.

I don't think you're missing out on a lot, and that's coming from someone who uses both Spring and Django daily. There are a lot of Spring projects, but just to give you an example: - Spring Security --> django.contrib.auth - Spring MVC --> well, Django urls, models, views and templates. - Spring Core/Beans (the dependency injection part) --> do you think you need it?

In the average JEE project, that's all you'll be using as far as Spring goes. Or maybe add Spring Integration or Spring Batch.

It is nice to have schema updates as part of ActiveRecord right there in Rails for you, but South is so easy to set up I don't feel like it can be considered a win for Rails.