We're at a point in our development where there have been many different fingers in our Rails pie, and there are things we know exist currently that are not being used, etc. What I'm looking for is some way of programmatically determining if there are any orphan routes in the controllers, maybe something that will take the output of rails routes and see if there is anything extraneous in the code. Any thoughts?
It sounds like what your looking for is known as code metrics, there's one solutions in particular that I can think of that sort of covers what you need. It's known as the rails_best_practices gem, one of the many things it checks for is unused controller actions. In addition it will inform you that auto generated routes (e.g., index, show, edit, update, etc..) require restricting when not all of them are used.
For instance the following line will create seven RESTful routes for your Foo controller, regardless of whether they're actually ever implemented or not:
resources :foo
But if your controller only makes use of say the index, show, new, create actions it will tell you to add the :only directive to your route mapping for those actions.
There might be some additional options out there that are more inline with what you need, I recommend taking a look at the Ruby Toolbox's code metrics category and seeing what's out there. Here's the link: https://www.ruby-toolbox.com/categories/code_metrics
Related
I want to make a vertical line going through the middle of the site and then have content on either side. How can I use CSS or ruby? to do this? I am not sure which one I would need and where I would put it. Also, what is the best resource for learning the syntax of the ruby on rails views/CSS stuff. It seems that rubyonrails.org doesn't have much documentation on that (they mostly explain the models and controllers)
I would suggest you start with something like: https://github.com/softmachine/rails-bootstrap
They provide a link to http://twitter.github.com/bootstrap/ which has plenty of documentation.
The next step, would be to ask a more specific question related to the exact problem you're having.
From your description it sounds like you need css, and depending on the nature of of the information you want to display, you might need to use ruby/rails to make it happen. Most likely, you could just use css.
see: http://jsfiddle.net/aTUq8/
using the railties patch described in this post: slow rails stack, i'm noticing that the step "set_routes_reloader" is regularly taking upwards of 3 seconds.
is this expected? if not, what might i be doing wrong and/or how do i go about figuring out if i'm doing something wrong, etc.
In our case the problem was that we were defining too many routes. The set_routes_reloader step loads your routes (as you might guess). We got a lot of mileage by adding the appropriate :except/:only arguments.
Something that may help you is the traceroute gem which provides you a list of routes that do not have an associated controller action. I wrote a one-time script to process our traceroute output and update our routes.rb file. You can find it here.
I am using datamapper in a Sinatra application. I currently use the command
DataMapper.finalize.auto_upgrade!
to handle the migrations. I had two Classes (Artists and Events) with a 'has_n' and 'belongs_to' association. An Event 'belonged_to' one Artist and an Artist could have many Events associated with it.
I changed the association to be a many_to_many relationship by deleting the previous parts of the class definition which governed the original one_to_many association in the models and adding
has n, :artists, :through => Resource
to the Event class and the corresponding code to the Artist class. When I make a new Event, an error is kicked off.
#<DataObjects::IntegrityError: events.artist_id may not be NULL
The :artist_id field is a relic of the original association between the two classes. The new many_to_many association is accessed by event.artists[i] (where 'i' is just an integer index going from 0 to the number of associated artists -1). Apparently the original association method between the Artist and Event classes is still there? My guess is the solution to this is to not just use the auto_upgrade method built into datamapper but rather to write an explicit migration. If there is a way to handle this type of change to a database and still have the auto_upgrade method work, that would be great!
If you need more details about my models or anything please ask and I'll gladly add them.
In my experience, DataMapper's auto_upgrade does not work very well -- or, to say the least, it doesn't work the way I expect it to. If you want to add a new column to your model, it will do what it should; try to do anything more sophisticated to a column and it probably won't behave as you expect.
For example, if you create a property of type String, it will initially have a length of 50 characters. If you notice that 50 characters is not enough to hold your string, adding :length => 100 to the model won't be enough to make auto_upgrade change the column's width.
It seems you have stumbled upon another shortcoming, although one may argue that, in your case, maybe DataMapper's behavior isn't that bad (think of legacy databases). But the fact is that, when you changed the association, the Event's artist_id column wasn't removed, and then when you try to save an Event, you'll get an error because the database says it is a required field.
Notice that the error you are getting is not a validation error: DataMapper thinks everything looks ok, but gets an error from the database when trying to save the object.
Hope this helps!
Auto-upgrade is not a shortcoming at all! I think of auto-upgrade as a convenience feature of DataMapper. It's only intended purpose is to add columns for you as far as I know. So it is great for getting a project started quickly, and managing test and dev environments without having to write migrations, but not the best tool for making modifications to a mature, live project.
For that, DataMapper does have migrations! Use the dm-migrations gem. The shortcoming is that they are not very well documented... at all. I'm actually working on changing a current project of mine over to using migrations, and I hope to contribute some instructions to the dm-migrations github wiki. But if you aren't ready to switch to migrations, you can also just update columns manually using an SQL client, and then continue to use auto-upgrade for new columns. That's what I have been doing for 2 years on my project :)
This is probably a very obvious question but I can't quite figure it out. Is there such a thing in rails as a field, or model filter? Something similar to the concept of a before_filter in controllers. In my situation, we have "time" information from a form that needs to be formatted and verified before being set. Instead of simply applying a validator on the field and returning an error, I would like to make it as user friendly as possible and make an attempt to properly format the data. For example, it would be nice to put in my model something like:
before_filter :formatTimeField, :only=>[:timeField1, :timeField2...etc]
As it is right now, I need to specify mutators for each of these fields, and this seems a little silly to me.
Any ideas? Please let me know if I've left out some crucial information. Thanks in advance!
Check out the documentation for before_validation and the rest of the ActiveRecord callbacks. There are a bunch of calls that get made at various stages in the record creation/modification process:
http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html
In the case you describe, you could call a before_validation method to try and fix the user's inputs and then validate on that modified data. Thus, if you still can't do anything, you can kick it back to the user for correction.
Also, the RoR Guide has a comprehensive overview of the different hooks: http://guides.rubyonrails.org/active_record_validations_callbacks.html#callbacks-overview.
Hope this helps.
In the app I'm working on, Courses have many Problems, which in turn have many Steps. Right now there is a form for adding Problems to Courses (and then Steps can be added to those problems). What we want is to have a form that just has a field for LaTeX input, and then process the TeX to create multiple problems with their steps.
At the moment, we're doing this all in the Problems controller. We have two methods, texnew which is identical to new except it has a different view that redirects to the other new method: texcreate, which uses helper methods to extract the problems and steps (using a series of regexes), tries to create them, and flashes somewhat informative error messages if something goes wrong.
The thing is, I keep on reading that we're really not supposed to be doing a bunch of stuff in the controller, and we should favor doing things in the model instead. Virtual attributes might be the right idea for taking in a text field and processing it to create a single problem, but I can't figure out how to make it work for multiple problems, or how to generate any sort of error messages if something goes wrong somewhere along the way.
Is there some better/more idiomatic way to do this?
You don't really need virtual attributes for this if all your relationships are setup properly. You can use the new rails3 nested attributes. There is a good article on them here. This will allow you to rely more on model validation logic and keep the lean controller fat model idiom that rails encourages.