11–20 of 27 posts
I almost fell off my chair laughing when I saw "Rails" and "Security" and "Maintainability" in the same sentence. A quick search here itself on HN will show you how immature and security-hole ridden Rails is. Built for, and by, HIPSTERS!
I'm glad to see rails devs are finally coming to their senses and exploring other patterns for building applications. SOA, command objects, etc. have been a pretty common pattern in "enterprise-y" frameworks for awhile. This is making rails look more like grails, which I think is a good thing.
At least for the apps I've been maintaining as a freelance, quite often they had services of some kind and other classic patterns.
Many Rails developers I know come from a Java and/or .Net background, so this is not really a surprise :-)
Having transitioned from Django to Rails nearly a year ago, this post reminded me of django forms[1]. When I used django, I didn't think much about them, but moving to Rails, I felt something was missing. Why do validations live only/primarily on the model? Doesn't it make more sense to do validation higher-up the chain to filter mistakes and potentially harmful input? Also a good point about the `attr_accessible` co…
This is exactly why edge Rails is moving towards strong_parameters, where these are enforced by the controller rather than the model.
Looks like typed function to me.
- How can this be used in tandem with strong_parameters; should ensuring the structure of params be a responsibility of the controller or the mutation (I'm leaning towards the former)? [1]
- How can validation duplication between models and mutations be avoided? In the example 'string :email, matches: EMAIL_REGEX' was used, but presumably one will still validate the email in the model. I'm guessing there are solutions to this, perhaps the existing model validation can somehow be used?
This seems like a great idea! I have a few thoughts that comes to mind, perhaps others can chip in: - How can this be used in tandem with strong_parameters; should ensuring the structure of params be a responsibility of the controller or the mutation (I'm leaning towards the former)? [1] - How can validation duplication between models and mutations be avoided? In the example 'string :email, matches: EMAIL_REGEX' was…
User.email.validation
Similar to that query project.. Can't remember the name now :-)
How would Mutations compare with Concerns, which seems to be DHH's preferred method?