Django for Rails devs
rcoder.net
rcoder.net
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!
* 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 be eager to read such an article too.
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.
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.