IE is such a wonderful browser... *cough* Anyways, I found a slight display problem with divs in IE 6. Apparently, the div will only shrink to a certain height before it stops shrinking. From experimenting, I found the height to be around 20px.
Anything larger than 20px, IE 6 will display properly. However, anything below 20px, such as 15px, IE 6 will continue to display as 20px. Frustrating huh?
I found a hack to get around this, which is to set the div to:
overflow: hidden;
This will allow the div to shrink to any height, and hide the content inside the div that goes over the specified height.
Annoying.
W
Thursday, January 31, 2008
12 Hour Time
RoR comes with many fantastic helpers for the view. However, there is one helper that is definitely lacking some features. Perhaps it is purposely missing features because of its complexity and range of customization. What I'm referring to is the DateHelper.
Firstly, when selecting a date, having selects as inputs just outright sucks! It's very hard for the user to visualize such a layout. We are used to seeing calendars. In what real world situation do you ever look at dates in a select box format... none that I can think of. But calendars, that's another story. Calendars are so normal to users that without them, we're lost! Unfortunately, RoR does not come prepackaged with a calendar format for dates. But luckily, RoR is extendable through plugins! We're currently testing out which one works best for us, and we'll let you know when we've come to a decision.
The second problem with the prepackaged helper is the fact that when selecting times, we're forced to take the inputs based on a 24 hour clock... EWWW!!! No body works on a 24 hour clock (except if you're in the military...) The usual person just isn't used to seeing a 24 hour clock. That's where plugins come in again!
I found a plugin that worked very well and required very little modifications:
12_hour_time
This plugin allows you to add an option to your current time selects to make them based on a 12 hour clock:
:twelve_hour => true
The rest (frontend and backend) are automatically handled for you!
Brilliant!
W
Firstly, when selecting a date, having selects as inputs just outright sucks! It's very hard for the user to visualize such a layout. We are used to seeing calendars. In what real world situation do you ever look at dates in a select box format... none that I can think of. But calendars, that's another story. Calendars are so normal to users that without them, we're lost! Unfortunately, RoR does not come prepackaged with a calendar format for dates. But luckily, RoR is extendable through plugins! We're currently testing out which one works best for us, and we'll let you know when we've come to a decision.
The second problem with the prepackaged helper is the fact that when selecting times, we're forced to take the inputs based on a 24 hour clock... EWWW!!! No body works on a 24 hour clock (except if you're in the military...) The usual person just isn't used to seeing a 24 hour clock. That's where plugins come in again!
I found a plugin that worked very well and required very little modifications:
12_hour_time
This plugin allows you to add an option to your current time selects to make them based on a 12 hour clock:
:twelve_hour => true
The rest (frontend and backend) are automatically handled for you!
Brilliant!
W
Tuesday, January 29, 2008
Lighbox modification
A few posts ago, I mentioned modal pop-ups and using the Lightbox Gone Wild implementation. Everything was going well, until I tested it out in IE6 for compatibility.
Well... to no surprise, there was a slight problem. Every so often when leaving the page, a JavaScript error would appear, complaining that some 'handler' was null or not an object. However, in Firefox, I was not having any problems.
I finally narrowed it down to a line with this call:
Event.observe(window, 'unload', Event.unloadCache, false);
I quickly checked the Prototype API and found out that this call was no longer necessary in version 1.6. I removed this line, and everything is now working fine once again (even on IE6!)
W
Well... to no surprise, there was a slight problem. Every so often when leaving the page, a JavaScript error would appear, complaining that some 'handler' was null or not an object. However, in Firefox, I was not having any problems.
I finally narrowed it down to a line with this call:
Event.observe(window, 'unload', Event.unloadCache, false);
I quickly checked the Prototype API and found out that this call was no longer necessary in version 1.6. I removed this line, and everything is now working fine once again (even on IE6!)
W
Saturday, January 26, 2008
Pagination
When displaying a list of information to the user, it's always handy to separate it into several pages if your list gets too long. This is a very common task, but also a very redundant and mundane task.
The logic to figure out how to display the page links is rather repetitive:
<Prev 1 2 ... 99 100 Next>
Instead of wasting time writing and rewriting this, wouldn't it be a better use of time working on something else? Well, there's a plugin that makes your life easy! It's called will_paginate.
will_paginate gives a wrapper around the find functions, allowing you to give the page number you want, and it returns to you just those objects that will be displayed on the page. Furthermore, with one simple function call, the nice page links will be displayed for you properly! Check out the will_paginate page for a quick example.
The only down-side I found to this plugin was that it didn't support AJAX. I hope that in one of the future releases they'll add AJAX support. In the meantime, I added one myself called will_remote_paginate. It merges will_paginate and the usual remote calls together like so:
<%= will_remote paginate @products, :url => list_products_path, :method => :get %>
If your interested in seeing what I did, give me a shout and I'll post it up. It's not the best solution in the world, but at least it works for me!
W
The logic to figure out how to display the page links is rather repetitive:
<Prev 1 2 ... 99 100 Next>
Instead of wasting time writing and rewriting this, wouldn't it be a better use of time working on something else? Well, there's a plugin that makes your life easy! It's called will_paginate.
will_paginate gives a wrapper around the find functions, allowing you to give the page number you want, and it returns to you just those objects that will be displayed on the page. Furthermore, with one simple function call, the nice page links will be displayed for you properly! Check out the will_paginate page for a quick example.
The only down-side I found to this plugin was that it didn't support AJAX. I hope that in one of the future releases they'll add AJAX support. In the meantime, I added one myself called will_remote_paginate. It merges will_paginate and the usual remote calls together like so:
<%= will_remote paginate @products, :url => list_products_path, :method => :get %>
If your interested in seeing what I did, give me a shout and I'll post it up. It's not the best solution in the world, but at least it works for me!
W
Thursday, January 24, 2008
Modal Pop-ups
Ever seen those really neat pages where you click on a link, and instead of an actual pop-up in another window, you get a "pop-up" that sits on top of your existing page. And even better, it's modal and anything not in the "pop-up" becomes darker.
Well, I wanted to implement something like that. My first initial thought was to create a new div, center it, make it transparent (slightly), then lay another div on top of this. The first div would block everything underneath it, while the second div would display what I needed. I saw two immediate problems. The first was that IE 6 doesn't support transparent png files very well (of course... considering IE 6 doesn't support many things very well), and the second was that IE 6 (again!) doesn't honour the z-index on selects. Wow.... how did IE 6 ever get so popular... (M$). Anyways... long story short, it requires a number of hacks to get everything working it seems.
So... instead of tackling the problem myself, I naturally assumed that I wasn't the only one with this problem. Lo and behold, I found a very good implementation for this already that fits hand-in-hand with RoR:
Lightbox Gone Wild!
This wonderfully written code includes only 2 files. A javascript file and a CSS file. It is, however, based on Prototype and Script.aculo.us, which RoR already automatically includes in it's javascript folder. Calling it is even simpler. You create a link to the HTML file you want to have in your "pop-up" and label it with the class as "lbOn". That's it! You get the whole package deal with this simple modification! Don't believe me? Try it!
If you want it to call a controller to have dynamic information displayed (unlike the examples given on the website), instead of the link URL being something like "text.html", just change it to the path of a controller action. What will happen is an AJAX call to that controller action, whereby you can treat it as any other AJAX call, such as when you use link_to_remote or remote_form_for.
Simple as 1-2-3!
W
Well, I wanted to implement something like that. My first initial thought was to create a new div, center it, make it transparent (slightly), then lay another div on top of this. The first div would block everything underneath it, while the second div would display what I needed. I saw two immediate problems. The first was that IE 6 doesn't support transparent png files very well (of course... considering IE 6 doesn't support many things very well), and the second was that IE 6 (again!) doesn't honour the z-index on selects. Wow.... how did IE 6 ever get so popular... (M$). Anyways... long story short, it requires a number of hacks to get everything working it seems.
So... instead of tackling the problem myself, I naturally assumed that I wasn't the only one with this problem. Lo and behold, I found a very good implementation for this already that fits hand-in-hand with RoR:
Lightbox Gone Wild!
This wonderfully written code includes only 2 files. A javascript file and a CSS file. It is, however, based on Prototype and Script.aculo.us, which RoR already automatically includes in it's javascript folder. Calling it is even simpler. You create a link to the HTML file you want to have in your "pop-up" and label it with the class as "lbOn". That's it! You get the whole package deal with this simple modification! Don't believe me? Try it!
If you want it to call a controller to have dynamic information displayed (unlike the examples given on the website), instead of the link URL being something like "text.html", just change it to the path of a controller action. What will happen is an AJAX call to that controller action, whereby you can treat it as any other AJAX call, such as when you use link_to_remote or remote_form_for.
Simple as 1-2-3!
W
Wednesday, January 23, 2008
Mixins
In Ruby, there's something called mixins. What is this? Basically, they are mix of a class and modules. Modules can be thought of as relatively independent pieces of code that you may want to mix into your classes. Modules are used to keep the code modular and easier to maintain.
For example, if we wanted to have the ability to compare objects, we could create a Comparable module. This module would define the functions in order to compare objects. Some objects do not require this function however, so we do not need to add it to a base class. Instead, we can include this module to only those classes that require it. This is, of course, overly simplified, but it is only to illustrate the purposes of modules.
For a quick tutorial on mixins, visit this site:
http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/
W
For example, if we wanted to have the ability to compare objects, we could create a Comparable module. This module would define the functions in order to compare objects. Some objects do not require this function however, so we do not need to add it to a base class. Instead, we can include this module to only those classes that require it. This is, of course, overly simplified, but it is only to illustrate the purposes of modules.
For a quick tutorial on mixins, visit this site:
http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/
W
Monday, January 21, 2008
DRYing Up YAML Fixtures (except for PostgreSQL!!!)
When creating YAML fixtures, there are many records that have many repeated values. For example:
user_1:
name: john
is_active: true
user_2:
name: billy
is_active: true
Here, the is_active field is repeated many times and has the same value true. This may be a default for many records. YAML allows you to set defaults:
defaults: &defaults
is_active: true
user_1:
name: john
<<: *defaults
user_2:
name: billy
<<: *defaults
Obviously, this simple example doesn't save us any time. However, if our defaults include many columns, this can save a lot of typing and headaches when default values need to be changed.
All this is wondeful... EXCEPT when your using PostgreSQL, and it's driving me NUTS!!! For some reason, this DRY method doesn't work. I haven't figured out why yet and my search for the answer has been rather futile. If any one has an answer, I'd like to know the reason.
W
user_1:
name: john
is_active: true
user_2:
name: billy
is_active: true
Here, the is_active field is repeated many times and has the same value true. This may be a default for many records. YAML allows you to set defaults:
defaults: &defaults
is_active: true
user_1:
name: john
<<: *defaults
user_2:
name: billy
<<: *defaults
Obviously, this simple example doesn't save us any time. However, if our defaults include many columns, this can save a lot of typing and headaches when default values need to be changed.
All this is wondeful... EXCEPT when your using PostgreSQL, and it's driving me NUTS!!! For some reason, this DRY method doesn't work. I haven't figured out why yet and my search for the answer has been rather futile. If any one has an answer, I'd like to know the reason.
W
Subscribe to:
Posts (Atom)