Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

10 Minutes to Your First Ruby Application : Page 3

There's no better way to experience the elegance and power of Ruby than to fire up your code editor and start writing Ruby code. Create a small, useful Ruby application, and along the way, you'll learn what makes the language tick.


advertisement
Bulking Up to Version 1 with Dynamic Loading
So far, so good with Version 0, but you can do better. Rather than having a simple, direct mapping of file types to the application, you could map file types to execution handlers. That is, you can define code for your file types that can then decide which application to run, and with which arguments, depending on additional command-line arguments.

For example, if you are doing web development and have created an HTML file, you most often want to view it in a browser. So your application as it is works OK. But sometimes you want to view it using a particular browser. Right now, Launcher only allows a single application association. What you may want is the ability to launch myfile.html in the Opera web browser:

$ ./launcher myfile.html opera



Or you my want to perform some syntax checking on the HTML:

$ ./launcher myfile.html syntax

In other words, you want to add some smarts (see Sidebar 4. The Smarts Behind Launching Logic).

Dynamic Loading
To add those smarts, you will change your program so that you can associate file types with Ruby code rather than associating a particular application. That Ruby code will handle the launching logic, allowing you to decide just how clever to be when launching an application for a given file type (see Sidebar 5. Dynamic Class Loading with Defined Custom Ruby Classes).

Before doing this, make one small change. Having all your code in one place is handy, but it's not a good practice for anything but the smallest apps. For the sake of better organization, split out the general class code from the code that interacts with the user. Do this by creating a file, go.rb, and moving all but the actual Launcher code into that file (i.e, that last chunk of code you just added):

#!/usr/local/bin/ruby require 'launcher' # Script to invoke launcher using command-line args def help print " You must pass in the path to the file to launch. Usage: #{__FILE__} target_file " end unless ARGV.size > 0 help exit else app_map = { 'html' => 'firefox', 'txt' => 'gvim', 'jpg' => 'gimp' } l = Launcher.new( app_map ) target = ARGV.join( ' ' ) l.run( target ) end

Note the extra line of code near the top:

require 'launcher'

You need this line to make your Launcher available to the current script. The require method looks for a file matching the given string. The file extension is omitted, so Ruby first will assume you want a .rb file but also will look for a compiled library (e.g., .so) if it doesn't find a Ruby file. (Ruby searches a pre-defined load-path, which includes the current directory, so if you keep launcher.rb in the same place as go.rb, you're good. If you move it, you have to be more explicit about were Ruby can find it.)



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap