Send As SMS
Transcraft Blog
The choice of the IT professionals

Wednesday, March 15, 2006

I have moved to my own blog


Just in case people thought I'd gone on quiet. I have not. I have simply started posting new articles on my own blog application, ok2life, where I have more control about the formatting, posting method, and publishing. Also, it is nicer to experiment more with Ruby on Rails and to have complete control of your own destiny (granted, is good for what it does).

The more I use Rails, the more experience I acquire. I will hopefully be posting more articles soon on ok2life when I pick up new knowledge along the way. I have seen more activities and feedbacks for my articles, which are good. I am learning from these comments that there are more than one way of doing something in Rails, and I am happy to be shown a more efficient way of doing it. I guess it is useful to build up a knowledgebase for Rails, as currently whatever I search for, I keep getting sent to the Rails API documentation site by Google, which is absolutely terrible for locating the information you need. What the online community needs is more programing guides for Rails, not reference guides.

There is an RSS feed for ok2life at here.

posted by David at 10:34 PM

| 0 comments links to this post

Thursday, February 02, 2006

Rails Trac bug #3493 regarding broken fcgi under Apache

OK, the original posting regarding this bug report can be found here

I had to upgrade to Rails 1.0.0 finally because another project does not work under Rails 0.14.3, but I found that for some reason Rails 1.0.0 does not work with my fcgi enabled Apache server. The URL's generated for all the static resources like images and Javascript etc. are all prepended with the name of the damn fcgi script !

So I quickly checked back with Trac, guess what, nobody cares. Fine, I will fix it myself. Took me a couple of hours to finally track down the offending code which has changed for the worse in the new version. makes me really angry that somebody can actually check in some code that breaks things rather than make them better.

This is the original code, which works perfectly in the action controller 1.11.0:

def relative_url_root
@@relative_url_root ||= server_software == 'apache' ? File.dirname(env["SCRIPT_NAME"].to_s).gsub(/(^\.$|^\/$)/, '') : ''

So clearly the author makes special provision for Fcgi running on Apache, can does not make assumptions about the environment the code has to run in (this is why if you use WEBrick you will not encounter this problem).

This is the code as it is currently in action controller 1.11.2, the newer version in Rails 1.0:

# Returns the path minus the web server relative installation directory.
# This method returns nil unless the web server is apache.
def relative_url_root
#@@relative_url_root ||= server_software == 'apache' ? env["SCRIPT_NAME"].to_s.sub(/\/dispatch\.(fcgi|rb|cgi)$/, '') : ''

The author is basically you that you are stuffed if the fcgi script is not called dispatch.fcgi. Brilliant ! Highlights my point in other posts that if you customise your Rails installation in any way make sure it is not a walk in the park for unwanted visitors, ugly problems like this will come back and bite you hard .

posted by David at 1:52 AM

| 0 comments links to this post

Sunday, January 15, 2006

The web delivered in a box, your own box

Every morning I go through the same ritual, I browse the headlines of a selection of my favourite websites by going through them one by one in my bookmarks. Well, no more. Anything that can be done manually can be automated by a computer. I have written my own application, Box-A-Web to help me drag together the interesting bits of these sites into one single personal portal, and the computer goes off and does the syndication of this information for me. What about RSS feeds, you ask ? Well I have one of those feeds too in another corner of my server, but these are the points I do not like about them:

1. You are not in control of what you want to see, feed publishers do
2. You need a RSS reader to view the feeds
3. Some publishers embed adverts in their feeds
4. Not all of my favourite sites have RSS feeds
5. HTML is a lot more visual than XML
6. I want to show my friends of my syndicated site sometimes, not possible with RSS

Up to recently, this would not have been possible to do with web technology. You can of course do this in an application you install on the desktop, but what is the fun in that ? I can change the appearance to my portal wherever I am, as long as there is an internet connection (which means most places these days). I do not want these list and tick jobs either, I want to be able to break a page I am interested in into little pieces, then drag these fragments and drop them on to a clean design, then collate them together like in a Jakartan Tapestry. Well, these days it is actually possible to do this using pure web technology, believe it or not.

With Ruby On Rails deployed on the web server, and a W3C compliant browser (like IE or Firefox), this is achievable. Ruby On Rails is not just a server centric technology either. You can do very sophisticated browser based operations like drag and drop, fade and swipe, auto-complete of text fields etc. It is also possible to partially render a web page without disturbing the whole page. The whole package definitely gives desktop technologies a run for their money.

Box-A-Web is an example of what the new technology can do. It emerges that once you break a web page up into little pieces, it is surprising how much of that page is actually useful to you. It is also more surprising how often these fragments change. So typically for a syndicated page, you do not really have to refresh all the fragments together each time. For this very reason, provision has been made for you to reload a particular feed behind a portion of the page without disturbing the rest.

Designing a partially renderable page i.e. AJAX, has its challenges, as all the URL calls you make to refresh portions of the page are fully exposed to the almighty Google search engine. If not done right, it can have some devastating effects (imagine Google getting hold of your delete URL, and happily invokes it once a night, bypassing all the Javascript prompters you have put in place to safeguard against earthly mortals, ouch !!).

Certain part of the syndicated page can also be made private, meaning they only get rendered once you have logged in. However, by default, everything pulled together by everybody is publicly visible. You can thus send an email of the public URL of your syndicated page to a friend so he/she can enjoy it too.

posted by David at 9:16 PM

| 0 comments links to this post

Bug in Rails 1.0 for fcgi when under virtual host

I upgraded to Rails 1.0 on Apache running on Linux with fcgi,
and the dispatcher immediately throws error on all static paths like images,javascripts,stylesheets etc.
I have one Rails project running under virtual host, the other under aliased path, and both are broken the same way.

Rolling back to Rails 0.14.3 fixes the problem immediately.

This is not a problem under WEBrick, leading me to think it is to do with the .htaccess file URL rewriting. Looking at the generated paths in the HTML, I can see what the problem is too, in that typically a path like /images/foo.gif in v0.14.3 is now incorrectly rendered as /dispatch.fcgi/images/foo.gif i.e. the name of the fcgi file in the "public" directory has somehow been appended to the base url, causing the document root to be pushed down one level. In the log file, I get this exception for each requested static file:

ActionController::RoutingError (Recognition failed for "/images/links.gif"):
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.0/lib/action_controller/routing.rb:469:in `recognition_failed'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.0/lib/action_controller/routing.rb:459:in `recognize!'
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/dispatcher.rb:38:in `dispatch'
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/fcgi_handler.rb:141:in `process_request'
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/fcgi_handler.rb:53:in `process!'
/usr/local/lib/ruby/gems/1.8/gems/fcgi- `each_cgi'
/usr/local/lib/ruby/gems/1.8/gems/fcgi- `each_cgi'
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/fcgi_handler.rb:52:in `process!'
/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/fcgi_handler.rb:22:in `process!'

The net effect is the contents of the page are still rendered correctly, however, the style, images, and all scriptaculous features are lost.

I have raised a bug report with Rails Trac, number #3493

posted by David at 6:01 PM

| 1 comments links to this post

Monday, January 09, 2006

Post a whole form contents back in an AJAX call in Ruby on Rails

Rails has a ready made call which facilitates passing the contents of all the elements in a form in an AJAX call with the call form_remote_tag

form_remote_tag :html => { :action => url_for(:controller => "some", :action => "place") }

However, the problem with the above method is you can not pass the name of the form into the call, so if you have multiple forms on your page, this is the way to do it:

<form name='logon' id='logon'>
<input name='name' />
<input type='password' name='pass' />
<%= link_to_remote "Log me in",
:url => { :action => 'authenticate' },
:with => "Form.serialize($('logon'))",
Extracted from Tips and Tricks

posted by David at 2:01 PM

| 1 comments links to this post

Thursday, December 29, 2005

Problem with AJAX drag and drop in Internet Explorer

Just had a painful experience in getting AJAX drag and drop to work for Internet Explorer using Ruby on Rails and scriptaculous

And yes, it all works fine with Firefox !!

posted by David at 12:38 AM

| 0 comments links to this post

Friday, December 09, 2005

Enhancement in Rails remote_function() to support Javascript calls

I have a dropdown list on my web page which is supposed to invoke a remote AJAX call to refresh a portion of the page each time a selection is made. With Ruby on Rails, the recommended way of doing it is to tie the remote_function() call to the onchange() event of the <select> tag. The problem is, with the remote_function() call, the URL you pass to it is static at the point of creation for the dropdown list, so it is impossible to pass the actual selection to the call when it is made, unless you wrap the URL into a Javascript function. However, if you look at the way remote_function() is implemented, there is no support for a Javascript wrapper at all. Well, my improved version and the way I approach solving this problem is here.

posted by David at 10:21 PM

| 0 comments links to this post

Friday, December 02, 2005

Off the Rails ?

If you look at the Ruby On Rails download site, you will see it takes three simple steps to download and create your first Rails application. Well, let me show you what happens in the real world. I have just finished putting together my accounts of the last three days, yes three days, to do the equivalent of the "Hello World" C program. Read it here.

posted by David at 12:48 AM

| 1 comments links to this post

Contact us

Previous Posts


links to this post

Powered by Blogger