CRUD Scaffold Generator

Scaffold

Rails 2.1 removed the original scaffold generator and replaced it with a new RESTful scaffold generator.

Bummer.

I’m not talking about the dynamic scaffolding that comes from putting “scaffold :model” in a controller. That “dynamic scaffolding” was removed in Rails 2.0 and few of us miss it. I’m talking about when you type “ruby script/generate scaffold Model” from the command line and get generated model, controller and view files as a result.

While I understand that Rails is “opinionated software” and that they want to encourage everyone to get on the REST bandwagon, I think completely removing the old scaffold generator was a mistake for one simple reason:

It unnecessarily raises a barrier to entry for beginners.

When beginners first start on Rails there is a lot to digest. Installation issues, Ruby language, MVC architecture, ActiveRecord, Rails syntax, routes, migrations and deployment—just to name a few. In my opinion, asking someone eager to learn Rails—someone who may have a background in PHP but who still doesn’t understand code blocks or the basic Rails .find syntax—to also use REST from the start is only going to frustrate them and slow the growth of Rails adoption. They need to walk before they can run. We have added best practices for advanced users at the expense of the newbies.

The Lesson of Microsoft Excel and Lotus 1-2-3

I remember when Microsoft Excel won the spreadsheet market away from Lotus 1-2-3. They did it in part by making an easy transition path so that Lotus 1-2-3 users could make the switch painlessly. (Lotus was also slow to adopt Windows, and Microsoft pushed out frequent releases with new features. Two other important lessons.) It was more work on Microsoft’s part to make Excel “Lotus-friendly” and meant supporting and living with code inside Excel that must have seemed extraneous and deviated from “best practices”. But that extra code wasn’t actually extra, it served an important function: to bring users into the product. Without those users, you could argue that the rest of the Excel code—the “essential parts”—would not matter.

If we want developers to transition from other technologies to Rails, it is important to keep the barriers to entry low and to make the upgrade path simple. Every developer who gets curious about Rails and says “Hey, I picked this up fast” will grow the audience and probably evangelize to others. That’s exactly how Rails got it’s amazing, viral beginning. But every developer who gets curious about Rails and says “I just tried it but I couldn’t make sense of it” is a developer whose participation, enthusiasm and evangelism we lose. For that reason I think the decision to remove the old-style scaffolding takes Rails in the wrong direction.

The Utility of the Original Scaffold Generator

The original scaffold generator made Rails easier for beginners by introducing the basics of CRUD (Create, Read, Update, Delete) and by giving them an opportunity to see how the Rails request/response cycle works, how routes work, how parameters are passed, and how instance variables and object instances do or don’t persist. It was a friendly introduction to the framework and to world of object-oriented programming for the uninitiated. It offered a smooth transition for anyone used to PHP, Perl, Python or Java. The beauty of the original scaffold generator code was not so much that it was useful, but that it was instructive.

The Solution: CRUD Scaffold Generator Plug-in

Fortunately, one of the wonderful features of Rails is it’s extensibility through plug-ins. So the original scaffolding doesn’t have to die just yet. I put the original scaffold generator into a plug-in, updated it (for example view templates now end in “.html.erb”) and cleaned up the views and styles a bit. I’ve called it CRUD Scaffold (”crud_scaffold”) so that it won’t interfere with the built-in “scaffold” generator’s RESTful scaffolding and to make clear that it generates the basic CRUD for a model. (99% of the credit goes to the original coders.)

You can download the plug-in by going to the github page for CRUD Scaffold Generator and then clicking the download button. Unpack the file and put the entire crud_scaffold_generator folder into the /plugins folder of any Rails application. Run it from the command line while inside the root of your Rails application:

1
ruby script/generate crud_scaffold Modelname

Where Modelname is the name of the model for which you want to create a model, controller and views. It works just like the old scaffold command use to work.

There is one big change in my version that is worth noting. The old scaffold used to dynamically read the fields from your database table, this one does not. I never found those dynamic fields useful and found they were confusing to beginners. Instead, my version reads the fields from the database table when you generate the scaffold. So it is a good idea to first create/migrate your database table, then generate the scaffold. If you add fields to your table later, you’ll have to either re-generate the scaffold or add the new fields to the views by hand.

My hope is that the CRUD Scaffold generator will keep it easy for beginners to get started with Rails. I know I’ll be using it in all of my Rails courses.

Bookmark and Share

17 Responses to “CRUD Scaffold Generator”

  1. Clinton R. Nixon Says:

    I find it hard to imagine that any Rails developer anyway wants to make it easier at the expense of quality code. Even if one did, though, REST is not a hard concept at all to understand. To say that REST makes it hard for beginners to get started with Rails - to say that you’ll avoid it in your courses - is an insult to the people you teach.

    The structure of REST is amazingly simple, and it simplifies working with Rails. Perhaps your assumptions about its difficulty come from your familiarity with pre-REST Rails, which I can understand. You’re incorrect, though.

  2. Kevin Skoglund Says:

    I didn’t say REST was hard and I never said I would avoid it in my courses.

    I said that it is a lot to throw at a beginner. Maybe you have enough experience to make the leap straight to REST, but I work with students from a wide variety of backgrounds and many don’t. Most beginners are not coming from an object-oriented background and have little or no experience with an MVC framework. Some beginners have only a small understanding of the difference between GET and POST, much less PUT and DELETE.

    It is my opinion based on my teaching experience (and you are welcome to disagree) that it is easier for beginners to understand the fundamentals of Rails, and then learn REST from there. Essentially to say: look how this is just like what you were doing in language X before and see how much easier it is in Rails. Once they have made that switch, you can move on to learn REST from there.

    Like I said, I hope it helps beginners. I know that it will help me to teach them.

  3. Lucy Says:

    I see your objection, here, but I’m not sure I entirely agree. I started learning Rails about six months ago, and as such I have only ever used the RESTful scaffolding. I was coming from a background of zero programming knowledge - I knew extremely basic html and that was it. I didn’t realy find it a barrier - as you say, there’s so much to learn, so it’s just one more thing among many. Maybe for those coming from other programming langauges the old version was easier to grasp, but I can say that as a complete n00b it makes no real difference.

    That said, I completely agree with the principle behind what you’re saying. I’ve been following your Lynda.com course and it’s defnitely the best introduction to Rails I’ve come across. The reason for that is your step-by-step approach, so that the priciples behind what’s happening are very clear. Since I already had experience generating the RESTful scaffold (and I knew the course was a version or so behind the Rails version I was using) I just assumed things were done differently in the old version, but followed the principles, and I’ve found that really, really awesome. But just explaining the principles the same way would have worked, I think, even when generating a RESTful scaffold. Again as a new user, I’d always rather learn the best practice way to do it from the get-go - it’s just having the priciples behind the Rails defaults explained that really makes the difference.

    All that said, I LOVE your course, I think you’re the best Rails trainer out there. I hope to see a bnew version for the updated Rails soon. So, if your experiecne as a teacher suggests this update is bad news, I’m definitely willing to believe you could be right. But I thought you might be interested to hear the perspective of someone who is both new to Rails and a user of your course.

    Thanks again!

  4. Kevin Skoglund Says:

    Lucy, thank you for the kind words and for your perspective on scaffolding. I’ll definitely keep it in mind.

    And FWIW, we are working right now on updating the Lynda.com Ruby on Rails training to the newest version.

  5. A Fresh Cup » Blog Archive » Double Shot #238 Says:

    [...] CRUD Scaffold Generator - Rails’ original non-RESTful scaffolding lives on in a plugin. [...]

  6. ellioman Says:

    “And FWIW, we are working right now on updating the Lynda.com Ruby on Rails training to the newest version.”

    Great to hear.
    I am currently going through your Essential Ruby class and had a problem in the “Scaffold: Magic CRUD”. I just skipped that chapter and I’m going strong ;)

    Great classes and I hope you continue to produce more…!

    Cheers from Iceland
    Elvar

  7. Aditya Says:

    Seeing maximum number of RoR articles on your weblog,it is not difficult to guess your favourite programmimg language.

    I have been following some of your articles for quiet some time now. Sometimes when one knows two or more scripting languages, he may be confused while selecting a language for a particular project. How do you decide? For example both RoR and PHP can be used to develop data driven web applications. Also when do you choose between Javascript or PHP or RoR for form field validation.

  8. Kevin Skoglund Says:

    @Aditya: In general, yes, I prefer Ruby on Rails. I find it more enjoyable, mostly because I love the Ruby language. But it’s not necessarily the right tool for every project. I also like the simplicity and no-fuss of working in PHP.

    A client’s needs or project’s requirements are the driving factor in making a language choice. Some clients already know which language they want for a new project. Sometimes you will be brought in to work on existing code. If a client already has a large site in one language, rewriting their site in another might not be in their best interest.

    I also factor in the client’s budget, their technical expertise and what ongoing technical support they will have when I complete the project. Simple sites may not need a full framework like Ruby on Rails. For clients with small budgets, it can be cheaper and easier for them to find a PHP developer to help them out down the road. (Rails developers are fewer and in high demand right now.)

    For form field validation, I do most validation after form submission in PHP or RoR. I use JavaScript when I want to give a different user experience or to correct simple mistakes (like only letting a user check 2 out of 10 checkboxes).

  9. Branden Silva Says:

    Hey Kevin,

    I know this is a fairly older post but I wanted to chime in on your post.

    I agree with your post. I know when I was going through your courses (which are excellent by the way) I was wondering why the dynamic scaffolding technique was not working when I installed the latest version of ruby on rails. I love the language and I’m slowly learning but the only way I found out how to do scaffolding the RESTful way and a way a beginner would understand was by searching the net for an hour or so.

    I’m no hardcore programmer. I’m fluent in XHTML, CSS, & a little in PHP but I wanted to just say thanks for the courses, they have gave me a great insight into RoR and I hope to see more from you in the future.

  10. John Burgoon Says:

    I completely agree with Kevin. Making Rails 2.x RESTful is fine, but deprecation and removal of old tools should be S L O W. I’ve been learning not only Rails, but Ruby, MySQL, and a host of other (unrelated) technologies at my new job. Although CNixon (above) thinks it’s insulting to my intelligence, I can tell you that I have plenty of intelligence - it’s just _REALLY BUSY_.

    I say, PLEASE insult me. Assume I know NOTHING. Show me what the code should look like, because the odds are that sometimes I won’t see what you are so sure I should be seeing… especially if the Folks Who Develop Rails keep breaking/deprecating things in favor of their lofty ideals.

    For example, how many of us have had to go and modify our config files because the Rails Gods have the energy to deprecate something (I give you, for example, config.action_view.cache_template_extensions) but don’t have the decency/energy/intelligence to change Rails so that “rails ” stops adding the deprecated items into the configuration? How many human production hours are wasted on these kinds of loose ends?

    The fact is that I might “know” a thing but be unable to precisely recall the syntax… such as the CRUD controller syntax handed to me by scaffolding. This happens often, in fact, and I rely heavily on the tools described in the majority of tutorials. Adding RESTful methods to Rails was a great decision - but removing the old scaffolding so soon was a stupid, short-sighted, newbie mistake. I hope I do not insult the intelligence of the intelligentsia who rule the ruby roost by pointing out that getting a host of excited newbies reliant on a simple tool (like scaffolding) and then yanking it out from under us is like, well, the good ole days of Microsoft.

    Thank you Kevin for giving me back the fundamental tool (scaffolding) upon which MOST extant Rails tutorials rely. A year from now when I’m a snooty Rails expertigentsian, I’ll try not to sneer at the intelligence of the poor devils who are trying to learn the hard way while juggling five or six other new technologies to boot.

  11. Kyle Kirst Says:

    Yes, Kevin, all you courses are wonderful. I was hoping that you guys would update the courses to reflect the scaffold in 2.2. I understand you recently had a child, so i understand you must be really busy. I just had a little boy last july 13, so i totally understand. Hopefully you get around to it sooner though, thanxs again for all your classes! Kyle

  12. Bill Andersen Says:

    Kevin, thank you for your scaffold plugin. It will help me complete the lessons on Lynda.com. I’m sure I will come to agree that the REST way is better, but you hit the nail on the head when you wrote that the change “raises a barrier to entry for beginners.”

    I look forward to your new Rails tutorials. Hope they are available soon.

  13. C. Spencer Beggs Says:

    To anyone following the “Ruby on Rails Essential Training” from Lynda.com and is using the latest Rails and RubyGems releases, you need to drop the “crud_scaffold_generator” folder into “vendor/plugins”

    To get to the right place in the “Scaffold: Magic CRUD” chapter, generate the Album model, then Admin controller and then use this command to generate the scaffold: ruby script/generate crud_scaffold Album Admin

    Overwrite anything it asks you to.

  14. Rob Jones Says:

    Kevin:

    Thanks for this! I am what I consider a very technical designer, and every year or so I come back to Rails and find that they have changed SO MUCH in it that all the books and tutorials are obsolete to beginners/novices that have not kept up with all the changes. Even if REST is better, its such a drag that the changes essentially throw all the old learning materials away.

    Great stuff,

    Rob

  15. Rob Jones Says:

    Another thing - its great how you have the exercise files that you can download, but they don’t work with the latest Rails… If you could update those too that would be useful.

    I am at chapter 12 and want to “reset” my project with your files, but I can’t just run your example files with script/server nor can I use my current Rails to generate a new project and import your “app” folder into it. Bummer.

  16. Kevin Skoglund Says:

    Thanks, Rob. We are actually recording a completely updated RoR Essential Training now.

  17. Rob Jones Says:

    Awesome! If you need someone to “test” it on lemme know… I’d be glad to help

Leave a Reply