2007-01-12

Ruby vs Perl

I've been working with Perl for the last 15 years and it's safe to say that I know Perl and I know her well, but as for Ruby, I've only been learning it for the last two weeks and unfortunately I've come to a conclusion that I thought would take a little bit longer if it were going to happen at all!

I've read the entire Pick-Axe book (version 2) and was extremely excited about the language in general as it has some very nice features that I could very easily become accustomed to but I felt that I needed to have a comparison against my favourite language in order to make a better decision.

I have a price list Excel document that I need to extract just two columns from, B and J.

The filesize is approx. 3.5MB and all in all, it's a pretty straight foward request.

Ruby loaded the Excel document into memory in 1.9 seconds as opposed to Perl doing it in 2.1 seconds (yep, IO is dependant on what's going on at the time so this could certainly be a skewed result).

But unfortunately, Ruby took a total of 21 lines of code to accomplish the same thing that Perl did in only 6 lines!

I certainly have a steep learning curve before I'm half as fluent in Ruby as I am in Perl but when it comes to the crunch, the simple tasks are what I use Perl for. If Ruby can't cut it in regards to being fast to code, them I'm going to have to put Ruby on the back-burner.

Unless someone can show me better stats and less code, Perl is the choice for me.

2007-01-02

Cross-browser JavaScript PopUp Calendar

Ok, I'm going overboard now, I'll post for like a day and a half, say everything that I've ever thought of, then I won't post for another year! hehehe Just kidding.

Ok, here's my second Cross-browser JavaScript widget that I just love building, my PopUp Calendar. It was originally inspired by the Visual Basic 6 Calendar Object, then modified because people at my previous employment wanted it to function differently.

So here goes again q:)



You can download the source code and the example HTML file from here, but once again, please leave my name on the code. It's just a simple sign of respect that's all.

Code Explanation

After including the popUpCalendar.css and popUpCalendar.js files into your HTML file, we need two additional objects to complete the exercise, a Receiving Object and a Parent Object.

The Receiving Object typically is a form item that can be set using JavaScript, though I have allowed for <DIV> and <SPAN> tags to receive the value using innerHTML or innerText.

The Receiving Object

<INPUT TYPE="text" ID="receivingObject" NAME="receivingObject" />

This can be placed anywhere in your code that you want to receive Dates for. You can have as many of these as you like, just remember that typically you have a Receiving Object and a Parent Object combo, rather than multiple Receiving Objects and a single Parent.

The Parent Object

<INPUT TYPE="button" ID="parentObject" NAME="parentObject" VALUE="..." ONCLICK="puc_showCal('parentObject', 'receivingObject', 'dateFormat', 'receivingObjectType_String');" />


The INPUT tag is pretty self explanatory, it simply displays a button with an ellipsis (three periods in a row) on it which activates the puc_showCal() function when clicked.

The puc_showCal() function is pretty straight forward. It requires that you send through the name of the objects, not the objects themselves. I've a simple function that returns an object using the names as references.

The parentObject is an anchor object. It simply uses the X and Y coordinates of this object as the TOP and LEFT values for the layer. Please note: you can hack the script if you wish there to be a distance between the TOP and LEFT points of the parentObject and the layer. In the function puc_showCal() lines 298 and 299 have variables x and y respectively, you can make your mods there if you wish.

The receivingObject is the HTML object that's going to be modified after the user has selected the Date they wish to use. There are actually four Object Types that can be used here:
  • VALUE - Typically a form element that has the property VALUE (ie. INPUT TYPE="text" or TEXTAREA objects)

  • INNERTEXT or INNERHTML - These apply to anything that has the properties innerText or innerHTML (ie. DIV's and SPAN's)

  • VARIABLE - If you declare a variable at the HEAD or above the call to puc_showCal(), you can have the value placed inside that variable for additional processing


This widget comes with a CSS file that can allow you to change it's appearance pretty easily and make it your own with just a few code changes!

Cross-browser JavaScript TreeView

I'm going to have a go at putting up a working example of my Cross-browser JavaScript TreeView Control working, plus an example of how you can use it on your website!

So here I go...



It works under Firefox (version 1.0.8 through 2 (even the new Beta version)) and the dreaded Internet Explorer (version 5.0 and up).

I've currently finished my first Web-based Content Management System (WebCMS) which uses this treeView for the organisation of your files on the web server, but I build the Tree Nodes dynamically using my beloved Perl!

Please feel free to download the files and use them as you wish. I only ask that you leave my name in them for my personal credit/ego q:) I've created a .TAR.GZ for you to download

Code Explanation

  1. Firstly, create an HTML file and link the Style Sheet and JavaScript files like so:

    <link rel="stylesheet" type="text/css" href="tv.css" />
    <script type="text/javascript" src="treeView3.js"></script>
    <script type="text/javascript" src="treeViewConfig.js"></script>


  2. Next, include the call to the function that starts it all off, renderTreeView();
    <script type="text/javascript">

    renderTreeView();

    </script>

    somewhere inside the BODY tag

  3. Save your HTML file and edit your treeViewConfig.js file. It doesn't have to be called this, but it makes sense that's all. The treeViewConfig.js file must have at least the following items for the renderTreeView(); function to do anything of interest at all

    imageDir = "[path_to_tv_directory_with_images_in_it]";

    createRootNode([rootNodeID], "[Root Node Label To Display]", "javascript:toggleNode([roodNodeID]);", "[frame_to_perform_action_in]", 0, 1);

    addNode([nodeID], [parentNodeID], "[Child Node Label To Display]", "[action_to_perform_when_node_is_clicked]", "[frame_to_perform_action_in]", 2, 2);


  4. Load your HTML file in a browser

I'll give you a bit more explanation of the functions mentioned in step 3.

imageDir = "[path_to_tv_directory_with_images_in_it]";

This sets the path to all the images that the TreeView will use during it's rendering. Without this set correctly, the TreeView will render but all these broken image links will appear, making it look like crap. It's relative to the HTML file I believe (I could be wrong), just have a play around with it.

createRootNode([rootNodeID], "[Root Node Label To Display]", "javascript:toggleNode([roodNodeID]);", "[frame_to_perform_action_in]", 0, 1);

Every TreeView requires a Root Node (ok, that's not entirely true simply because you can have a TreeView without a Root Node but that's not the way I've designed this one). This TreeView requires a Root Node q:)

The createRootNode() function allows you to give the Root Node an ID to which every other Child Node can be added to (typically make this a Numerical Value, it's easier to parse trees this way, though String Values will work, just slower). It also allows you to specify the Label that appears for the Root Node. This can include any HTML you see fit.

Next is the "javascript:toggleNode([roodNodeID]);" parameter. This forms the <A HREF=""> part of the code that's generated, so whatever you can stick inside a normal <A HREF=""> attribute will happily go in here.

The "[frame_to_perform_action_in]" parameter in most cases for you, will be a blank string (ie. ""). This was included incase you decided to do a two framer version where the left frame would hold the TreeView and the content accessed by the Nodes would be displayed in the right frame. If this is the case, the value for this typically would always be the name of the right frame.

And lastly, the 0, 1 parameters. These are simply image indicies within the IMAGELIST array. At the moment, the first image that I load is the Plus Node icon which means that the Root Node by default would be closed, second image that I load is the Minus Node icon, so this specifies that if I have not selected this Node, use IMAGELIST[0]. If I've selected the Node use IMAGELIST[1] and so on.

Finally, the addNode([nodeID], [parentNodeID], "[Child Node Label To Display]", "[action_to_perform_when_node_is_clicked]", "[frame_to_perform_action_in]", 2, 2); code. This line is almost identical to the createRootNode() function call except this now applies to Nodes within the Root Node. Same details apply to these parameters as they do for the createRootNode() except the [parentNodeID] obviously references a Node that this Child is going to belong to.

Well that's about it for my second post. A whole lot of waffling going on here, but somehow, I now kinda understand what Programming books are like 1000 pages long!

My first posting!

Wow, I truly never thought that I'd be creating a Blog but here I am, doing just that q:)

I hope I don't offend anyone with my opinions but I feel that I need to join the online community in a way that I was able to contribute my opinions about everything without having the world say no I can't.

At least this way I can find out how everyone else feels about my thoughts and perhaps their opinions might help shape mine!

Anyhow, if you're reading this then all I can say is, Hello, I'm Bradley, and I've got ideas about how things should be and if you'd like to hear about them, I'll be glad to post about them!