Simple jQuery Solution to Provide Default Values for Page Elements

Tony Pitale, Web Developer, November 26, 2008 8

When outputting sets of data that may or may not be present it is valuable to have some default to display in the cases when that data does not exist. As this set grows to the point where detection becomes unwieldy, perhaps as new fields are added, having complex conditionals in your view code is typically not the best solution. In this example, Dining & Kitchen and Appliances have no information.

Listing Price Information

Original Price: $239,999.00
Low Price: $139,000.00

Dining & Kitchen

Appliances

Bedroom Information

Main Floor Beds: 2

Enter jQuery: with a simple statement we can easily detect which elements on our page are empty, and fill them with some default value to notify a user of that case.

$('ul').each(function() {
  if(jQuery.trim($(this).html()) == "") {
    $(this).html("<li>No information available</li>");
  }
});

The above code checks every unordered list element on the page to see if the html within is empty. If so, it adds a simple list item with a default value to inform the user that the section on the page has no information, instead of simply being empty. The end result is below.

Listing Price Information

Original Price: $239,999.00
Low Price: $139,000.00

Dining & Kitchen

No information available

Appliances

No information available

Bedroom Information

Main Floor Beds: 2

This solution has the benefit of speed, and a fairly accessible global reach, while keeping view code and helpers free of potentially gargantuan if statements.

Posted in Tips and Tricks on 11/26/08 8 comments

Joan Piedra said on 11/27 at 01:50 PM

Tony,

This is nice and simple solution for a real user; sadly it won’t work with spiders, bots or screen readers with javascript disabled.

I believe checking if there is no real data should be a part of the back-end process, leaving all the views clean of if/else statements.

Regards,
Joan

Hein Haraldson Berg said on 11/29 at 08:44 AM

I agree with Joan. Some things are better left for the server-side to handle, and with a decent CMS with well-coded templates, this should not even be an issue to which we needed some JS solution to fix.

Keith said on 12/01 at 10:14 PM

I think this is a creative and perfectly valid solution. I would definitely use JS to fill in this type of fluff on a page if it meant keeping the views that much less cluttered. Thanks for sharing.

Hein Haraldson Berg said on 12/02 at 03:05 AM

Worrying about how cluttered the views (I assume by this you mean ‘templates’?) seems strange to me. We are the developers, and we have to deal with clutter so that the customers don’t have to. Better to keep the clutter backend than letting it leak out to the frontend in the first place and then again fix it.

‘Let’s print out the titles no matter what — even if the content isn’t there — and then afterwards check with JS if the titles are standing alone or not!’ It just sounds like a silly idea. Because it is. Get you views straight — the clutter stays backend, the page load times decreases because the server’s handling that stuff, only relevant stuff for the search engines to pick up, and everybody’s happy.

Joan Piedra said on 12/02 at 08:45 AM

@Hein: Agree.

Tony Pitale said on 12/02 at 04:54 PM

@Joan: You’re right - the dynamically-added content provides no additional value to spiders or bots, but in this specific case the relevant content (e.g. “Appliances") is already present. This approach does appear to provide hurdles for users that rely on a screen reader.

@Hein: I think we can use the terms “view” and “template” interchangeably here - what we’re really talking about dynamically-rendered markup. Controlling code clutter is an important goal at all levels and removing this clutter from the view makes the job of the design & production team much easier.

Certainly this logic could be pushed elsewhere (in a Rails application, we would use a helper module) but this would end up removing some control over the markup from the designers and would result in no performance gains. The solution I present here leaves us with clean code on both the “back end” and in the presentation layer, but as with any solution there are drawbacks to consider.

Hein Haraldson Berg said on 12/02 at 05:14 PM

The clutter thing still doesn’t reach through to me, but I may just be spoiled with a great CMS with a great template system. There’s no PHP, RoR or Django (or whatever) clutter to think about, only simplified statements to print attributes, test if values are set and so on.

Our template system has grown more powerful the last year, so I can see the reasons to why this JS was made in the first place perfectly well — we did exactly the same thing. But, maybe it would have been more beneficial, in the long run, to spend some more time working on your back end once or twice, than to write these little JS snippets every time you stumble upon weaknesses and no-can-do’s in the system?

But of course, one have to work with what one has available (in many companies employees are locked to specific technologies, CMS’ and so on).

I certainly enjoy ‘spamming’ our internal bug report system whenever I’m not pleased with something, and only good things comes out of it. Except for tired, over-worked colleagues over at the product apartment, of course. :)

Joan Piedra said on 12/02 at 08:53 PM

Tony,

I understand and agree that the back-end shouldn’t output code (html code), and only content. The templates (aka views) should do the trick, but instead of having lot’s of if/else conditionals inside the view, you may just output the following content.

No information available

The template would loop in an array and put all the <li>’s inside the <ul>.
I don’t see anything wrong, nor difficult there.

Again, it’s a nice solution, I just feel it should be done in the back-end.
Regards,