Blog > Browser & Betriebssysteme

Da ich mir vor kurzem ein Android Smartphone (Motorola Milestone) zugelegt habe, war natürlich das erste was ich tun wollte, mit der Hardware spielen. Leider hab ich aus Zeitmangel nicht mehr als eine kleine Test-Applikation zustande gebracht. Das wird sich hoffentlich in den nächsten Wochen ändern.

Beim Herumspielen und Surfen mit den Android ist mir aufgefallen, dass so gut wie niemand seine Webseite für kleine Geräte optimiert. Manche Websites lassen sich schlicht mehr nicht bedienen. Dies ist mir schon mit dem eeePC aufgefallen und ich war ständig mit der horizontalen Scroll-Leiste beschäftigt. Es gibt aber auch Ausnahmen: alistapart.com beispielsweise lässt sich wunderbar bedienen!

Meine Webseite wird zwar korrekt auf dem Android dargestellt, allerdings ist sie dort total überladen. Und da ich auch zu den coolen Jungs gehören will, hab ich meine Seite auch dementsprechend optimiert. Surft man meine Seite mit einem mobilen Gerät an, gibt es nicht nur ein alternatives Stylesheet, sondern auch eine auf das Minimum abgespeckte Version des Inhalts dieser Seite. Maximaler Informationsgehalt für ein Minimum an Bytes sozusagen :-)

Da ich es leider nur auf einem einzigen Gerät getestet habe, kann es natürlich gut sein, dass es auf anderen Displays mit anderen Browsern und anderen Smartphones anders aussieht. Ich würde mich bei Darstellungsproblemen über eine kurze E-Mail sehr freuen - am Besten mit Bild.

Um die Webseite zu besuchen einfach auf aaron-mueller.de gehen oder diesen QR-Code scannen.

Vorgestern bin ich auf ein Problem gestoßen, an das ich noch nicht gedacht hatte: Es ist nicht möglich, eine Datei mit einem XMLHTTPRequest zu versenden. Grund dafür ist JavaScript, welches in der Browser-Sandbox läuft und nicht auf lokale Dateien zugreifen kann.

Doch wie hat das GMail gelöst? Hier werden Dateianhänge nach dem Auswählen ohne ein Neuladen der Seite hochgeladen. Nach ein paar Experimenten und etwas Hilfe von ajaxpatterns.com fand ich ein paar interessante Browsereigenschaften, mit denen man GET- und POST-Requests auch ohne das XMLHTTPRequest-Interface absetzen kann.

Der iFrame Tag

Die Idee ist Folgende: Wenn per JavaScript ein GET-Request abgesetzt werden soll, wird dynamisch ein iFrame erzeugt und dessen src-Attribut auf eine URL gesetzt, die dann aufgerufen wird. Die GET-Parameter können dann wie gewohnt in Form von ?p1=val1...&pn=valn an die Adresse angehängt werden. Um die Server-Response abzufangen, bekommt das iFrame eine onLoad-Funktion verpasst, die den Inhalt des iFrames extrahiert, weiterverarbeitet und das iFrame wieder löscht. Das iFrame dient hier als eine Art Kontainer zum Senden und Empfangen.

<script type="text/javascript">
function $(id) { return document.getElementById(id); }
function call() {
    var d = document.createElement('div');
    d.innerHTML =
        '<iframe id="iFrame" style="display: none;" ' + 
        'onLoad="callback()"></iframe>';
    document.body.appendChild(d);

    $("iFrame").src = "server.php?val=" + $("var").value;
}
function callback() {
    $("result").innerHTML =
        $("iFrame").contentDocument.body.innerHTML; 
    $('iFrame').parentNode.removeChild($('iFrame'));
}
</script>

<p id="result"></p>
<form onSubmit="call(); return false;">
    <input type="text" id="var" />
    <input type="submit" />
</form>

Mit dieser Technik hat man einen fast vollwertigen Ersatz für das XMLHTTPRequest-Interface. Manche Frameworks nutzen dieses Feature, um auch ältere Browser zu unterstützen.

Doch was tun, wenn der Browser keine iFrames unterstützt? Hier kann man sich einer ähnlichen Technik bedienen: Sobald man einem img-Tag das src-Attribut verpasst, versucht der Browser das Bild zu laden. Hier lässt sich wie im iFrame-Beispiel auch eine URL angeben die zu einem Script führt und Parameter anhängen.

var img = document.createElement('img');
img.setAttribute('src', 'server.php?p1=val1');

Dies ist natürlich ein one-way-ticket. Nach dem GET-Request kann der Server nur noch mit einem Bild antworten.

Und was ist mit POST?

Hier gibt es einen weiteren Trick, POST-Requests an den Server zu senden. Beim dynamischen Erstellen des iFrames fügt man diesem ein Formular hinzu, welches die Parameter als input-Tags beinhaltet. Mit JavaScript sendet man dann das Formular ab und extrahiert wiederum die Server-Response aus dem iFrame.

Einfacher geht es mit dem target-Attribut des form-Tags. Hier kann man ein iFrame als Target angeben. Das iFrame dient hier wiederum als Kontainer für das Abfangen der Antwort vom Server. Im folgenden wird wird die ausgewählte Datei auf den Server geladen:

<script type="text/javascript">
function $(id) { return document.getElementById(id); }
function call(form) {
    var d = document.createElement('div');
    d.innerHTML =
        '<iframe id="iFrame" name="iFrame" ' + 
        'style="display: none;" ' + 
        'onload="callback()"></iframe>';
    d.setAttribute('id', 'repository');
    document.body.appendChild(d);
    return false;
}
function callback() {
    $('result').innerHTML =
        $('iFrame').contentDocument.body.innerHTML;
    $('repository').parentNode.removeChild($('repository'));
}


<p id="result"></p>

<form method="post" enctype="multipart/form-data" 
    action="server.php" target="iFrame"
    onSubmit="call(this);">
    
    <input type="file" name="file" />
    <input type="submit" />
</form>

Auf Serverseite wird die Datei nur noch entgegengenommen und in das richtige Verzeichnis geschoben.

foreach ($_FILES as $f)
   move_uploaded_file($f['tmp_name'], "upload/".$f['name']);

Warum der Umstand?

Eigentlich erstaunlich, dass sich Web-Entwickler immer wieder solche dreckige Hacks einfallen lassen müssen, um ans Ziel zu kommen. Der Browser ist mittlerweile zum "Plattformübergreifenden Betriebssystem" mutiert, doch die Programmierung ist alles andere als komfortabel.

Mit dem neuen Google Browser Chrome kommt hoffentlich wieder etwas frischen Wind in den Browser-Markt. Ich warte derweil geduldig auf eine Linux-Version von Chrome.

Beim Surfen kommt es oft vor, das man zwar nicht viel Zeit hat, aber mal schnell den Reedreader durchgeht, ein paar Links folgt und etwas rumstöbert. Und oft hat man dann keine Lust/Zeit längere Artikel durchzulesen die man "grade gefunden" hat. Bisher hab ich dann die offenen Tabs in meinem del.icio.us mit dem Tag "toRead" verankert, oder schnell die Links per DragAndDrop aufs Desktop gezogen. Die Desktop-Verknüpfungen hat man dann noch präsent und kann sie auch schnell löschen, aber die Bookmarks in del.icio.us durchsuche ich seltenst nach dem "toRead"-Tag, und dann müsste ich das Tag wieder enfternen oder den Bookmark löschen. Alles ziemlich suboptimal.

Markus hat mir heute ein tolles Firefox-Plugin gezeigt, mit dem man solche Seiten in einem Stack speichern kann (einfach ein Icon drücken) um dann den Stack später durchzuarbeiten. Sehr praktisch das Teil!

Zeitzonen, Sommerzeit, Normalzeit, UTC, CET, MEZ und NTP, das ist absolut nicht mein Ding. Gerade hab ich mir ein kleines Makefile geschrieben um ein etwas größeres LaTeX-File nach PDF umzuwandeln, da sagt mir make:

Warning: File `Makefile' has modification 
   time 6.4e+03 s in the future

Ich schau auf meine Systemuhr: Alles ok. Dann wurde es mir klar: Mein Fileserver hat noch die Sommerzeit eingestellt. Und tatsächlich ging die Systemzeit vom Fileserver mehr als eine Stunde vor. Um dem für allemal vorzubeugen habe ich einen NTP-Daemon installiert, doch dieser gab mir eine Zeit die genau eine Stunde in der Vergangenheit lag und die Hardware-Uhr lag immer noch in der Zukunft.

root@datenpool:/etc# date
Wed Oct 31 19:38:08 UTC 2007
root@datenpool:/etc# ntpdate pool.ntp.org
Looking for host pool.ntp.org and service ntp
host found : pd907efc7.dip0.t-ipconnect.de
31 Oct 20:04:27 ntpdate[2097]: step time server 
   217.7.239.199 offset -6788.989946 sec
root@datenpool:/etc# hwclock --show
Wed Oct 31 22:58:56 2007  0.000000 seconds

Also musste ich mich doch mit all dem Kram beschäftigen, dabei wollte ich doch nur an meinem LaTeX-File weiterschreiben. Wieder mal voll verzettelt.

Der Fehler war dann, das die Zeitzone Europe/Berlin nicht gesetzt war und die Zeit in der Hardware-Uhr nicht erneuert wurde. Ich bin für die Abschaffung der Sommerzeit!

Warning: File `Makefile' ha




OpenOffice auch mit Word
vom 15. October 2007


	
Sun hat mit dem ODF Plugin (Version 1.1) eine Möglichkeit geschaffen, OpenOffice-Dateien auch mit MS Word, MS Excel und MS Powerpoint zu öffnen und zu speichern! Das ist der Moment auf den ich gewartet habe; Ab sofort werde ich keine Ausreden mehr gelten lassen, wenn ich OpenOffice-Dateien verschicke. Das Tool ist kostenlos und ~30MB groß.

Die Exportfunktion von OpenOffice-Dateien ins Microsoft-Equivalent hat bei mir nie 100% funktioniert. Vor allem bei Tabellen gab es sehr oft Probleme. Also wer noch Windows und Word auf seinem Rechner hat, sollte das Tool unbedingt installieren (und mir dann berichten wie es funktioniert :)



	5 Kommentare,
	
	
	del.icio.us,
	
	[Sun][1] hat mit dem [ODF Plugin][2] (Version 1.1) eine Möglichkeit geschaffen, OpenOffice-Dateien auch mit MS Word, MS Excel und MS Powerpoint zu öffnen und zu speichern! Das ist der Moment auf den ich gewartet habe; Ab sofort werde ich keine Ausreden 




Fluxbox 1.0
vom 10. October 2007


	
Lange hat es gedauert, doch nun ist es getan: Der Windowmanager Fluxbox ist in der Version 1.0 erschienen. Fluxbox wurde vor ca. 7 Jahren von Blackbox abgespalten und seit über 4 Jahren trug er 0.9x Versionsnummern. Ich werde am Wochenende mal einen Blick reinwerfen und anschauen was sich in den letzten Jahren so getan hat.



	Kommentar schreiben,
	
	
	del.icio.us,
	
	Lange hat es gedauert, doch nun ist es getan: Der [Windowmanager Fluxbox][1] ist in der Version 1.0 erschienen. Fluxbox wurde vor ca. 7 Jahren von [Blackbox][2] abgespalten und seit über 4 Jahren trug er 0.9x Versionsnummern. Ich werde am Wochenende mal