I have generated a few controllers and models to my app and now I want to add testing (I know it's a little backwards but at least I am starting fairly early in my project). Anyway, every time I generated a controller/model I did not include the --no-test-framework so now I have a bunch of specs related to controllers, helpers, models, and views. Do I need these? And, if not, is it okay to just delete them? I am noticing from some tutorials (Hartl, Bates) that they are using request specs, are these all I need?
Thanks!
Related
I just inherited a RoR 3.2 app and am trying to get it working on 4.2
I am going to put on my sarcastic hat for a second, just so I can feel better. Instead of having a single line in a single file to protect specific fields from mass-assignment, "Strong" Parameters requires bloating up controllers and heaven help you if a controller uses multiple models or a model is used by multiple controllers or need nested attribute whitelisting. This is the exact opposite of DRY and KISS.
That is better. Okay, so the question is, besides getting rid of mass assignment completely, which is sounding really good right about now, is there a sane way to use it or get around it. From what I understand that gem that brings back attr_accessible won't work in Rails 5 which is where this app is heading.
I understand the Ruby object model and can make a ton of modules that controllers can mixin, but that is just ugly and still error prone.
Any advice or hints would be welcome.
Why is that every new Rails feature involves more boilerplate spread over multiple files? If I wanted Java, I know where to find it. The stupidity of getting rid of the powerful and clean link_to_function in favor of using a tangled mess of callbacks almost made me quit, but adding that function back is trivial. Hopefully when the client wants the inevitable upgrade to Rails 5 I can talk him into something more sane and move things bit by bit to a sane web framework.
What you're after is "form objects". There's a great railscast episode on them. You may also be interested in the reform gem
Edit: looks like there's a free version of that railscast episode on youtube: https://www.youtube.com/watch?v=SvL_aZt3zyU
I am currently developing a web project using Yii framework. I'm wondering where is a good place to put all the business logic, in the Controllers, or Models(models here as in mappings from database tables to actual objects)? Both doesn't seem right. I think I might need an extra "asset" layer in between controller and models, but I have no idea how to start. Any suggestions?
Generally the suggestion is to go about using Fat Models and Thin Controllers. So business logic in your model. It makes it far easier to make your code re-useable.
More info here:
http://www.yiiframework.com/doc/guide/1.1/en/basics.best-practices
If you've got a lot of custom logic, you could potentially have an "asset" layer of additional models that handled your DB models. Depends on your specific system though … I'm finding I do use CFormModel objects this way at times to map from a form with a bunch of different models to the models as needed.
As an exercise, I intend to replace all front-facing aspects of my Rails application with Backbone.js. Part of the plan includes redesigning everything right down to the CSS.
The issue I'm struggling with is in delegating responsibility for templates and views.
Is there any benefit to implementing the new front-end entirely in Backbone, hence only using Rails as an API?
How do I strike the right balance between Rails and Backbone when it comes to handling the HTML elements of the application?
Since it seems that nobody is going to post an answer to this I'll offer my two cents as just one point of view (I've written elsewhere about the issue of how to get rails and backbone.js to work well together: rails and backbone working together).
Most people in this situation will tend to drop the rails views altogether and migrate everything to backbone.js.
This is what I've done in a project that I'm working on right now.
This is the natural course of events, and particularly once you start getting used to all the complex interesting things you can do with backbone.js and structured javascript, it becomes difficult to turn back and implement standard stateless HTML pages.
As I mentioned in my other answer linked to above; however, there are costs to completely abandoning HTML views and the stateless layer. In my case, I intend to add back pure HTML pages for non-js-enabled browsers for GET requests only once the app has reached a certain level of functionality. We won't support POST or PUT requests unless the user has javascript enabled (or unless they want to go through the JSON API).
That's the balance I've struck: stateless HTML (no-JS) for accessing data, but JS required for posting/changing data. Your choice will vary depending on your use case and target user.
The other thing that I would mention is that if you have been working with rails HTML views on a project for some time, you might be unprepared for the initial overhead required to switch to backbone.js. This is not simply swapping HAML for ERB: you are migrating from a stateless front-end to a stateful one, and that is a potentially huge change (depending on the complexity of the app). I myself was a bit unprepared for the depth of that change, and had to do a lot of catching up before getting our app back on track after making the switch. And we made the switch very early, with minimal functionality already in-place.
Anyway just a few thoughts, hope they help.
Why controllers are named "users_controller.rb" and models are not named "user_model.rb"?
Why there is "application_controller.rb" but inside views the folder "layout" is not named "application"?
Code flows from thought best when the naming supports the developers internal model of the problem. When building an application, I don't think of finding a user model (UserModel.find) I think of finding a user (User.find). On the other hand, the controllers are the translation layer between the web interface and the data store (and business logic), so it makes more sense to call them something different.
There's also the problem of namespacing; if both my model and controller are named User, then which User am I referring to at any given moment? In this case, either you name everything with their type, which runs into the problem I describe above, or one 'wins' and is allowed to be referenced 'bare'. It seems to make the most sense that the model would win, so as to provide a better mental mapping.
Inside app/views/layout is application.html.erb and you can have other layouts which are selected by different controllers.
In the end, however, these were choices made during the development of Rails, and they are entirely stylistic choices based on what the developers thought made the most sense, so there isn't really a 'right' answer to your question, unfortunately. In fact, some similar decisions have been revisited. (application_controller.rb used to just be named application.rb.)
Ruby on Rails follows "Convention over configuration" principle. Particularly naming conventions are extensively used by Rails while mapping your routes to controllers, auto-loading and reloading classes, finding appropriate template for an action and many other features.
That principle leads to some restrictions as you can't easily break some of the conventions without getting into troubles. But on the other hand it makes our lives easier as we get smaller amount of configuration and can easily move from one Rails project to the other because all of them have similar structure and follow same conventions. In addition, I believe, that makes Rails core development much easier as core team have a lot of information about how the project using Rails will be structured and they don't have to worry that much about generalization. They simply assume you play by the rules and follow conventions.
Though, I doubt many of naming conventions have serious reasoning behind them. I think at some point someone just decided that it'd be easier for Rails to handle your controllers and distinguish them from other classes if they all have Controller suffix. And here we are having all our controllers in app/controllers directory with that suffix.
I have 2 applications that are going to be built (possibly a 3rd API), all are going to use the same database. What is the best way to use the same models across all applications.
Also, what are some of the caveats you have experienced or foresee with this method. Looking for the best solution to this.
Rails, as opinionated software, prefers a single app, rather than shared models. I've tried it both ways. Are you going to just have copies of the models that can get out of sync? Are you still planning to use Rails' migrations? When you have multiple apps, migrations become difficult. Do you use just one app for migrations? Then you lose the ability to check in migrations along with the code it refers to. Automating builds can become very difficult. You can possibly find a way share migrations too, but that requires some source code management sleight-of-hand which ultimately makes it more difficult to do separate apps and still get everything Rails has to offer. At that point you may want to look into Sinatra.
On the other hand, there's a lot of organizing you can do in a single app that keeps the model domain shared, yet separates the controllers, such as using namespaces or engines. I'd recommend those techniques.