RailsCasts Pro episodes are now free!
Learn more or hide this
GitHub User: GregSilcox
I can't believe how much pain this episode saved me this week. Using traditional methods was taking me down a twisted complex path that was dramatically simplified with a form object. This is right up there with presenters and service objects as the most significant changes in mindset for me.
Thanks, this is really well done and helpful. I especially like that the whole process is a refactoring of old code. I've found it difficult to design loading, authorization, presenters, service_objects, etc. into the beginning of a complex project. It always seems to work better to refactor code as it becomes complex into a set of objects that work well together. Form objects must really work well with form builders and form presenters.
This is certainly an area of my apps that needs some TLC. Thanks!
I went through many of the original RailsCasts about a year ago. They where are a great way to refresh on the basics, but rails has changed so much that it would be difficult for a new rails hopeful, such as my son, to make some of them work. Thanks for giving us a fresh, back-to-basics episode.
This article surprised me with a new use model. I see the value in the various methods for providing json for views, but I am building sparse yet complex data structures from the database to perform a diff, i.e. what changed between before and after a process ran.
Serializers seem like an ideal way to produce these structures, especially when it comes to writing exhaustive tests.
Thanks for a completely new idea, Ryan!
I was thinking about this also. The happiest spot for me would be to consider my app as a set of single page apps. Each one would greatly lighten the page reloading, and user experience, but make it easy to move to another single page. The pages would map to my primary resources.
Wow! I feel like I need to watch this several times in slow motion to absorb it. It's amazing how much you can pack into 14 minutes. It also seems like really understanding dynamic forms could simplify my database architecture.
I love the service object approach. Your episode on Presenters from scratch really expanded my mind on how to simplify view code using models. I've come to really hate helper modules because they are so hard to test and easy to make a mess with.
For controllers I've been using a set of classes I call ControllerAssistants. I set them up through a before filter and give them info like the params, etc. They are really easy to test and debug.
My models are huge and could really use some help.
Views need Presenters
Controllers need Assistants
Models need Services
How great is that?
I use quite STI and polymorphism liberally, because I have sets of classes with exactly the same columns. Even so I learned a lot from this episode. I especially like the way you discussed the trade-offs between different approaches. Often, the hardest part is knowing the best option. I end up coding it one way, hating it later then refactoring it to another way. This can waste weeks of time if the models are heavily used throughout the application.
I also really like your authentication from scratch. When AuthLogic went through it's unsupported period (Rails 3.0) I was really stuck and really came to value being in control of my core logic. Often we use huge gems because we need 10 lines of code from them, and spend more time figuring out how to wrangle them to fit our needs when coding from scratch is tiny, fast and takes less time (Devise).
Thanks. Yet another episode worth a year of my pro subscription.
I think it would be better to make an app that is so compelling the user wants to join. Why have grumbly users that are only there because it is too much work to switch.
I've been working on a multi-tenant app for about four years now. I didn't know it was called that and have seen so little written about it, I made it all up from scratch. And it's been ridiculously complex. Especially with a myriad of roles per tenant, and several tenant types. Although mine works better without subdomains, I think I can apply the default scope to my current methodology for enhanced security/protection against developer forgetfulness.
This is most mind-expanding episode I've watched so far. I can't even get myself to code today because I keep thinking of ways to implement this into my project. It's possible I could remove dozens of files and lots of complexity, while improving the testability with this method.
There's nothing like having the author of cancan explain authorization. Thank!
Thanks for mentioning dom_id. I wrote my own helpers for this. I can now go remove code. :)
Thanks, Ryan. Being able to see the email in the browser sure beats looking at the markup in the logs and imagining how it might look!
Wow, I moved to pg over a year ago so I could use Heroku. I never even knew it would help me with search. I have some code to update. Thanks!
Every time I think I really know what I'm doing in rails you humble me. This is so simple and useful, and I didn't know it. Thanks so much!
@Elliot Larson, I think you've nailed it.