Heute gibt es einen Ausflug in die dunklen Kammern der "Quick and Dirty - getting it done"Heldendaten-Katakomben. Schon mal eine QlikView Extension programmiert? QlikView Workbench installieren, Property-Bags definieren, am Server deployen? Geht das nicht einfacher? Natürlich! Gibt es dafür Support: selbstverständlich nicht :-)
QlikView's "Full Browser Client" - vormals AJAX-Client oder ZeroFootprintClient - ist ein voller HTML5 Client. Auch der QlikView (Offline) IPAD-Client, der dieser Tage in Version 2.0 erschienen ist, startet im Onlinemodus innerhalb der App einfach den Safari Browser.
Will man den Client funktionell und/oder graphisch erweitern, so hat man in QlikView 11 die Möglichkeit Document- bzw. Object Extensions zu entwickeln. Stefan Walther schreibt darüber gerade eine Blogserie auf qlikblog.at. Meine liebste Spaß-Extension findet sich im QlikMarket und auf unserer Demo-Seite.
Irgendwann in den 90er-Jahren, als viele Javascript noch nicht von Java unterscheiden konnten, fand man manchmal folgende verbrecherische Syntax um einen Messagebox bei Klick auf einen Hyperlink anzuzeigen:
<a href="javascript:alert('Hallo Welt!');">Dein Link</a>
Lang vergessen, kann man sich diese Syntax in QlikView zu nutzen machen. Wie? Das lesen Sie in den nächsten zwei Abschnitten!
Während im Fat-Client und im IEPlugin QlikView die Darstellung selbst in der Hand hat (und somit auch "selbst" drucken kann), ist im AJAX-Client das Rendering via HTML an den Browser ausgelagert. Somit kann man sich auch nur auf den "Druck" des jeweiligen Browser-Herstellers verlassen. Das führte wohl dazu, dass der QlikView AJAX Client diese Aktion gleich komplett ignoriert.
Dieses Verhalten ist natürlich nicht ganz zufriedenstellend für einen Anwendungsentwickler der beide QlikView-Clients (IE-Plugin und AJAX) für seine Analysten bereitstellen muss. Während die IEPlugin-User den Button benutzen können, muss man den AJAX-Usern erklären, dass sie umständlich im Browsermenü den Druck anstarten müssen, oder am einfachsten gleich einen Screenshot machen.
Gibt es einen Ausweg? Ja, man könnte eine "Button"-Extension programmieren die den Browser-Druck mittels Javascript "window.print()" aufruft. Geht es auch Quick and Dirty? Ja, denn QlikView lässt eine Syntax zu, die ich eben seit den 90ern nicht mehr gesehen hatte:
Es gibt eine QlikView Aktion "URL Öffnen". Ich nehme an, dass diese Aktion gedacht ist um externe URLs, webbasierte CRMs oder etwa Documentmanagement-Systeme anzuspringen, und gegebenenfalls die aktuelle QlikView-Selektionen als GET-Parameter zu übergeben.
Interessanterweise schluckt diese Aktion aber auch folgenden Befehl: javascript:window.print()
Der Aufruf von JavaScript macht im QlikView-Fatclient keinen Sinn, da hier keine Interpretation des Befehls stattfindet. Um den Button wirklich nur im AJAX-Client anzuzeigen, benutzen wir die Clientplatform()-Funktion. Wer QlikView für das IPAD entwickelt hat, hat diese Funktion zum Erkennen der Browser-Plattform vielleicht schon benutzt:
![]()
FatClient und IEPlugin liefern einen leeren String für ClientPlatform(). Wir zeigen das Objekt also nur an wenn ein Browser kommt!
Der Test auf unsere Demo-Seite funktioniert: In QV11.20SR5 mit Firefox 27 und IE11 funktioniert meine "Poor Man's Print Extension".
PS: Um das Druckergebnis im Browser zu verbessern, sollten Sie den Druck der Hintergrund-Graphik aktivieren. Das ist in jedem Browser (ja sogar Browser-Version) ein wenig wo anders versteckt, hier die Einstellungen für IE11 und Browser.
In JavaScript gibt es dafür eine Funktion: window.scrollTo(0,0). Es bietet sich also wieder an eine Poor Man's Extension zu schreiben :-)
Hier kommt aber nun leider ins Spiel, dass diese Vorgehensweise von Seiten der QlikTech natürlich nicht supported ist. window.scrollTo(0,0) funktionierte wunderbar im Firefox, doch IE11 wehrte sich standhaft dagegen, nach oben zu scrollen.
Ein bisschen Code-Analyse des AJAX-Clients später stellte sich heraus, dass QlikTech sich scheinbar die Scrollposition merkt. Um also die Poor Man's Extension auch im IE11 lauffähig zu machen, muss ich die Aktions-Definition erweitern auf:
javascript:Qva.binders[""].ScrollLeftToRemember=null;window.scrollTo(0,0);
Bisher konnte ich keine Nebenwirkungen unseres Hacks feststellen. Der Button funktioniert in Firefox 27, IE11, Chrome 33 und auch am IPAD mit Safari. Die Benutzung ist natürlich trotzdem auf eigenes Risiko! Zum Testen und gibt es die Applikation wie immer auf unserem Demo-Accesspoint demo.heldendaten.net
QlikView's "Full Browser Client" - vormals AJAX-Client oder ZeroFootprintClient - ist ein voller HTML5 Client. Auch der QlikView (Offline) IPAD-Client, der dieser Tage in Version 2.0 erschienen ist, startet im Onlinemodus innerhalb der App einfach den Safari Browser.
Will man den Client funktionell und/oder graphisch erweitern, so hat man in QlikView 11 die Möglichkeit Document- bzw. Object Extensions zu entwickeln. Stefan Walther schreibt darüber gerade eine Blogserie auf qlikblog.at. Meine liebste Spaß-Extension findet sich im QlikMarket und auf unserer Demo-Seite.
Poor Man's Extensions
Ich weiß gar nicht ob es ein Feature ist, oder ein Bug. Ich weiß auch gar nicht wie ich auf die doofe Idee kam. Aber seit ich es in QlikView entdeckt habe, nenne ich es "Poor Man's" Extensions :)Irgendwann in den 90er-Jahren, als viele Javascript noch nicht von Java unterscheiden konnten, fand man manchmal folgende verbrecherische Syntax um einen Messagebox bei Klick auf einen Hyperlink anzuzeigen:
<a href="javascript:alert('Hallo Welt!');">Dein Link</a>
Lang vergessen, kann man sich diese Syntax in QlikView zu nutzen machen. Wie? Das lesen Sie in den nächsten zwei Abschnitten!
Poor Man's JavaScript Print Extensions
In QlikView gibt es einige Aktionen die vom AJAX-Client ignoriert werden. Ein Beispiel ist die "Arbeitsblatt drucken"-Aktion. |
| Diese Aktion wird vom AJAX-Client ignoriert |
Während im Fat-Client und im IEPlugin QlikView die Darstellung selbst in der Hand hat (und somit auch "selbst" drucken kann), ist im AJAX-Client das Rendering via HTML an den Browser ausgelagert. Somit kann man sich auch nur auf den "Druck" des jeweiligen Browser-Herstellers verlassen. Das führte wohl dazu, dass der QlikView AJAX Client diese Aktion gleich komplett ignoriert.
Dieses Verhalten ist natürlich nicht ganz zufriedenstellend für einen Anwendungsentwickler der beide QlikView-Clients (IE-Plugin und AJAX) für seine Analysten bereitstellen muss. Während die IEPlugin-User den Button benutzen können, muss man den AJAX-Usern erklären, dass sie umständlich im Browsermenü den Druck anstarten müssen, oder am einfachsten gleich einen Screenshot machen.
Gibt es einen Ausweg? Ja, man könnte eine "Button"-Extension programmieren die den Browser-Druck mittels Javascript "window.print()" aufruft. Geht es auch Quick and Dirty? Ja, denn QlikView lässt eine Syntax zu, die ich eben seit den 90ern nicht mehr gesehen hatte:
Es gibt eine QlikView Aktion "URL Öffnen". Ich nehme an, dass diese Aktion gedacht ist um externe URLs, webbasierte CRMs oder etwa Documentmanagement-Systeme anzuspringen, und gegebenenfalls die aktuelle QlikView-Selektionen als GET-Parameter zu übergeben.
Interessanterweise schluckt diese Aktion aber auch folgenden Befehl: javascript:window.print()
 |
| Quick&Dirty: Javascript in Qlikview |
FatClient und IEPlugin liefern einen leeren String für ClientPlatform(). Wir zeigen das Objekt also nur an wenn ein Browser kommt!
Kleiner Tipp am Rand
Hat man die Anzeigefunktion definiert, so verschwindet der Button natürlich sofort im QlikView-Developer. Wenn Sie den Button während der Entwicklung sehen möchten, zeigt der Shortcut CTRL+SHIFT+S alle Objekte (und damit auch den Button) an! Vor dem Speichern bitte wieder CTRL+SHIFT+S, damit das normale Verhalten wieder hergestellt ist.
Hat man die Anzeigefunktion definiert, so verschwindet der Button natürlich sofort im QlikView-Developer. Wenn Sie den Button während der Entwicklung sehen möchten, zeigt der Shortcut CTRL+SHIFT+S alle Objekte (und damit auch den Button) an! Vor dem Speichern bitte wieder CTRL+SHIFT+S, damit das normale Verhalten wieder hergestellt ist.
Der Test auf unsere Demo-Seite funktioniert: In QV11.20SR5 mit Firefox 27 und IE11 funktioniert meine "Poor Man's Print Extension".
 |
| IE 11 Druckdialog öffnet sich |
 |
| Firefox Hintergrund drucken |
 |
| IE 11: Hintergrundfarben und -bilder drucken |
Poor Man's JavaScript ScrollUp Extension
Vor kurzem erhielt wir eine weitere Anfrage: Ein Kunde hat eine Applikation die sehr viele Diagramme nach unten anzeigt. Daraus resultiert ein langer vertikaler Scrollbalken. Kann man es bewerkstelligen, dass der User mittels eines Buttons wieder ganz rauf zum Start der Applikation springt?In JavaScript gibt es dafür eine Funktion: window.scrollTo(0,0). Es bietet sich also wieder an eine Poor Man's Extension zu schreiben :-)
Hier kommt aber nun leider ins Spiel, dass diese Vorgehensweise von Seiten der QlikTech natürlich nicht supported ist. window.scrollTo(0,0) funktionierte wunderbar im Firefox, doch IE11 wehrte sich standhaft dagegen, nach oben zu scrollen.
Ein bisschen Code-Analyse des AJAX-Clients später stellte sich heraus, dass QlikTech sich scheinbar die Scrollposition merkt. Um also die Poor Man's Extension auch im IE11 lauffähig zu machen, muss ich die Aktions-Definition erweitern auf:
javascript:Qva.binders[""].ScrollLeftToRemember=null;window.scrollTo(0,0);
Bisher konnte ich keine Nebenwirkungen unseres Hacks feststellen. Der Button funktioniert in Firefox 27, IE11, Chrome 33 und auch am IPAD mit Safari. Die Benutzung ist natürlich trotzdem auf eigenes Risiko! Zum Testen und gibt es die Applikation wie immer auf unserem Demo-Accesspoint demo.heldendaten.net
 |
| Die Aktion für ScrollUp im IE11, Firefox 27 und IPAD IOS7 |
 |
| Die ScrollUp-Applikation in ihrer vollen Pracht. Der Poor Man's ScrollUp Button ganz unten. |