-
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
end*following a few posts below, we agree that something like this should be in the controller instead
or
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
end -
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:
/assets/javascripts/views/foo/index.js.erb
/assets/views/foo.js.erb
/assets/application.erb.js
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 soresources :users do
resources :books do
resources :chapters
end
endI 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
user_house_room_path(room.user_id,room.house_id,room.id)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.idOr 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 @bookso 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.
By Andey February 10, 2012 - 4:00 pm
I think the routes being defined in each controller would be amazingly convenient
By Emil February 10, 2012 - 8:10 pm
Agreed, but certainly not in the model. They don’t belong there!
By admin February 14, 2012 - 9:28 am
There are plenty of better options than there is currently. ie a routes.yml file could be nice.
By Amol Pujari February 15, 2012 - 9:21 am
what about all public methods in controller become routes by default.
new annotations/clauses can be introduced to handle specific cases
Amol
By UnderpantsGnome February 14, 2012 - 5:06 pm
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.
By Michael Latta February 14, 2012 - 5:18 pm
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.
By Wojtek Mach February 14, 2012 - 5:52 pm
>> 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:
galaxy_system_path
system_planet_path
Also, if you have instance variables @galaxy and @system simply writing:
galaxy_system_path
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
By Adam Crownoble February 14, 2012 - 6:36 pm
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.
By Jeremy February 14, 2012 - 9:38 pm
I think you might be overly relying upon generators.
By Chris February 15, 2012 - 12:43 am
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.
By Artur Roszczyk February 15, 2012 - 6:39 pm
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)
By Helmut Juskewycz February 20, 2012 - 10:02 am
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.
By admin February 21, 2012 - 2:41 pm
I agree with you now, as some previous comments have clarified my post.