CSS files for Rails Controllers
Whilst working on various different projects using CSS frameworks such as SASS, 960 Grid System and Blueprint I have found overriding with specific files per controller to be a much cleaner process.
Note: I think Rails 3.1 actually does this out of the box
Obviously it is not always necessary to create a new css file for every controller so I needed a way to include the file if it exists. This saves on unwanted entries in log files for file cannot be found when we kind of know that already.
So what I did was add a before filter to the application controller.
class ApplicationController < ActionController::Base
…
before_filter :controller_styles
private
def controller_styles
@all_styles = Array.new
@all_styles = [“reset”, “960”, “layout”, “nav”, “text”]
controller_style = File.join(Rails.root, “public/stylesheets/”, “#{request.parameters[:controller]}.css”)
if File.exist?(controller_style)
@all_styles.push(request.parameters[:controller].to_s)
end
end
end
What this simple code does is call the method at the start of every request. The method then creates an array with the default css files already included.
A lookup is then made in the stylesheet directory for a css file with the same name as the requesting controller. If it exists, push it on to the end of the array. If it doesn’t, don’t.
Then in the main layout.html.erb view file, include:
<%= stylesheet_link_tag @all_styles %>
into the head of the html and you have the option to override your CSS in a clean structured manor.
Simples!
TCPServer Error: Address already in use error
This little error has been popping up occasionally in my local rails development environment using the WEBrick server.
I generally just use the default 0.0.0.0 ip address with a different port assigned to it depending on the app I am running. There may be a better way of running local development servers that I don’t know about but this has always been quick and flexible enough for my uses.
As default, when starting WEBrick, the server attempts to bind to port 3000. If you have already got another app running on 0.0.0.0:3000 the following error will rear it’s head.
=> Booting WEBrick=> Rails 3.0.0 application starting in development onhttp://0.0.0.0:3000=> Call with -d to detach=> Ctrl-C to shutdown server[2010-09-12 15:34:34] INFO WEBrick 1.3.107[2010-09-12 15:34:34] INFO ruby 1.9.2 (2010-08-18) [x86_64-darwin10.4.0]08[2010-09-12 15:34:34] WARN TCPServer Error: Address alreadyin use - bind(2)Exiting10/Users/eford/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/webrick/utils.rb:73:in `initialize': Address already in use - bind(2) (Errno::EADDRINUSE)
Two options are available that will either fix the issue or just get around it.
WEBrick allows the port bind to be defined when start by passing the port number through the start command:
rails s -p=3001
To reuse the default server setting, you wil first need to need to free the address by killing the process.
On a Mac, use the terminal window to view the processes
ps aux | grep rails
You should see something like
eford 14290 …. /Users/eford/.rvm/rubies/ruby-1.9.2-p0/bin/ruby script/rails s
Depending on your setup, the path will be different but it is the .ruby script/rails s to look for. Kill the process using kill -9 <pid>. The -9 will stop the process without question
Once stopped, try starting the server again with rails s
rails s=> Booting WEBrick=> Rails 3.0.0 application starting in development on http://0.0.0.0:3000=> Call with -d to detach=> Ctrl-C to shutdown server[2010-09-12 15:42:11] INFO WEBrick 1.3.17[2010-09-12 15:42:11] INFO ruby 1.9.2 (2010-08-18) [x86_64-darwin10.4.0][2010-09-12 15:42:11] INFO WEBrick::HTTPServer#start: pid=14290 port=30009=> Booting WEBrick=> Rails 3.0.0 application starting indevelopment on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server[2010-09-12 15:42:11] INFO WEBrick 1.3.1[2010-09-12 15:42:11] INFO ruby 1.9.2 (2010-08-18) [x86_64-darwin10.4.0][2010-09-12 15:42:11] INFO WEBrick::HTTPServer#start: pid=14290 port=3000
Try 0.0.0.0:3000 in your browser now and you should have your app
Sass Highlighting In Dreamweaver 5.5
I have just spent a good while trying to get highlighting to work in Dreamweaver for SASS.
Various guides show to change Extensions.txt and MMDocumentTypes.xml configuration files as on http://kb2.adobe.com/cps/164/tn_16410.html.
The explanations are all correct but if you are using Dreamweaver 5.5, save some hair pulling and edit the above files in your User Profile AppData / Support.
A good explanation can be seen at http://forums.adobe.com/thread/861133
I really like this piece - Yun Byoung Chul PENE MENN
A really cold, emotional work
Source: theartofanimation
Having some wine with my favourite lady in the world
I’ll tell you what’s not fit for purpose… Chicken’s wings!
Zend Cache Error – Silverstripe 2.4 admin
After uploading a new site built on Silverstripe 2.4 to my shared host, the following error reared it’s head when trying to access the admin area. [User Error] Uncaught Zend_Cache_Exception: cache_dir is not writable After some searching through the Silvstripe forums, I finally ended up at finding a resolved support ticket that showed an easy solution in the mysite/_config.php. First, check the silverstripe-cache folder exists in your site’s root directory, and ensure it is writable. Then add the following line anywhere in your _config.php file. Finally revisit your admin with flushed cache (/admin?flush=1) This fix worked fine for me but I have seen it hasn’t worked for others. A last case solution for those that need a quick fix would be to edit the cache directory in /sapphire/thirdparty/Zend/Cache/Backend/File.php. Change: The file is part of the Sapphire core so this solution is not advised as a long term fix, and could quick easily be overwritten in future updates.$_SERVER['TMPDIR'] = '/absolute_path_to_your_cache_foler/silverstripe-cache';
protected $_options = array(
'cache_dir' => 'CHANGE_TO_CACHE_DIR',
'file_locking' => true,
'read_control' => true,
'read_control_type' => 'crc32',
'hashed_directory_level' => 0,
'hashed_directory_umask' => 0700,
'file_name_prefix' => 'zend_cache',
'cache_file_umask' => 0600,
'metadatas_array_max_size' => 100
);
Allowed memory size error in Silverstripe
Silverstripe have made great improvements in the memory consumption in version 2.4 but the admin area can still get the frustrating error message. Fatal error: Allowed memory size of 268435456 bytes exhausted There are a few options to fix the issue: Personally, I have found the 2nd option to be the best and most reliable throughout the website. Some shared hosts lock down the options to increase memory limits so some digging around the support docs might be required if the above don’t work.
