Responds_to_parent loc error

If the rjs inside your responds_to_parent block ended up removing the iframe from your html page, the loc variable will no longer be defined.

Besides having an ugly error message on your firebug console, it can actually cause problems for the javascripts on that page as well.

In order the get around this problem, you'll need to do the following patches:

in parent_selector_assertion.rb and responds_to_parent.rb

replace all occurrence of
(3 in parent_selector_assertion, 1 in responds_to_parent)

loc.replace('about:blank');

with
if (window.loc) { loc.replace('about:blank'); }

and that's it!


J

Ruby Exception Hiearchy

For those who wants a better understand of the exception hiearchy, here it is!

Exception
Errno
NoMemoryError
ScriptError
LoadError
NotImplementedError
SyntaxError
SignalException
Interrupt
StandardError
ArgumentError
IOError
EOFError
IndexError
LocalJumpError
NameError
NoMethodError
RangeError
FloatDomainError
RegexpError
RuntimeError
SecurityError
SystemCallError
SystemStackError
ThreadError
TypeError
ZeroDivisionError
SystemExit
SystemStackError

Cheers,

Joseph

the importance of .to_i

many times we'll use data fetched from a database in condition statements. And alot of times (at least I do) we'll assume data returned are numeric types of some kind because that's how it's specified in the database schema.

Big mistake!! .to_i should always be attached to numeric variables when used if you don't want little bugs creep out of nowhere.

One of my function acted all weird because I was comparing "1" with 1 :)

Another common place to make mistake is retrieving params variables, they will always return string values and it's up to you to convert them to your desired types.


J

Customized Logger

Rails framework comes with a logger for you to log activities on your application, which is pretty handy. However, there's a problem. Your development.log or production.log (depends on which environment you are running) comes with many other informations which makes is very difficult to locate your own logs.

In order to solve this issue, we'll create a custom logger which will extend the original logger and save our own logs on a seperate file.

Open environment.rb (the reason we put it there it's because you want it available as soon as your server boots up, so you can call it whenever you need it)

go to the very bottom and add the following lines:

class CustomLogger <>
end

YOUR_CUSTOM_LOG = CustomLogger.new("/path/to/your/log/file")

and you use it just like a regular logger:

YOUR_CUSTOM_LOG.info "GOT HERE"

something worth noting is that the variable that holds the CustomLogger object must be
a global variable, or else you won't be able to access it in your controllers or models.

another thing is that make sure you create the log file ahead of time, your server won't start if the log file you specified does not exist.

when everything is set, restart your server and test it out!


J

Debugging

So the debugging that comes packaged with RadRails is a little bit slow... well, not even a little bit slow, it's tremendously slow! I had run the debugger before, and I guess I was doing some simple debugging and so I didn't notice the time it took to start and debug (or maybe I just expected it to be slow?).

Anyways, I was running some new test cases and they were failing when they should have been working. So, I pulled out my trusty debugger, and lo and behold, it took so long that I left and came back about 5 minutes later and it was still running! I ended up stopping it, as my friend, J, had reported a similar problem earlier. He told me about some sort of fast-debugging gem. I quickly googled it and found a gem that works with RadRails.

Instructions can be found here:

http://www.aptana.com/docs/index.php/Fast_Rails_Debugging_using_Aptana_Rails_IDE

If you ever need to debug, a huge time-saving suggestion would be to install this gem and use it!


W