netvibes - (re)mix the web

The main idea behind this series of articles is, as you’d have guessed by now, to take over the MiniAPI tutorial and push it into the 21st century, kicking and screaming show how easy it can be to get the same effects in UWA. The most acute readers among you would have noticed that we swiftly skipped over Step 3:

“Basically, Multiple Pages are to be replaced by the Pager or the TabView control depending on the initial usage, Markup remains strict XHTML, and Classic Forms will get a part of its own later.”

Well, no more skipping! Now that we’ve shown how to adapt classic forms in UWA, it’s time to take a few steps back and see about this Multiple Pages business that’s we’ve been avoiding for so long…

What used to be true might not be anymore

I’ve said time and again in this series: while a MiniAPI module could be based on a string of dynamic files, UWA recommends heartily that a widget be made of one static files (the data being get/set using Ajax requests). The reason bears repeating: while a MiniAPI module was designed to only work within the safe confines of a Netvibes user-page, a UWA widget is meant to work on many different platforms, which reaction in front of unexpected data you can never be certain of.

Hence, instead of have a MiniAPI module working within the safe confines of Netvibes, your UWA widget should be working within the safe confines of our recommendations:

• A UWA widget MUST use only one, valid XHTML static file
• This file MUST be XML well formed
• It MUST be UTF-8 encoded
• It must include the Netvibes widget namespace: xmlns:widget="http://www.netvibes.com/ns/"
• Any dynamic data MUST be retrieved using JavaScript/Ajax methods

We insist. Rrrrreally do.

Of course, you still do it the old way - just don’t be surprised if your users drop your widget because another one does work everywhere.

UWA does not leave you on your own

So what’s the alternative? How can you replicate linking pages of content together with a simple <a href=”" > tag (and relative URLs), as you do in classic XHTML webpages and did in MiniAPI?

Newcomers already know this from this post’s intro: Pager and TabView are the answers. They both are UWA controls, aimed at differents uses. We’ll see each right now…

Pager: when you have more than one page of data

With MiniAPI, when your data took more than one page to display, you had little choice but to display it on multiple pages (or one dynamic, self-updating page), linked together with your own “previous/next” buttons.

The idea behind UWA’s Pager is to normalize such uses, both code-wise and style-wise.

The code.
Since your widget gets its data using one of UWA’s Ajax methods, it’s only right to make use of that. As you can see in its doc, the Pager control takes a literal JavaScript object, a JavaScript array or the JSON data returned by the UWA.Data.getFeed() method. From there on, it only needs to know how many entries are to be displayed on each page (offset), and how at which offset you are currently.

The style.
UWA introduces a handful of templates, which help you keep you data styled in way that fits the current theme instead of relying on your own custom styles - and potentially look bad/inadequate. The Pager control includes such template, which contains normalized previous/next buttons. You don’t have to worry about proper look&feel, it does it for you.

Dive into the documentation, or see how we did it with the Twitter tutorial right on this blog.

TabView: when you want different kind of data displayed in one widget

Other use cases: you’d like to display more than one feed, separately, on your widget. Or even better: have it display a feed here, the local weather there, and maybe a third part with updates from your town’s webcam.

With MiniAPI, this was only possible by linking pages. With UWA, you can create tabs using the TabView control, each of which can contain any HTML content. In effect, it’s like having multiple widgets in one, accessible through a tab. You can have as many tab as you need - and even tab-menus for a given tab. Just remember that a tabs system should be the first thing coded into your widget, because adding tabs to an existing widget isn’t too easy.

As with the Pager control, TabView helps you by normalizing both code and styles.

Dive into the documentation, or see our blogpost presenting it, with a well-known example from last year.

Getting the best of both worlds

How can you possibly top that? By combining the two, of course! Once your widget has it tabs system set, you can fill the tabs with just about anything allowed with idea, which comprises HTML, Flash and other plugins… and a Paging system, if the tab’s content needs it. Again, the Rugby World Cup is an example of the wide possibilities offered by UWA. Try it!

Tags: conversion, miniapi, pager, tabview, uwa

This entry was posted on Friday, January 18th, 2008 at 6:46 pm and is filed under Articles, Tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.