protofunc()

Die jQuery UI-Widget-Factory am Beispiel einer Canvas Map: Teil I

Tags: deutsch, javascript, jquery, tutorial

Wir müssen nicht mehr lange warten und jQuery UI 1.5 wird ist released. Neben einigen Komponenten und hübschen Effekten, bietet der Core eine – für Plugin-Autoren – interessante Widget-Factory, welche ich mal am Beispiel einer Canvas Imagemap näher unter die Lupe nehmen möchte. Als erstes sollte man sich daher die neuesten Versionen von jQuery, UI und explorercanvas (wir wollen ja, dass die Beispiele auch ein bisschen im IE funktionieren.) besorgen. Hier findet ihr eine - zugegebenermaßen - häßliche Demo des einfachen CanvasMap-Plugins (ich bin kein Grafiker und scheitere bereits bei Imagemaps :-).

Die HTML Struktur und das CSS

Bevor wir anfangen solltet ihr einen kleinen Blick in das HTML werfen. Ihr werdet sehen, dass wir erstens ein Bild mit der Karte Berlins haben und zweitens ein transparentes Bild, welches die eigentliche ImageMap darstellt. Der Grund hierfür ist einfach. Canvas erzeugt anders als SVG richtige Pixelgrafixen. Man kann hier leider keine Events, wie beispielsweise mouseover gezielt abfangen. Wir brauchen daher eine darüber liegende Interaktionsebene für den User.

Was macht die Widget-Factory?

Im Prinzip macht die Widget-Factory nicht sehr viel, aber sie macht es geschickt. Sie erstellt aufgrund eines – von uns zu definierenden - „Prototypen-Objekts“ ein ordinäres jQuery-Plugin und eine JS-Klasse. Das jQuery-Plugin dient hierbei als Initialisierungs- und Zugriffs-“Controller“ für die definierte Klasse. Um das folgende Tutorial zu verstehen sollte man also Grundkenntnisse in JavaScript-OOP besitzen.

Der Grundaufbau eines jQuery Widgets könnte so aussehen:

Die Widget-Factory erstellt uns nun die gewünschte Klasse und das jQuery-Plugin:
Mit folgendem Ausdruck können wir unsere Klasse instantiieren:

Innerhalb unserer Instanzmethoden können wir auf das #map-Element mit this.element (Es handelt sich hierbei um ein jQuery-Objekt von #map.) und auf die Optionen mit this.options zugreifen (d.h. also this.options.defaultOptionB enthält den String ‘ mein Freund’ und defaultOptionA ist weiterhin der default-Wert ‘Hello’).
Wenn wir unsererem Widget ganz zu Anfang noch einige Dinge mitgeben möchten wie z.B. CSS-Klassen setzen, Events-Binden, zusätzliche Elemente hinzufügen, können wir eine Instanzmethode namens init definieren. Diese wird automatisch vom Constructor unserer Klasse aus aufgerufen (Den Constructor selbst liefert die Widget-Factory.).

Startcode unserers Canavasmap-Widgets

Wir wollen später das unser Widget wie folgt aufgerufen werden kann:

Das #map-Element ist hierbei nicht die Imagemap selbst, sondern ein Container, welcher die Bilder und die Imagemap umfasst.

Als erstes erstellen wir unseren Namespace (pf für pfrotofunc) und definieren die 1. Methode sowie unsere Defaults für unser Plugin namens canvasmap. In der Initialiserungsmethode erstellen wir ein Canvas-Element fügen es in einen div-Container und platzieren es vor das Imagemapbild. Der Container ist für das später auszuführende explorercanvas notwendig. Als nächstes überprüfen wir, ob das Canvas-Malobjekt (this.canvas[0].getContext) zur Verfügung steht.
Wenn dem nicht so ist, haben wir es wahrscheinlich mit dem IE zu tun und rufen G_vmlCanvasManager.initElement auf dem Element auf, wandeln es in ein jQuery-Objekt und speichern es in unsere canvas Eigenschaft.

Nach einer weiteren „Sicherheitsabfrage“ speichern wir unser Malobjekt in this.ctx und binden unsere Events.

Da die Browser recht unterschiedlich mit Events bei Imagemaps umgehen, belegen wir sowohl das Bild als auch die einzelnen areas der Imagemap mit dem click und mouse-over/out – Event und da wir unobtrusiv und barrierearm arbeiten, stellen wir den Mausevents noch focus- und blur-Events zur Seite.

Der aufmerksame Betrachter wird feststellen, dass die Eventhandler, die gebindet wurden, noch gar nicht existieren. Hierzu kommen wir aber zum Schluss zurück, wenn der übrige Aufbau unserer Klasse feststeht.

Die weiteren Instanzmethoden

Die nachfolgenden Methoden werden – wie die init-Methode - ebenfalls im Canvas-Prototypen-Objekt gespeichert und mit der $.widget-Factory in eine Instanzmethode unserer $.pf.canvasmap-Klasse umgewandelt.

1. Die getArea-methode

Da wir - wie oben gesehen haben - unsere Events auch auf das Bild gelegt haben, aber wir natürlich mit der jeweiligen area-Arbeiten müssen (hier stehen nämlich die wesentlichen Informationen zum Malen drin.), müssen wir aus unserem Event die area extrahieren.

Die getArea-Methode bekommt sowohl das Event-Objekt als auch das DOM-Element von unserem Eventhandler übergeben und muss nun entscheiden, welches von beidem die gewünschte Image-Map area enthält. Sofern sie keine area findet, ist irgendetwas schief gelaufen und sie gibt false zurück.

2. Die getCoords-Methode

Aus unserer Area müssen wir nun die einzelnen Koordinaten, welche im Attribut coords durch Komma separiert gespeichert sind, extrahieren. Daneben müssen wir das ganze noch in Zahlen umwandeln. Wir speichern das ganze dann in ein Array ab und geben es zurück.

3. Die drawArea-Methode

Nun sind wir kurz vor dem eigentlichen Mal-Vorgang. Wir benötigen für unser Beispiel nur den Shape-Typ ‘poly’, wir wollen aber später evtl. noch weitere Typen hinzufügen. Daher enthält unsere drawArea-Methode gar nicht den eigentlichen Mal-Code, sondern lediglich die Entscheidung, ob wir den Shape-Typen unterstützen und welche Mal-Methode aufgerufen werden soll:

Die Methode extrahiert also den Shape-Typ aus der Area, überprüft ob wir eine solche Methode definiert haben und wenn ja übergibt drawArea die Koordinaten sowie die Maloptionen an die eigentliche Mal-Methode.

4. Die poly-Methode

Nun malen wir aber wirklich:

Als erstes sagen wir unserem Malobjekt, was wir malen wollen. Dann bewegen wir unseren Zeichenstift zur ersten Koordinate. Danach gehen wir das Array bei 2 beginnend, immer um zwei Schritte durch und ziehen unsere Linien. Sobald wir hiermit fertig sind, ziehen wir unsere Verbindungslinie zwischen End- und Anfangspunkt. Und zuletzt Füllen wir unsere gezeichneten Linien unseren übergebnenen Optionen (o) entsprechend aus und zeigen eine Border an.

5. Die drawClickArea-Methode

Um den Sinn der letzten Methode zu verstehen, muss man etwas zu canvas wissen. Es handelt sich wie gesagt um Pxielgrafiken. Man kann also nicht einfach sein Malobjekt verändern, sondern muss mit jedem Schritt das gesamte Bild löschen und von neuem anfangen. Gleichzeitig wollen wir aber, dass ein angeklickter Bereich auch dann noch gehighlightet wird, wenn man mit der Maus drüber fährt. Dafür speichern wir unseren geklickten Bereich in unserer Objektinstanz unter der Eigenschaft ‘ clickArea’ ab und rufen diese Methode beim hovern regelmäßig auf.

Nun haben wir alle Methoden zusammen und können uns den noch fehlenden Event-Handlern widmen:

Wie ihr seht löschen wir innerhalb dieser Funktionen das Canvas und rufen letzlich immer nur die bereits oben definierten Methoden auf.

Das Zwischen-Ergbenis unseres Canvasmap-Plugins.

Und was habe ich davon?

Dies werden sich nun einige fragen. Als 1. haben wir objekt-oriientierten Code hinterlassen. Dies hat in verschiedener Hinsicht Vorteile. So haben wir beispielsweise alle Zustände und Eigenschaften aus der DOM-Map sauber in unserer Objektinstanz zwischengespeichert. Die Eigenschaft areas zeigt beispielsweise nur auf die Areas unserer einen Imagemap, selbst wenn wir mehrere Imagemaps auf unserer Seite haben und diese mit unserem Plugin behandeln.

Einige jQuery-Plugin Autoren werden nun aufschreien und konstatieren, dass sie den selben Effekt mit der herkömmlichen Architektur ebenfalls hin bekommen. Dies stimmt tatsächlich. Je nachdem, ob man Funktion oder Variable außerhalb oder innerhalb der this.each-Funktion definiert, erreicht man einen derartigen „Speicherzustand“ entweder für alle DOM-Elemente des aktuellen jQuery-Objekts innerhalb seines Plugins oder für jedes einzelne DOM-Element innerhalb des Plugins.

Das hängt stark mit der Funktionsweise von Closures zusammen. Das Problem hierbei ist, dass eine Menge hilfreicher Funktionen und Variablen privat sind und schwer von außen zugänglich gemacht werden können.

Stellt euch beispielsweise mal vor euer Kunde kommt auf euch zu und will nun eine weitere Funktionalität implementiert haben. Ausserhalb der Imagemap soll eine Legende mit Kontrollelementen erscheinen. Sobald der User auf eines dieser Elemente klickt, soll ein bestimmter Stadtteil gehighlightet werden. Die gesamte Funktionalität habt ihr ja im Prinzip geschrieben.

Der Autor, welcher die herkömmliche Schreibweise von jQuery-Plugins benutzt hat, wird nun erklären, dass er für das Hinzufügen der neuen Funktionalität eine halbe Stunde benötigt. Daneben wird ihm – vorausgesetzt er steht auf sauber organisierten Code – der Kopf rauchen wie er diese Funktionalität sauber und flexibel in sein Plugin und möglichst als Option integriert.

Der Widget-Factory-Autor wird selbstverständlich selbiges behaupten, braucht aber beispielsweise keine Zeit sich zu überlegen wie er seinen Code nun neu organisieren muss und hat noch genügend Zeit für eine oder zwei Kippen :-).

Zugriff von außen

Die UI-Factory Methode fügt unserem jeweiligen DOM-Element unsere Objektinstanz - ähnlich einem DOM-Expando (nur Memory Leak sicher) - hinzu. Wir haben daher auf unsere gesamte Objektinstanz mit folgendem Ausdruck Zugriff.

In der Regel werden wir dies nicht benötigen, da die Factory uns eine sehr schöne Möglichkeit bietet einzelne Methoden von aussen zu erreichen. Hierbei ruft man das normale jQuery-Plugin auf und übergibt als 1. Parameter den Namen der Instanzmethode. Alle weiteren Parameter werden ebenfalls als Parameter an die Methode weitergegeben:

Dieser Code sagt also nichts anderes als: Mal die area mit der id ’spandau’ mit folgenden Optionen aus.

Einfacher geht es nicht oder? Demo für den Zugriff von außen.

Ausblick auf Teil II des Tutorials

Neben der Widget-Factory hat sich das UI-Team auch Gedanken darüber gemacht, wie die „Aussenwelt“ über entscheidende Zustandsänderungen innerhalb des Widgets informiert werden und wie man ein Widget modularisieren kann, um beispielsweise den Widget-Core klein zu halten oder um Dritten die Möglichkeit zu geben die Funktionalität zu erweitern/abzuändern, ohne dass eine Zeile des Original-Codes verändert werden muss. Wie man sein eigenes Widget derartig „pimpen“ kann soll der zweite Teil zeigen.

Written June 8, 2008 by
alexander farkas

Controlling Embedded Video with Javascript Part I: Quicktime

Tags: english, javascript, tutorial, video

This is the first part in a little series of articles about scripting the controls of video with Javascript. I worked on a project recently where using flash for video was not an option, but instead all other major formats/plugins had to be supported (quicktime, windows media player, real player, vlc player). While researching for this project, I noticed that there was a certain lack of easily accesible information about this topic, especially concerning cross-plugin and cross-browser functionality. That’s why I decided to write these articles, maybe they can help someone who’s trying to do something similar.

Javascript can be used to control nearly every aspect of the mentioned plugins’ behaviour. Usually the reason for scripting video plugins will be to create a custom control interface, while the standard controls are hidden. One should think very carefully about this from a usability perspective, because most users will be more familiar with the standard controls. Also there will always be certain (older) browsers-plugin-combinations that will not behave as expected, possibly preventing certain users from accessing the content. Therefore it’s always a good idea to have some sort of fallback plan (i.e. show standard controls if Javascript is deactivated… think graceful degradation).

This first article will cover the Quicktime plugin, followed shortly by WMP, Real, and VLC. Below is a list of desired features that should ideally work across all plugins and browsers. The approach I want to take is to create a common interface of functions covering the desired features and implement the interface for each plugin (view the interface functions - Note: This is an interface by convention only, it is not enforced through code). That way the underlying plugin can be easily swapped without changing much code. See the Quicktime scripting demo page for a working example.

List of desired features:

  1. cross-browser embedding with standard interface deactivated
  2. basic playback controls: play, pause, stop
  3. display current time, duration, and status information
  4. jump to specified time within movie
  5. volume control
  6. change/load movie
  7. buffering
  8. fullscreen display

Embedding Quicktime

To begin with we must embed the quicktime plugin properly so that it works in all major browsers (Quicktime version 7.4 as of writing). I won’t go into much detail here, since this has been covered sufficiently elsewhere (i.e. here or here). This is the method that I’ve used:

In order to avoid the <embed> tag, which is non-standard (i.e. won’t validate), there are ways to use nested <object> tags instead (see A List Apart Articles: Bye Bye Embed), but I could not get the scripting to work properly in that case (any evidence of the contrary would be greatly appreciated…).

Note: This method of embedding the Quicktime plugin does not address the ActiveX activation issue in Internet Explorer – therefore you will currently need to click on the video once in order to activate it. It seems though that Microsoft is finally going to change the behaviour of embedded controls so that this won’t be an issue any longer after April 2008 (see: IEBlog: IE Automatic Component Activation (Changes to IE ActiveX Update)).

Basic Scripting

So let’s get started with the scripting, this is going to be pretty basic stuff – I might cover more advanced topics in separate articles. Note that the presented code is not fully optimized and I’ve ommited safety checks in order to preserve simplicity.

The first thing we need to do is to get a reference to the video object. The easiest way to do this, assuming the embed technique described above is being used, is to give the object tag an ID and the embed tag a NAME with identical values. That way the video can simply be accessed by its name:

In this case Internet Explorer will use the ID attribute and all other browsers the NAME attribute. Once we have a reference to the actual video, we can start manipulating it – the basic playback controls would look something like this:

Before actually manipulating the movie it is usually a good idea to check the status of the movie to make sure that it is ready for action. Otherwise if you try to access the video too early before it has loaded, Javascript errors can occur. The following method will return a string with the status of the movie:

It’s safe to access the movie, if the status is either “Playable” or “Complete”. The returned string will have one of these values:
“Waiting” - waiting for the movie data stream to begin
“Loading” - data stream has begun, not able to play/display the movie yet
“Playable” - movie is playable, although not all data has been downloaded
“Complete” - all data has been downloaded
“Error: ” - the movie failed with the specified error number

The next two functions show how to access the current playback time and the duration of the movie. The thing to note here is that the time returned by “GetTime()” and “GetDuration()” are in the movie’s time scale units. In order to convert this to seconds one needs to divide it by the time scale (units per second). This will then give you the time in seconds, usually you will then want to convert this into a nicely readable string format (something like: hh:mm:ss).

In order to set the movie to a specific position, one basically has to do the opposite – multiply the movie’s timeScale with the desired position in seconds. Note that the time cannot be set beyond what has currently been buffered - if you attempt to do this it will set the time to the last buffered frame.

The volume within Quicktime has a range of 0 – 255. I will convert this to be within a range of 0 – 100, because I think it is easier to work with in that range.

To swap the movie that’s being played, just set a new URL. For some reason Quicktime will show the default controller again if you change the URL – so in order to keep it hidden, you will need to manually hide it again.

When a new movie is initially loaded it will be buffered into memory. It can be useful to give some feedback about the buffering status of a movie. The following function will return the percentage of the movie that has been buffered (0 – 100%):

As for full screen mode, it is currently (to my knowledge) not possible to invoke Quicktime’s internal full screen mode for embedded movies - even though since version 7.2 it has become a feature of the free standalone player.

That about wraps it up, check out the demo page and feel free to post any questions or feedback.

Links

Written February 1, 2008 by
boris