I am a beginner in learning Ruby and Rails.
I was going through the following section on Rails 3.2.1 Guide:
http://guides.rubyonrails.org/routing.html#paths-and-urls
which says:
Creating a resourceful route will also expose a number of helpers to the controllers
in your application. In the case of resources :photos:
photos_path returns /photos
new_photo_path returns /photos/new
edit_photo_path(:id) returns /photos/:id/edit (for instance, edit_photo_path(10) returns /photos/10/edit)
photo_path(:id) returns /photos/:id (for instance, photo_path(10) returns /photos/10)
I am curious to know how and when in the lifecycle of a request are these helpers, i.e. new_photo_path, edit_photo_path etc created and where in the source code I can found the code doing the same.
I was navigating through the code in the following file /gems/actionpack-3.2.1/lib/action_dispatch/routing/mapper.rb and I guess the code in this file is creating the above helpers.Please correct me if I am wrong.
Thanks,
Jignesh
Essentially, yes, that is correct. For more information, you should check out the Routing Walkthrough series that Ryan Bates did last September, where he walks through some of the Rails code that controls routing.
If you use the generators (e.g. rails g controller NewController) the helpers are automatically created and places in ./app/helpers with similar nomenclature. If you are doing the controllers by hand then you would need to create your own, e.g. new_helper. By default though all controllers load application_helper.rb.
If you are not going to use a helper method in more than one controller/view it is best to put it in its own helper file. This guide may help explain it more.
Update
The helper methods are written by you based on your needs. The code for the helper generator can be found here
Related
We are currently using Ruby 1.9.3, Rails 3.1 (i know, we're working hard to upgrade all our applications).
We're using a module (let's call it 'OurModule' to add a method (let's call it 'OurAddOnMethod' to a model defined in a gem (let'd call that 'GemModel'). We have that module file living in the 'config/initializers' directory.
That file defines the module, and then calls this to include it in the model:
# Include the extension
GemModel.send(:include, OurModule)
When developing, things work well mostly, but periodically we will get an error that basically says "Undefined method 'OurAddOnMethod' in 'GemModel'". Restarting the server resolves the issue (for a while).
I'm assuming this is happening because the models are reloaded periodically with changes made in the development environment, and it appears that the initializers do not also get reloaded at that time..? It seems like this may not be the best way to set things up; it is quite frustrating to deal with.
Can anyone enlighten me on a better way to achieve this?
I ended up using wrapping the code in the following, and keeping it in initializers:
ActionDispatch::Callbacks.to_prepare do
# configure stuff or initialize
end
I feel really bad, i completely missed this question that seems to completely cover mine (linking to the answer that i used):
https://stackoverflow.com/a/8636163/287516
I want to create a simple module for my Moodle but it takes so much time. Is there any template that I can just optionally change it and make it how I want?
I'm not aware of a boilerplate block template for Moodle, however there is a pretty decent walkthrough on the Moodle Docs page for blocks:
To define a "block" in Moodle, in the most basic case we need to provide just four PHP files. Remember, in this example we are creating a block called 'simplehtml', replace 'simplehtml' with the name of your custom block. The four files should be located in blocks/simplehtml and are:
https://docs.moodle.org/dev/Blocks#Ready.2C_Set.2C_Go.21
https://github.com/danielneis/moodle-block_newblock
Provides a good starting point.
You can start from simplehtml block contributed by moodle.
https://moodle.org/plugins/view/block_editablecontenthtml
You can find detailed dev explanation here:
https://docs.moodle.org/dev/Blocks
A simple question. Does this version support generators?
I wanted to test out using it and follow along with Ryan Bates screen cast which I uses a different version.
I've been playing with tables today and want to see how this works using the generator with a scaffold generated model and all its components.
Running rails g bootstrap:themed returns
Could not find generator bootstrap:themed
So I tried to reinstall with rails g install:bootstrap
Error similar which lead me to try to find if it supports these commands.
Thanks
It doesn't need generators for asset files, since we hook into the asset pipeline through the use of a Rails Engine - configuration options are available through the use of variables (use this as a reference, Sass variables are actually $x rather than #x and need to be defined before importing bootstrap), Sass' #extend, and Bootstrap's #makeRow and #makeColumn mixins, along with the other Bootstrap mixins.
Themed scaffold would be interesting but generally would be a pain to maintain - view scaffolding tends to get ripped apart pretty quickly anyway. Perhaps a 'sane' application.html.erb layout generator could be useful.
So yeah, we currently have no generators, don't need an asset one, themed scaffold probably not coming soon unless someone is interested enough to do the work on it, potentially a layout generator in the pipeline.
Checkout
https://github.com/decioferreira/bootstrap-generators
Seems to be what you are asking for.
-Rick
So I have a Rails 3.0 Engine (gem).
It provides a controller at app/controllers/advanced_controller.rb, and a corresonding helper at app/helpers/advanced_helper.rb. (And some views of course).
So far so good, the controller/helper/views are just automatically available in the application using the gem, great.
But I want to let the local application selective over-ride helper methods from AdvancedHelper in the engine (and ideally be able to call 'super'). That's a pretty reasonable thing to want to allow, right, a perfectly reasonable (and I'd think common) design?
Problem is, I can't seem to find any way to make it work. If the application defines it's own app/helpers/advanced_helper.rb (AdvancedHelper), then the one from the engine never gets loaded at all -- so that would work if you wanted to replace ALL the helper methods in there (without calling super), but not if you just want to over-ride one.
So that kind of makes sense actually, so I pick a different name. Let's call my local one ./app/helpers/local_advanced_helper.rb (LocalAdvancedHelper). This helper DOES get loaded, if I put a method in there that wasn't in the original engine's AdvancedHelper, it is available to views.
But if I put a method in there with the same name as one in the engine's AdvancedHelper... my local one NEVER gets called. It's like the AdvancedHelper (from engine) is earlier in the call chain than the LocalAdvancedHelper (from app). Indeed, if I turn on the debugger, and look at helpers.ancestors, that's exactly what's going on, they're in the reverse order I'd want in the ancestor chain. So AdvancedHelper (from engine) could theoretically call 'super' to call up to LocalAdvancedHelper (from app) -- but that of course wouldn't make a lot of sense to do, you'd never want to do that.
But what I would want to do... I can't do.
Anyone have any ideas, is there any way to provide this design, which seems perfectly reasonable to me, where an app can selectively over-ride a helper method from an Engine?
Anyone have any explanation of why it's working the way it is? I tried looking at actual Rails source code, but got lost pretty quick, the code around this stuff is awfully abstract split amongst a bunch of places.
This is pretty esoteric question, I'm pessimistic anyone will have any ideas, I hope you surprise me!
== Update
Okay, in order to understand what part of Rails code is being called where, I put a "def self.included ; debugger ; end" on each of my helpers, then in the debugger I can raise an exception to see a stack trace.
That still isnt' really helping me get to the bottom of it, the Rails code jumps all over the place and is pretty confusing.
But it's clear that a helper with the 'standard' name (ie WidgetHelper for WidgetController) is called by different rails code, to include in the 'master' view helper module for a given controller, than other helpers are. I'm wondering if I give the helper a different name, then manually include it in my controller with ("helper OtherNamedAdvancedHelper"), if that will change the load order.
We can use Module#class_eval to override.
In main app,
MountedEngineHelper.class_eval do
def advanced_helper
...
end
end
In this way other methods defined in engine helper are still available.
Thanks for your elaboration. I think this really is a problem. And it is still present in Rails 3.2.3, so I filed an issue.
The least-smelling workaround I came up with is to do a "half alias method chain":
module MountedEngineHelper
def advanced_helper
...
end
end
module MyHelper
def advanced_helper_with_extra_behavior
advanced_helper
extra_behavior
end
end
The obvious drawback is that you have to change your templates so that your helper is called. At least, you make the existence of extra behavior explicit there.
These release notes from Rails4 seem enticingly related to this problem, and potentially note it's been fixed:
http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#helpers-loading-order
I see that some of the examples included with ExtJS 4 start up via a single call to Ext.application(). Other examples, however, manually call Ext.Loader.setConfig(), Ext.require(), and Ext.onReady() instead. I want to make sure I understand the difference.
Am I correct in assuming that:
you'd normally use the convenient Ext.application() call for a full-screen (e.g., Viewport-based) app?
if you just want to use a few ExtJS components on a pre-existing "non-Ext" page you'd opt for the manual calls to Ext.Loader, require, and onReady()?
Thanks for the clarification!
The full application call is used for the Ext MVC approach, and comes with a set of conventions to pre-load additional components, for example the stores and views options in the controller classes. For a better explanation see the Ext documentation on MVC.
If you just need to throw a few components on the page, as you state, you will get better performance just using the loader, or better, avoiding dynamic loading (at least in production).