Rails 4.0 Wishlist

    TL;DR Maybe I’m an idiot, but I’m looking at Rails from a beginners point of view.

  • Routes defined in the model, maybe as: and :via attributes would suffice.

    Maybe like this:

    class User < ActiveRecord::Base
      Route :author # this could probably be accessible from a controller in params
      Route :reader
      Route :moderator

    *following a few posts below, we agree that something like this should be in the controller instead


    class Book < ActiveRecord::Base
      Route :novel, :via => :author # this would give you; /novel/arthur_conan_doyle/sherlock_holmes_the_hound_of_the_baskervilles
      Route :mystery, :via => :hero # would give you /mystery/sherlock_holmes/the_hound_of_the_baskervilles

      ... # friendly id code
  • A Routes admin panel/sitemap, to see if those routes are setup correctly, something like resque. or maybe a tree structured ‘rake routes’ or a instrumentation panel like the top command to see when routes are being accessed.

    i’ve not specified the value for the ‘:user’ and ‘:house’ hashes as their path should be implied by the route setup and passing them should not be needed.

  • An interactive mode for migration generators, so that you don’t have to track table names and column names down. For example; new, remove, add and delete generators.
  • Generators which have to option to include annotations linking to the related file paths in comments, for example: in a controller have “# ../views/modelname/edit.html.erb” just above the edit action so that a ‘gf’ in vim just sends you there or a click in sublime text or another editor.
  • Api only generators, so the generated controllers and models have an api specific output (no views, token driven), maybe backbone aware?

    Maybe creating a backbone app as default, by having api and backbone model generation.

    Backward compatibility for decoupled webapps; for example using v8 or therubyracer to create an old school app for when the user’s browser fails a certain prerequisite, i.e. serverside backbone.

  • View-specific assets, i.e /views/foo/index.html.erb will load from the following:
    this is to prevent javascript logic from unrelated views loading in the wrong places, this is more for cleanliness in the head than for security through obscurity.
  • A nested view structure:
    If my resources are nested like so

      resources :users do
        resources :books do
          resources :chapters

    I should be able the structure my views like this; “app/views/users/books/chapters/index.html”

    Those nested resources would probably have to work like partials.

    Routing errors should be more descriptive, show the previous view, current view and controller in the error, the glaring error might just be obvious immediately.

    How about adding a queries to routes as a replacement for path helpers.

    Instead of something like this


    as you noticed the first two parameters are just taken from the last parameter in that instance and should just be “implied”, maybe we should have something like this:

      path_for :user, :house, :room => room.id

    Or maybe like this:

      edit_galaxy_system_planet_path(galaxy.id, system.id, planet.id)

    In this example the path could be based on the order of the system in a galaxy and the planet number in a solar system instead.

    But instead if using path helpers, we could have a path “finder”

      Path(:edit, :galaxy => :id, :system => [:x, :y, :z], :planet => :number)

    But if the last parameter is :id, then the galaxy id, and system coords would be surplus to requirements and the path finder should be able to figure that out and shorten the url (if that route is defined in routes.rb or defined in a controller) and probably show a warning.

    Or what about just adding a `path` method to models for example you can do

    redirect_to @book

    so why not have a path method like

    redirect_to @book.path(:via=>:author)

    or something to that effect.

  • a decoupled “view app” that only contains views, assets and mock controllers to hand off to designers (maybe for outsourcing purposes) that you can copy and still run, possible using something like Sinatra in that layer.
  • make renaming an application easier, by removing the need for the apps namespace all over the place, or by having a ‘Rails rename’ command.
  • prettier error messages, for example “missing page” could load a placeholder (sometimes you just want a page to debug to)
  • Rails generator history, I often come across a demo app that does what I am looking for but I will then have to trawl through the git commits to see how that app applies to my app, I am ok with copying files and modifying them for my needs but when it comes to files that have been created via a generator then they are hard to duplicate. I propose the rails generations are logged in a file so that it can be used later to create a step by step tutorial.

13 thoughts on “Rails 4.0 Wishlist

  1. Your decoupled “view app” can easily be accomplished using an Engine. They checkout the view repo, mount it up in a rails app and bang away on the views. Commit their changes and you update the gem when it’s ready.

  2. I would like to see resource aware convention over configuration. Routes are a bandaid. We should be specifying the resource model / API model and let the routes be derived from there. Given a set of models, and the ability to specify the public API. The full rest API for routes could be derived.

    The existing routes approach tries to support rest routes, non-routes, and too many other aspects like legacy URL schemes. We can keep a way for legacy schemes, but there should be a default resource aware scheme.

  3. >> edit_galaxy_system_planet_path(galaxy.id, system.id, planet.id)
    You generally shouldn’t have more than 2 level nesting (I believe Jamis Buck wrote about that somewhere), you can have instead:
    Also, if you have instance variables @galaxy and @system simply writing:
    is actually enough.

    >> Generators which have to option to include annotations linking to the related file paths in comments, for example: in a controller have “# ../views/modelname/edit.html.erb” just above the edit action so that a ‘gf’ in vim just sends you there or a click in sublime text or another editor.

    With vim-rails, inside edit action you can just use :Rview

  4. I like your idea of having the routes as methods of the models. However, I realize that this sort of thing really shouldn’t the responsibility of a model. But I think it does make sense for a presenter to able to represent routes.

    Along those same lines, I think ditching procedural helpers for something more object oriented like presenters would be a great new feature for 4.0 as well.

  5. Routes should definitely not be in the model. Models should only be used for business logic.

    Rails routing is extremely powerful. You need to full expressiveness of ruby to define them. Yaml files are too simple to be used for this purpose.

  6. If comes to path, you could have use sth like this, since rails 2.3.x (AFAIR):

    link_to “Edit”, [:edit, :admin, user, room]

    expands to:

    link_to “Edit”, edit_admin_user_room_path(user, room)

  7. I am sorry but I dont get the “put everything in the model approach”.

    I appreciate the ActiveRecord Pattern, although, I also understand the advantages of a separate data access layer. But putting something like routes in a model is completely wrong. Not all the time resource routes are a 1:1 mapping to models. I dont know why some believe that a routes should correspond to a model. I dont want to model my database scheme to routes and vice versa.

    Use the lib folder, use engines, use good programming techniques (Java has some good approaches), and don’t use models as some kind of code dumpster.