Is it the first to this community or already the discussion started. sorry if posted it again. This is for people who has not seen this... ------------------------------------------------------------------ Rails' Ridiculous Restrictions, a Rant I recently finished using Ruby on Rails to write a simple bug tracking application. I thought I'd take this new RAD environment for a spin, having heard all the hype. It kind of blew. Don't get me wrong: I have to admit, it was a fun experience. There's a thriving community around Rails, and I get more email in an hour on from the Rails mailing list than on all five of my Perl lists in a day. Rails doesn't do anything any other framework hasn't done. BUT, I admit it integrates all the bits and pieces bloody well and sprinkles the whole thing with some smart marketing. A light webserver, ORM, templating language, code generator and pre-built templates are nothing new, but a killer viral 5-minute video demo of all those things working together brilliantly IS. But Rails also annoyed me. A lot. The developers have taken a brilliant idea -- brilliant -- such an incredibly short distance. Insert sports metaphor here. Rails lived up to most of the hype, but who wants to hear about that? As an entitled American who contributed not one line of code to Rails and has used it for all of one project, I am of course brilliantly qualified to bitch about it. Here's what SUCKED about using Rails: 1. IT TAKES THE RELATIONAL OUT OF RELATIONAL DATABASE MANAGEMENT SYSTEM Basically, Rails groks tables and columns well, but relations are second class citizens. This is so stupid. Rails is smart enough to look at my database's entrails and build accessors, craft templates and generate controllers to handle the whole thing. I can Create, Edit, Update and Delete without writing any code. As long as I don't leave the table. DO NOT LEAVE THE TABLE! In fact, don't even glance outside the table, like to get some labels for some ids in a popupmenu. If Rails is already taking a latex glove to my db schema, how about feeling up those foreign key constraints I set up? Kind of a good hint about how to arrange has_many and belongs_to associations, ain't it? OK, forget foreign keys. Let's pretend I'm too amped on Mtn Dew to care about imposing data intergrity at the data level. There's still no excuse. Because Rails insists I name my foreign key columns table_id if I want to live the good life. When I do so, I shouldn't have to declar has_many and belongs_to. Perl's Class::DBI::Loader is smart enough to autodetect relationships, and has been for some time. There's no reason Rails can't do this as well. This isn't some minor feature. Any halfway decent data model is going to have tables that RELATE to one another. That's why we keep them in Postgres or Oracle or Mysql or SQLite instead of a flat file. It gets really really old retyping the same type of popup onto a template and a has_many for every belongs_to and a belongs_to for every has_many. Rails should be able to do this. After all, it makes three-way outer joins look effortless with the :include attribute to Class.find. Not even Class::DBI is there yet. Ideally: -Rails detects relationships from foreign keys or column names. -Rails automatically sets up has_many and belongs_to associations at the model level. -Rails creates some extra @instance_variables at the controller level to pull data from other tables in. -Rails uses popup menus at the scaffolded view and generated view level to select foreign data. For example, user_id becomes a popup menu of users, resolution_id becomes a popup menu of bug resolutions. 2. RAILS DOESN'T PLAY WELL. WITH ANYONE. NOT EVEN ITSELF. The cool thing about the Rails demo is the guy, I think it's that Scandinavian guy who invented Rails, is sort of playing. He says "woops" about every three seconds. He changes things in a text editor and BOOM -- the application changes. But do you remember that moment in the demo when the play turns ugly with a big ole error page? It's when he tried to update his db schema or model or something. It doesn't work because he has to reboot the webserver before those changes take effect. Which he says and moves on quickly. Well, it turns out that webserver rebooting requirement really sucks when you're trying to, um, Rapidly Application Develop. Now, I understand why this restriction exists. If Rails has to look at your schema on every request, you're going to take a performance hit. But having to reboot the webserver makes Rails feel like a step backward from even CGI Perl in terms of speed. At least in that environment you can just reload the script to see if your changes worked. Why can't Rails adopt the smart middle ground? The webserver does not need rebooting, until you set a :fast flag somewhere, in which case Rails caches the schema info. Since Rails already differentiates development from production, this should be pretty painless to implement. --->Rails also doesn't play well because it will overwrite your code. Here's the scenario: you started a project in scaffolding mode because you were learning Rails and this is Rails' coolest and easiest mode. You made some slight modifications to the models and controllers as you associate your models with one another. Then you discovered you wanted to depart slightly from the scaffolding. So you backed out and figured out how to ruby script/generate scaffold Thing. Except -- Woops! -- this overwrites your old code, your models and controllers. In the case of controllers, you may be safe because the scaffold generator will use the plural form. But your model is probably toast. Rails allegedly will ask permission first but, um, it didn't. The solution is to stop playing and start over at the beginning and DO THINGS RIGHT THIS TIME, DAMMIT! Here is an actual entry from the Rails FAQ: "Q012:That stinks... I want the scaffold code without starting over! Too bad. Start a new rails project, run scaffold, then manually add the missing stuff to your new project from your old project with copy and paste." Are we having fun yet? --->This "back to square one" technique returns again and again in using Rails. When I installed the login-engine plugin for Rails -- which is really cool, by the way, even Perl's CPAN does not have libraries operating at this high a level yet -- there was no documentation on how to make it work with my existing user table. Fine. I let it build its own table, made a new user and logged in. But then when I went to install user-engine, which adds access controls on top of login-engine, it again did not want to integrate my existing data. The user I had created 5 minutes earlier in login-engine was useless. I had to let user-engine autogenerate a new user named "admin" with an insecure default password. 3. YOU CAN'T READ THE FACKING MANUAL BECAUSE THERE IS NO FACKING MANUAL. Rails has no manual. Let me repeat that: Rails has no manual. If you haven't used Rails, you may not believe me. Well, go visit the Rails documentation page: http://rubyonrails.org/docs Hmmm ... We have APIs, Tutorials, HowTos, Snippets, but no manuals. There's a section called "manuals" but that's documentation for side projects, like a standalone utility called SwitchTower, or how to upgrade rails, or "Routing," whatever that is (odd place for a networking primer). You do have "API," at api.rubyonrails.com, which is a nice reference. Actually, no, it's a baffling, messy, ugly, confusing jumble of documents with a fairly useless introduction. Once you figure out that all key classes are annoyingly prefixed with the word "Action" and that the base classes are actually named Class::Base instead of just Class, you can pretty much usually find what you want if you know what you're looking for. But this is a terrible way to learn the framework. Which brings us to the section "Books." Ah, the REAL manual. Let's set aside that it feels a little slimy to start in on a "free" application framework and a very slick "free" video demo and read a bunch of free O'Reilly tutorials only to find out, when it gets down to brass tacks, you're going to have to shell out $35 for a linear, rational, comprehensive overview of the language. Ya, let's set that aside. Fine. Harumph, but fine. What gets me is I am just *not* going to pay to read 570 PAGES about a framework! I'd actually pay twice as much if they could boil this sucker down to 200 pages or less! If I am going to waste time, I might as well go online, where the information is free and up to date. If you want to sell me a book on a rapid development framework, keep it tight! The whole point of my paying for the book is that my time is valuable. And the whole point of you, framework developer, writing the book is that you can most elegantly and efficiently summarize the framework because, well, you know the whole story! 4. RAILS ATE MY DATA, OR AT LEAST STOOD IDLY BY WHILE MY DATA WAS EATEN Rails knows which column is varchar(40) and which is int(11), but don't expect it to do anything with that information other than maybe size the text fields in your scaffolded HTML form. If you plop 80 chars of data into a 40 char field, Rails goes ahead and passes it along to the database this way. A certain extremely popular "database" will silently amputate data in this situation. Rails inserts the data and raises no error. This is especially silly since a> Rails already incorporates methods to validate input for particular columns and b> Rails is already recording column types. 5. THE FIRST RULE OF RAILS IS: DO NOT TALK ABOUT RAILS' RULES! Rails has lots of important rules that you need to follow if you want things to work easily and to really flex the power of the framework. But all the demos I saw, including the Onlamp.com tutorial, were so busy hyping how easy Rails is that they glossed over the rules, even though they are pretty simple. The trouble with that approach is that people end up trying the framework, and use techniques from elsewhere that can really gum up the rails works. Like naming database tables in singular form (ala Philip Greenspun) or naming a foreign key "user" instead of "user_id" (ala Class::DBI). And then they become unnecessarily frustrated with the framework. Rails needs to put a set of simple rules in a place where most newbs will see it. Things like: -name your tables in the plural -foreign keys should always be named like so: tableNameInSingularForm_id So: user_id (foreign key) -> users (table) -models are named singular -controllers are plural, at least in some cases -many-to-many jump tables should be named: alphabeticallyFirstTablePlural_alphabeticallySecondTablePlural So: axes_users -columns in many-to-many jump tables should be named like other foreign keys So: axe_id and user_id -columns named created_on and updated_on will automatically be populated correctly 6. THERE'S MORE THAN ONE PLACE TO SAY IT You want to setup some kind of configuration for some particular rails package. You: A. modify your existing code, which will use the package B. modify code in the package itself C. specify when you install or bootstrap the package via ruby script/* and the command line D. modify -APPBASE-/config/environment.rb E. modify -APPBASE-/app/controller/application.rb F. modify -APPBASE-/config/environments/-ENVIRONMENT-.rb I had one engine that needed four of those. Anyway, those are all the headaches I can remember. I'm pretty sure I've forgotten a few, but oh well. I only say all this because Rails is the first framework worth criticizing. Oh, not really. Who am I kidding? I say this because I like to complain. But hopefully more people will start learning Rails, if only so they go back to their home platform all charged up to do it one better. a Hack Wednesday, February 15, 2006 ------------------------------------------------------------------ thanx g.balaji -- Posted via http://www.ruby-forum.com/.