I'm really new at this and I don't want to mess up my current application. I'm currently working on HTML/CSS stuff but I have a little understanding as to how to get things working.
I created a new controller by just doing
rails generate controller sign_up
I've created a index file (index.html.erb) inside sign_up folder from rails that automatically generated. Now I wanted to add more files, can I just add more files by typing in
rails generate controller sign_up send_page more_page other_pages
Will send_page, more_page, other_pages be automatically combined into the existing sign_up folder? Is this the correct way of adding pages if I want rails to add other files automatically? I just want it to ruin what I have so far so I don't want to try it for myself because I'm still really new to this,
Thanks!
To answer your question :
New files will be added to the existing folder but existing files will not be merged, you'll have to resolve the conflict by choosing between old and new files.
It seems to me you're trying to use generators for every action you need in your app :
Scaffolding is great to have a sample structure, but as soon as you start building your controller for real you need to move away from it : extend the controllers, models and views by hand. It's the only way you'll start to really understand how things are working.
If you run the generator again, it's going to complain about conflicts with existing files. Then you'll have to choose to overwrite (losing your existing changes to e.g. the controller), or not (in which case you won't get the new auto-generated methods, etc.).
You can just create a new controller action and a new view for each additional page you want to add (and a unit test, of course!). If you're using non-standard/non-restful action names, you'll also have to edit config/routes.rb to route them.
Looking at the names in your example, and your reference to "pages", I suspect what you really may want to do is create separate controllers for send_page and more_page. If that's the case, you'd run the generator separately for each new controller.
Related
Where is the best place to add a new view to a Rails app?
I have three main controllers and then the Application controller. I folders in views for the three controllers. I want to add a homepage view to my application, separated from the other views. Where would be the best place to add it? Should I make a new folder in views and add a homepage there? Can I add it as part of the application controller?
If you want to have Rails work consistently and easily, it's best to follow the Rails conventions. So, the views for a particular controller would go into the app/views directory, in a subdirectory named for the particular controller. So, the view for your pages_controller would go into app/views/pages - and you'd have a view named for each relevant action in your controller (show.html.erb, for example).
Generally, Rails operates by "convention over configuration". So, if you follow the conventions, you'll find everything works nice and smooth. If you try to create your own conventions, at some point it will bite you and things will stop working.
So, the basic question is: which controller will render your new home-page view? I'm guessing probably static_pages_controller or similar. In which case, the view would go into app/views/static_pages.
If you don't have a controller then Rails won't render the view at all.
What's the best way to edit and format page views using Irwi Wiki in Rails?
Here is the controller it's set up for me:
class WikiPagesController < ApplicationController
acts_as_wiki_pages_controller
end
Though there's no views folder corresponding to the controller. I just want to be able to edit the html or add css to the wiki articles I can create now.
https://github.com/alno/irwi
As it says in the docs:
You may create your own templates for controller actions (show, edit and history), in other case default built-in templates will be used.
So, in your views folder, create a folder called wiki_pages and then put your new templates in that folder.
Here's what's going on:
When your WikiPagesController currently goes to render a wiki page, it looks for a template in apps/views/wiki_page corresponding to the current action. That folder/file doesn't exist, so it looks in other directories and ultimately finds the template in the gem. (You should be able to see this process in your console.)
When you create the folder and add the template (as above), the WikiPagesController finds the template in your application and renders that, instead of rendering the template provided by the gem.
So I have done a little research and I think you can just copy all files from here: https://github.com/alno/irwi/tree/master/app/views/base_wiki_pages into views/wiki_pages folder so you will have all views locally and you will be able to edit them.
I'm making a gem that will add some custom responders to an application's controllers. To test this, I'm going to need a dummy application sitting inside of a test directory that I can load and somehow generate views from.
I'd prefer to use Cucumber to test this gem, because that is what I'm most comfortable with having used it in the past.
How do I generate an application inside of my test directory like this? I will need at least a controller and a model, but views aren't necessary (the responder is only for JSON). Can I just generate a new Rails app within /features/support/dummy? How would I run the dummy application from within my test suite?
At first, do not generate anything within features/support/. That's the place for global hooks.
Your problem sounds not hard if I understood correctly. Here is my proposed steps.
Create a demo directory in project root. New demo app will be under it.
Create a ruby module/class under features/support/, with methods to generate a demo app and delete it. The demo app will be simply some directories like app/contorllers for test purpose. Making a whole new Rails app sounds overkill.
Create a tag for the Scenario which need generate app. Add Before and After hook for this tag to add and remove app for this Scenario, by calling the module/class in #2
I am developing Rails plugin (it is 3.1 Engine) called Carrier (https://github.com/stanislaw/carrier).
In one of my rails app I want to extend Carrier's controller with some new methods - fx. add new action #comment_form to Carrier::MessagesController (I want this action only exist in my app - I don't want to add it in Engine - because it is very specific).
Two strategies I see here:
1) I copy {Carrier's plugin root}/app/controllers/carrier/messages_controller.rb file to app/controllers/carrier/ folder of my app, and then extend it (all plugin's original actions are copied to rails app controllers folder too!).
2) More accurate way I want - is just to create {My rails app}/app/controllers/carrier/messages_controller.rb and write only #comment_form method I want Carrier to be extended with.
Expecting that two controllers's content (original from plugin's folder + custom in my rails app having only new #comment_form) will superpose, I tried the second way. But Rails then stopped recognizing all original Carrier's actions (#index, #show, etc...) written in messages_controller.rb from the Carrier plugin's folder and began treating rails app's messages_controller.rb version as the only one (all original actions began treated as empty and thus began rendered through rails conventions default flow).
So my question in general is:
How to add new actions to Rails Engines controllers without copying them entirely to Rails app/controllers folder?
UPD
For now I see two solutions which allow extension of engine's controllers without serious hacks (like this gem does: https://github.com/asee/mixable_engines from this thread: Extending controllers of a Rails 3 Engine in the main app)
1) load YourEngine::Engine.config.root + 'app' + 'controllers' + 'your_controller'
inside your_controller.rb that is in #{main_app}/app/controller/your_engine folder. Notice load instead of require.
2) Devise way (according to some SO topics suggest):
In main app create new controller that subclasses engine's one + edit routes to they point to this new controller.
I am still sure some even better solutions exist. Please correct me if they do!
Your option 2) is fine because it will let you upgrade the gem seamlessly.
Your current way simply overrides the existing controller.
Say you want to extend FooController.
Create a file named foo_controller_decorator.rb in your initializer folder
In the file:
FooController.class_eval do
#your additionnal code here.
end
I know this is a very old question but in case someone else finds this question, here is a gem that does decorators nicely. It hooks into Rails ActiveSupport and adds a convention to doing decorators that is safe from circular dependencies. We have been using it in production on multiple apps for a while.
https://github.com/EPI-USE-Labs/activesupport-decorators
I'm a happy user of RoR but have one complaint. When I do script/generate scaffold it automatically generates all my files and places them in their proper folders. However, all the different scaffolds I've created name their view files the same.
I have a bunch of index.html.erb view files and when I have them open in my text editor, it's almost impossible to tell what controller they're related to.
I'd like to change the default naming scheme of the scaffold command to name the individual files to contain their view folder name. So, instead of index.html.erb, use index.home.html.
Is there a way to do this, or am I stuck? What solutions to the multiple files with the same name problem have you Rails developers discovered?
Thanks!
You're going to be fighting the Rails' conventions by going down that path and Rails works best when you work with it rather than against it. A core part of the philosophy of Rails is that there are a set of conventions that once learned make it easy to find your way around any Rails application.
Instead of trying to redefine how Rails works, I would recommend taking advantage of the features offered by your text editor or IDE for quickly navigating to the correct view template. For example, the Rails bundle within TextMate on the Mac lets you quickly open the view file associated with a particular model and there's a plugin for Vim that provides an equivalent feature.