In my Rails 3.1 app. Ive got a few controller's calling this block of code:
twitter_entertainment_users = Rails.cache.fetch('twitter_entertainment_users', :expires_in => 24.hours) do
begin
Timeout.timeout(10.seconds) do
Twitter.suggestions('entertainment')
puts "#{Twitter.rate_limit_status.remaining_hits.to_s} Twitter API request(s) remaining this hour"
end
rescue Twitter::NotFound
end
end
Instead of re-typing this block of code everywhere. Should I have this in a module instead? i.e. to keep things DRY?
If so, where should this go? I read somewhere about putting module code in app/concerns/foobar.rb.
Any other approach? Looking for suggestions / articles.
it's always better not to repeat your code. That way when you change something, you only have to do it in one place. (And believe me - you don't want to do it five times over and then just hope you didn't miss anything.)
Put it somewhere where all the controllers can access it. Consider making a module (or a folder) for all the helper methods you might need and keep them in one place. That way you always know where to look.
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 find, even when assigning the decorator #singleton(false) to the view-model, that while the view-model does then persist as a singleton across activation/deactivation, the bindings and components, etc do not.
(I assume this is because they are stored in a container that is disposed on deactivation.)
The result is that upon every deactivation/activation of a view with a singleton view-model, the view is un-bound and then re-bound.
Is it possible to cause the bindings to persist across deactivation/activation?
This one stumped me for a good while. It also confused me as to why implementing it was not a higher priority for the Aurelia Team.
This takes a fair amount of code to get working. I have put the code in a Gist here: https://gist.github.com/Vaccano/1e862b9318f4f0a9a8e1176ff4fb727e
All the files are new ones except the last, which is a modification to your main.ts file. Also, all my code is in Typescript. If you are using Javascript you will have to translate it.
The basic idea behind it is that you cache the view and the view model. And your replace the router with a caching router. So when the user navigates back to your page, it checks first to see if there is a view/view model already created and uses that instead of making a new one.
NOTE: This is not "component" level code. That means I have tested that this works for the scenario that I use it for.
I got my start for making this change here: https://github.com/aurelia/router/issues/173 There is another user (Scapal) made something that works for him and posted it there. If what I am posting does not work for you, his may help you out.
i'm also interested in an answer to this.
maybe i'm now making a complete fool out of me but why not use aurelia-history navigate(..) command?
I am trying to trim the leading "the" in a query that returns the titles of articles in Joomla, so that results are displayed in alphabetical order and the leading "the", if present, is disregarded. The module responsible for this is the Article Category (which is Joomla core module) and the file I think I should modify is helper.php in modules/mod_articles_category.
I replace the following line:
$articles->setState('list.direction', $params->get('article_ordering_direction',
'ASC'));
With this:
$articles->setState('list.direction', $params->get('article_ordering_direction',
'TRIM(LEADING \'THE \' FROM a.title) ASC'));
However, if I enable the debug mode, the TRIM is not showing. SO I guess, that I need to make the change somewhere else. Sorry but I am not familiar with Joomla so don't really know where this query is coming from. Any pointer is very much appreciated.
Okay, the short answer is no, I don't believe you can modify a query from a module, just like this. I haven't worked with modules, but I have some experience with components, so I would suggest two approaches:
Try to query the database yourself from the module, not by using setState, but building the query yourself.
You can cheat. Since Joomla has already done the heavy lifting for you, you could just manipulate the result object (i.e. $list) rearranging it and stripping off whatever you don't want. I would also suggest that you treat your code as a layout override, that way you'll be able to update your site without overriding the changes you have made.
I have started an application in YII, I want to use proper standards of YII but am just bit curious about the use of its CHTML Class. I think that using CHtml::link() or CHtml::image() instead of normal HTML code <a></a> and <img src... /> will cost more time to application on server side. I tried to look for some reason to use it but yet not success in finding any good resource on why should I use it and how its beneficial then traditional HTML. Like I can use all those methods for defining paths to actions in normal HTML code then why use it
any help or reference for clarification would be appreciated
Thanks
Let's talk about CHtml::link(). Its main advantage is that you can indicate a controller route and send some get variables by simply passing an array as paramater. Lets say you wanna go to the eat() action of your LivingController, with the variable 'meal' and its value being 'hamburgers'. It could simply be done like this:
> CHtml::link(array('LivingController/eat', 'meal'=>'hamburgers'));
If you want to express this using <a></a> only, then I don't need to tell you how much harder it would be. In addition, we should remember that a link generated using CHtml::link() will always work, even if you change the url format. That wouldn't happen with <a></a>: you would have to rewrite the url every time you change the url format.
The advantages of CHtml::image() are less clear, at least to me. Sincerely, I think it's just a matter of encapsulation.
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