I wanted to generate a link to the current page being viewed, with some extra parameters, but couldn’t find an easy way just by browsing the docs. It turns out this is quite easy:

    link_to "My Link", url_for(my_params)

The url_for helper fills parameters like :controller and :action using the current request information, if they are not provided in my_params.

Thanks to:

http://stackoverflow.com/questions/2543576/rails-link-to-current-page-and-passing-parameters-to-it

def store_location
  session[:return_to] = request.request_uri
end

To this:

def store_location
  session[:return_to] = request.fullpath
end

Thanks to:

http://www.dixis.com/?p=352

http://iterat.ive.ly/index.php/2010/09/03/upgrading-your-authlogic-gem-for-rails3/

I wanted my web application to use messages in a language depending on the locale used by the web browser. According to the HTTP specification, browsers can send headers, in a request, to indicate preferred language, based on the user system.

At first I thought the framework would take care of this for me automatically, but that’s not the case (at least until this version). So we have to write some code to accomplish this.

First step is writing a CBehavior to set the application language during application startup. I created a file protected/components/StartupBehavior.php containing this:

<?php
class StartupBehavior extends CBehavior{
    public function attach($owner){
        $owner->attachEventHandler('onBeginRequest', array($this, 'beginRequest'));
    }

    public function beginRequest(CEvent $event){
        $language=Yii::app()->request->getPreferredLanguage();
        if ($language=='pt_br')
            $language='pt';
        Yii::app()->language=$language;
    }
}
?>

As you can see, the Yii framework already has a function to get the preferred language from the request headers, so we only have to set the language property in Yii::app().

Since I was building this application to work mainly to be accessed from Brazil, I had to change the language to ‘pt’ instead of ‘pt_br’ which is the value the browser would give me. I had to do this because Yii has no default message mappings to ‘pt_br’ (you can check the messages subdirectory in your framework installation to see if your language is already being mapped).

Now we need to load this CBehavior on startup. Just add the following to the array in protected/config/main.php

'behaviors'=>array(
    'onbeginRequest'=>array('class'=>'application.components.StartupBehavior'),
),

1) poll chrome.extension.getViews() (using setInterval or setTimeout) to check if the popup has closed.

2) Use the messaging APIs to set up a Port between the popup and background
page. You then should get a onDisconnect event in the background page when
the popup goes away.

3) Have the background dispatch events using chrome.extension.getViews() -
if there is a popup in the list, you use the DOMWindow handle to call a
function in the popup directly.

I’m currently using workaround number 2 above, proposed by Antony Sargent.

Thanks to:

http://groups.google.com/a/chromium.org/group/chromium-extensions/browse_thread/thread/cc6673d8e47a9bf4/06b9ab24ff5ac7e5?#06b9ab24ff5ac7e5

http://code.google.com/p/chromium/issues/detail?id=31262

I found out that Firefox 3.6 and Internet Explorer 8 implement an event called  ”onhashchange”, following the HTML 5 specifications. If you want to target other browsers, you have to do it yourself using timers or use history management javascript libraries (that probably will use the timer strategy).

Thanks to:

http://stackoverflow.com/questions/680785/on-window-location-hash-change

https://developer.mozilla.org/en/DOM/window.onhashchange

I was getting some UnsupportedClassVersionError when I tried running my application in Mac OS X. This error means I’m trying to use code compiled in a Java version not supported by my JVM.

To check Java version, I used “java – version” that told me I’m using Java 1.5. My code is compiled in JDK 1.6. So I tried to find out how to upgrade my JVM version to 1.6.

So, I found out that Java 6 is already installed, I just needed to run this command:

/Applications/Utilities/Java\ Preferences.app/Contents/MacOS/Java\ Preferences

and drag Java 6 to the first position.

Thanks to:

http://meus5cents.blogspot.com/2009/04/java-6-no-mac-os-x-leopard.html

To make text selection work inside XUL, I needed to use this (Mozilla) proprietary CSS style:

-moz-user-select: text;

Thanks to:

http://mattsnider.com/css/css-string-truncation-with-ellipsis/

Using ejabberd 2.1.x built from source code from Git repository.

I’m connecting to an ejabberd server using Smack XMPP client library. I am able to create new accounts on the XMPP server when the connection is not logged, just connected to the server. If I connect using an account, like admin, and I try to register a new account, it fails causing a forbidden (403) error on the ejabberd server.

Solution:

Just add the following configuration to ejabberd.cfg configuration file:

%% Put this in the section ACCESS RULES
{access, register_from, [{allow, admin}]}.

%% Change mod_register so it contains the new access rule:

{mod_register, [
          {access_from, register_from},
           ...
                    ] ...

Thanks to:

http://www.ejabberd.im/node/3914

Using Grails 1.2.2.

I created a Service and declared some methods like this:

def signUp = { arg1, arg2 ->
    //method body
}

This is a valid way to declare a method, where you simply assign a closure to class member variable, and it works the same way as a method declared the usual Java way.

To enable transactionsupport in my Service, all I have to do is add this line to the class:

boolean transactional = true

And it should work. The problem is: it didn’t work.

Solution:

What is wrong with the code above is that methods declared using closures don’t get the transactional behavior injected. I just changed it to this:

def signUp(arg1, arg2){
    //method body here
}

I could not find anything telling me that the closure declaration shouldn’t work, so I just assumed it would work, since Grails and Groovy developers have implemented some pretty smart default behavior for other features. Also, I was using the closure syntax a lot, because the books and articles I was reading use it a lot.

I was using Grails 1.1.1 and could not understand why my application was not throwing an Exception when I was inserting a record that clearly was violating some constraints (like unique indexes). I checked to see if the record was created, and it wasn’t, as expected. So, the problem was that GORM was not throwing an Exception when something goes wrong with the save() method call.

Solution:

I found out that not throwing an Exception in save() is the default behavior in GORM. But there is a parameter you can set to true on the save method called “failOnError”.

myDomainObject.save(failOnError:true)

But to make this work I needed to upgrade my Grails to the latest version, currently 1.2.2. Then it worked!

You can also change this default behavior putting the following setting in Config.groovy:

grails.gorm.failOnError=true

Thanks to:

http://www.brentbaxter.com/2010/03/10/grails-tip-using-failonerror-when-saving-domain-instances/

http://jira.codehaus.org/browse/GRAILS-4984