Archive for the 'learn' Category

Looking to Learn Object Oriented JavaScript?

Monday, April 9th, 2007

Yes, JavaScript is Object oriented. In fact, the only way you’ll move beyond very simple scripts is if you move beyond procedural JavaScript into using and building your own JavaScript objects. There’s no better way to solve many common front end programming problems than by building an object and taking advantage of its properties and methods.

Starting out with Object Oriented JavaScript can be a little daunting, though. (It’s tough to find a good spot to get started and learn some good practices). Never fear! Here’s the very article I used to learn Object Oriented JavaScript. It’s a pretty solid resource for a beginner, and will put you well on your way to learning how to think of JavaScript as something much more than a series of one-liners and functions.

technorati tags:, , ,

HOWTO: Creating Column Layouts with JSTL and JSP

Saturday, March 3rd, 2007

Creating a multi-column layout in a JSP using JSTL can be a difficult concept to master. Over at my day job, we’ll see this concept occasionally. We’ll have a block of data that we’d like to present in a series of columns, with a maximum number of items in each column. Here is a quick tutorial to outline a solution to this pattern. We’ll be using Sun’s Core JSTL tag library, to do the heavy lifting, along with CSS and HTML.

The Setup
Let’s assume we’ll have at most 30 items in our set, and we’ll want a maximum of 10 items in each column, giving us a three-column layout. For this example, we’ll also put our items in an ordered list so that we can see what item number we’re working with. Let’s set that up in code.

  1. CSS — You’ll need a simple column layout that accounts for the fact that you may have any number of columns, depending on how much data you’ll be working with. I’ll use floats to make it simple, and I’ll add a border to each successive column for a little visual flair. My CSS would look like this:

            div.leftCol{
              float:left;
              width:200px;
            }
    
            div.middleCol, div.rightCol{
              border-left:1px solid #CCC;
              float:left;
              padding-left:20px;
              width:200px;
            }
          
  2. HTML — This one is up in the air. You may have three divs, you may have one. But, they’ll all look something like this:

    <div class="leftCol">[[10 items]]</div>

We know what we’ll be working with, but we’ll need some creative use of JSTL to actually get these elements to fall into place and enforce our maximum values per column rule.

The JSTL
We’ll be making use of two JSTL Core constructs: the <c:if> tag and the <c:forEach> loop.

  • <c:if> works like any standard if test. We’ll use it to test column data boundaries.
  • <c:forEach> gives us a hook called "varStatus" that lets us peek into the status of the iteration. We’ll be looking specifically at the index property of that varStatus object.

Writing the Code
Let’s start with a skeleton JSTL loop, so that we have a little scaffold to build on.

    <c:forEach items="${someItems}" var="item" varStatus="loop">

      <li>${item}</li>

    </c:forEach>
  

That’s a start. We still have to figure out where to place our starting and closing div tags and our starting and closing ol tags, which is the problem concept behind this pattern. Luckily, there’s a clever way of solving this problem.

Assume that we know that there will be at least one item to work with. (If there’s a chance for zero, use a <c:choose&gt block to react appropriately, dealing with the zero condition separately, and using this method as-is.) With at least one item, we’ll always need a left column and a start <ol> tag, no matter what. We’ll always need closing tags for our left column div and an ol, too. Knowing that these are always required, we’ll move them outside the loop, so that they’re always displayed.

    <div class="leftCol">
      <ol>
        <c:forEach items="${someItems}" var="item" varStatus="loop">

          <li>${item}</li>

        </c:forEach>
      </ol>
    </div>
  

We now have at least one column and list. We can use simple if tests to figure out when to close that first column and list and begin a second. In pseudocode, if we are at our maximum number of items, print a
close ol tag, print a close div tag, print a new open div tag with appropriate class, and print a new open ol tag.
So, if we’re at a maximum number of items (in our case, 10 and 20), we’ll close that column and start a new one. Let’s add that concept to our block of code, and finish this pattern. (Remember that loop.index gives us a count of which item we’re on.)

     <div class="leftCol">
       <ol>
         <c:forEach items="${someItems}" var="item" varStatus="loop">

           <li>${item}</li>

           &;lt;c:if test="${loop.index == 10}">
&;lt;c:if> &;lt;c:if test=”${loop.index == 20}”>
&;lt;c:if> </c:forEach> </ol> </div>

That above code may take a few seconds to sink in. The trick is that the </ol> and </div> tags after the loop will close any <ol> and <div> tags that are open at that point. It could be the left column that those tags close, or the middle column, or the right column. Let’s think about that for a second.

  • If there are 4 items in the list, we print the opening tags, enter the loop, print 4 items, exit the loop, print the close tags.
  • If there are 17 items in the list, we print the opening tags, enter the loop, print 10 items, print the close tags for the left column, print the opening tags for the middle column, print 7 items, exit the loop, print the close tags.
  • If there are 24 items in the list, we print the opening tags, enter the loop, print 10 items, print the close tags for the left column, print the opening tags for the middle column, print 10 items, print the close tags for the middle column, print the opening tags for the right column, print 4 items, exit the loop, print the close tags.

As you can see, we’re using the nature of HTML (a closing tag closes the nearest opening tag, regardless of any attributes that opening tag may have) to simplify our work and save many lines of JSTL. In the meantime, we have a simple pattern that will allow us to create as many columns as we want (simply create a generic CSS column class) with as many items in each as we want (simply change the boundary values in the JSTL). The key to the puzzle: keeping code we know we’ll always need outside of the loop so that it will always be printed and taking advantage of the nature of HTML.

technorati tags:, , , ,

Ruby on Rails: Selecting the last item in a database table

Thursday, October 26th, 2006

Ruby on Rails has the great find(:first) method that lets you grab the very first ActiveRecord object out of a given database table. That’s all well and good, but what if you want the last? Use this: Model.find(:first, :order => “id DESC”). That will give you the first record in a reversed list of IDs: basically, the record with the highest ID value, or the last record in the table.

Not good enough for you? Order by any other field. Want a different first record ? Sort by a field ASC. The :first record really depends on what order your records are in.

technorati tags:, , Ruby, Rails, ActiveRecord

Google Launches Custom Search Engine

Tuesday, October 24th, 2006

Google’s just launched Google Custom Search Engine, which lets you, basically, build your own search engine around a certain set of topics. Why would you do this, other than to show off? Well, Google will let you "make money from the traffic you receive through Google’s AdSense program." Now, why on Earth would Google pay you to make your own search engine when theirs works so well? Simple: your personal engine can make theirs better.

Experts are going to deliver more relevant search results than an algorithm almost every single time, simply because they are experts: they know where and how to look for information in their fields. Search engines only know how to look for information, and that’s not talking about highly specialized information. Essentially, you’re training Google in what’s relevant for your subject and giving them information that they can easily roll back into their own search algorithms. (AJAX titled search + lots of traffic = pretty good indication that Google should mark these pages as relevant).

Plus, Google is improving user experience on two fronts with this product: first, they’re making available a great resource for specialists to find what they’re looking for; second, they’re ensuring that all searches that end with a Google result return highly relevant, targeted information. Your search’s specificity makes Google’s search look better: it’s the halo effect. All for a little AdSense revenue.

technorati tags:, , , ,

Blogged with Flock

Wildcard SSL Certificates and Internet Explorer

Monday, October 23rd, 2006

Wildcard SSL certificates let you purchase a single certificate for an unlimited number of subdomains. For example, you can buy a certificate for *.foo.com, allowing bar.foo.com and baz.foo.com to live under the same certificate. But, x.bar.foo.com is not covered by the wildcard. (And, it leads to a particularly nasty barrier page in Internet Explorer 7 that says, basically, this site is a scam so don’t visit it). Wildcard certificates only wildcard a single level: if you need subdomains of subdomains, you’ll need to blanket them with their own certificate.

technorati tags:, , , ,

Google’s Battle Between Love and User Testing

Wednesday, October 18th, 2006

I think everyone would like to have this problem:

Google is trying out a number of new UI improvements with SearchMash that it may or may not implement into Google’s current search engine, but doesn’t want the user experience to be skewed by Google’s brand name. The general public has such positive feelings towards Google that users might be inclined to simply like whatever is presented to them, which would hinder a true analysis of what’s actually good and what’s not.

Even though it’s almost never going to happen for us normal, only-kind-of-liked folks, Google’s predicament begs a really interesting question: how do you test new products, or big product revisions, on people who are intimately familiar with, and really really love your existing product? You can’t simply recruit people for testing, sit them down in a room, and have your facilitator say, "OK, this is the new Google. What do you think?&qout; This invites very biased responses: passionate users (as most who use Google are) will have passionate answers that are inherently biased towards the thing (product, idea, etc.) that they like like (or dislike). Preference, in either direction - love or hate - breeds passion; passion leads to a bias. So, how did Google avoid bringing preference into testing? They used the software equivalent of the blind taste test.

We’ve all seen those crazy Pepsi vs. Coke, "if you blindfold 10 people and have them drink a Pepsi and a Coke, 9 out of 10 will take the Pepsi," ads on TV. Google’s brought this out of the world of TV (and traditional product research), and remapped it to the web: "9 out of 10 people who didn’t know they were using a Google search product really liked our new features" Now, you’re able to get unbiased results for a beloved product. Without any bitter aftertaste!

technorati tags:, , , , , , ,

Blogged with Flock

Whither CSS vertical-align

Thursday, October 12th, 2006

Though there is a CSS property vertical-align, it doesn’t work like attribute valign in HTML tables. CSS property vertical-align doesn’t seem to be able to solve this problem:

Plain and simple, the CSS veritical-align property really doesn’t work like it should. (Maybe it works to the spec, but it’s not intuitive.) It does not work like a <td>’s valign="middle" attribute, and odds are that’s the behavior you’re trying to emulate when you’re using vertical-align.

Aligning an element vertically within a container of a known height is pretty simple. You can:

  • Give the to-be-aligned element margin-top,
  • Give padding-top to the container, an sub-container in the larger container, or the to-be-aligned element,
  • Use position:relative or position:absolute to slide the aligned element into its desired position.

All this is great. But, what happens when you’re trying to vertical-align against something with a dynamic height? Using vertical-align rarely works as planned, and won’t work if you’re using a block-level element. What do you do?

Vertical Centering in CSS is a solid technique that lets vertical alignment work like it should. I’ve got code using this method in production and, let me tell you, it works very well. Yes, it adds a little extra markup to your document and CSS, but it’s well worth it for the final effect: a vertically centered element without the usual headache. Follow that link and align freely!

technorati tags:, ,

Multiple CSS Classes on an Element

Wednesday, October 11th, 2006

Here’s a little CSS tip that a lot of people are unaware of: you can give an element as many CSS classes as you’d like by adding them to that element’s class attribute separated by spaces.

This is how it looks: <div class="big orange square">. Your div now belongs to three classes: big, orange, and square.

What about adding classes with a script? Just use element.className += ” classname” to add them (that’s space + classname). To subtract? Set element.className equal to a string without that element. You can do this by splicing that unwanted class out of a string, using a regular expression to filter it away, or using any other string manipulation. Just set element.className = to your new string. Voila.

technorati tags:, , , ,

Explaining Dojo’s FisheyeList Widget Settings

Wednesday, October 4th, 2006

I’ve been using Dojo’s FisheyeList widget (think of Mac OSX’s dock) in an internal app I’ve been
building for TheLadders.com. It’s a totally killer piece of script,
and works very well right out of the box. However, there’s not much (read: there’s no) documentation on using it. So, in the hope of
helping someone out, here’s what I’ve figured out so far. (I’m working on dojo version 0.31, and by no means is this list exhaustive).

  • Using dynamic images: You can add list items (dojo-FisheyeListItems, to be exact) at run-time with JavaScript. Just document.write them into your dojo-FisheyeList container, and the widget will pick them up. This allows you to grab images dynamically with another script, and inject them into your list.
  • What do the properties of the dojo-FisheyeList container actually do? This:
    • dojo:itemWidth - The width of the item in the "dock" before mouseover (in pixels).
    • dojo:itemHeight - The height of the item in the dock before mouseover (in pixels).
    • dojo:itemMaxWidth - The biggest possible width your image can have on full mouseover (in pixels).
    • dojo:itemMaxHeight - The biggest possible height your image can have on full mouseover (in pixels).
    • dojo:orientation - Either "horizontal" or "vertical".
    • dojo:effectUnits - The distance your mouse can be from the widget before it activates. Lower values mean your mouse must get closer to
      the widget strip before the icons puff up; higher values mean the widget activates at greater distances. Decimal values are OK.
    • dojo:attachEdge - Specifies which section of an icon triggers the "puff" effect. Can be "top", "bottom",
      "left", "right", or "middle". "middle" creates a really strange effect.
    • dojo:labelEdge - Specifies where the image’s label displays. "top" and "bottom" are the only choices here. If you
      enter anything other than those two, the widget defaults to "top".
    • You don’t need to add a label to your images. If you don’t add the "caption" attribute to a dojo-FisheyeListItem,
      the caption won’t display for that item.
    • dojo:enableCrappySvgSupport - I tried toggling this between quot;true" and "false", but really noticed no difference.
      I’ve been testing in IE 6.0 and FireFox 1.5, so perhaps this does something in an older (or different) browser?

In all, this widget gives you a great effect with a very quick installation. Does anyone else have any tips for using the FisheyeList?

technorati tags:, , , , , ,

12 Ways to Learn - or Improve - Your CSS

Wednesday, September 27th, 2006

As one working exclusively on CSS-based layouts (that’s it, a little markup and a lot of CSS) day in and day out, I readily admit that it’s a tough thing to learn to do and it’s not an easy thing to master. Ben Henick’s 12 Lessons for Those Afraid of CSS and Standards serves both levels by presenting ideas that the novice needs to know and the intermediate needs to master. I recommend clicking that link and reading the article, no matter what you’re level. I’ll provide some of my thoughts on the article below (I’ll even try to make them match his order).

  1. CSS is a very functional language. You really should think of it as an object-oriented language powered by inheritance and contextual properties. This is confusing at first (why does my headline render differently in one column than another?) but immensely powerful (I can make my headline render two different ways in two different contexts).
  2. Rendering engines cause rendering bugs that make perfect presentation of a design very difficult. It’s not impossible, though. Using tools like position, you can really measure and execute designs to the pixel.
  3. Most people don’t understand the skill and time involved in battling browsers, especially when your company or project is firsting starting out down the CSS road. It takes a while – especially for a new CSS programmer – to figure these things out and learn how long "simple" tasks will take.
  4. I’ve fallen into the div-soup trap before. Real CSS mastery occurs when you realize that you don’t need divs anymore, that you can do the same thing using all those "basic" html tags that you’ve long forgotten.
  5. In many cases, the person responsible for a site’s graphic design is not responsible for any other aspects of site implementation. When paired with a failure to create strict site- and section-wide wireframes, this lack of accountability results in unique comps for too many pages, and thus a lot more work for the stylist and producers.

    Please, designers, create consistent designs. There’s no reason why your columns should vary by a few pixels here and there. There’s no reason why a site should have more than a few base templates. Designers can either expidite the build process or bottleneck it with their creations. And, believe me, I’ve designed and built. When I design with building in mind, my design works better with fewer compromises.

  6. Tracking down browser bugs takes time, and it’s most often that crunch time when a project is in its final phases. It’s a hectic thing.
  7. The author left out one big benefit: really taking advantage of the cascade lets you do things, and change things, quickly. Want your left-hand links to be green? Tight CSS makes this a snap.
  8. See #7. You don’t need all the markup that you think. This is a hard concept for novice programmers to grasp: their quickest action is to wrap everything in a div, style it, and walk away. I prefer to use divs as selectors, then use normal HTML markup as children of that selector. This makes stylesheets easy to read and easy to change. Plus, by using normal HTML markup, you can really improve that SEO, which everyone loves.
  9. Without stylesheet hacks, your site won’t work. Plain and simple. Yes, /**/ is not valid CSS, but it works. Try to write code with standards and mind, but avoid blocking on standards. There are cases where you will need to eschew standards to get your work done. Don’t stay late looking for a "standards-compliant fix" when you won’t find one (believe me, I’ve looked), and the hack is the cleaner, easier way to go.
  10. There’s nothing like writing a whole page, getting it into production, then seeing the "peak-a-boo" bug dropping off some text for no discernible reason. Or having blockquotes slowly shift your text off the screen. Or having…
  11. position:relative is usually the first thing I try when trying to fix an IE bug. line-height sometimes works, too.
  12. A background image on an <h1&gt makes a lovely, accessible, SEO-friendly headline. Standard design templates let you use and reuse backgrounds. Reusting common elements means less new browser bugs, and shorter development cycle, and much happier developers.

You can tell I’ve been doing this for a while, eh?

technorati tags:, , , , , , ,

Blogged with Flock

I'm Reading…
Search This Site
You are currently browsing the archives for the learn category.

AddThis Feed Button

Need great hosting?

Categories