{"id":511,"date":"2011-09-04T11:23:13","date_gmt":"2011-09-04T09:23:13","guid":{"rendered":"https:\/\/sgaul.de\/?p=511"},"modified":"2014-03-13T21:34:54","modified_gmt":"2014-03-13T20:34:54","slug":"j-query-projekte-mit-events-strukturieren","status":"publish","type":"post","link":"https:\/\/sgaul.de\/2011\/09\/04\/j-query-projekte-mit-events-strukturieren\/","title":{"rendered":"J-Query-Projekte mit Events strukturieren"},"content":{"rendered":"<p>Sobald es sich um mehr als ein kleines Aufklappmen\u00fc handelt, k\u00f6nnen J-Query-Projekte schnell gro\u00df und somit un\u00fcbersichtlich werden. Schon bevor es soweit ist, sollte man sich eine klare Struktur \u00fcberlegen. Es gibt unz\u00e4hlige Projekte im Web und somit auch viele verschiedene Vorlagen. Viele nutzen einfache Funktionsstrukturen, einzelne oder auch mehrere Klassen. Was mir bisher kaum \u00fcber den Weg lief: Mit eigenen Events bietet J-Query eine M\u00f6glichkeit, sauber und vor allem unabh\u00e4ngig zu modularisieren. Ganz im Stile des Observer-Patterns muss eine Datenquelle so nicht mehr wissen, wer genau an ihr interessiert ist.<!--more--><\/p>\n<h2>Verschiedene Funktionen auf verschiedene Listener aufteilen<\/h2>\n<p>Als Grundlage ben\u00f6tigt man zun\u00e4chst HTML. Dieses dient als Template, auf welches man dann mittels Javascript zugreifen kann. Hierbei sollte man beachten, \u00fcberlegt mit IDs und Klassen zu arbeiten. Ist ein Event-Listener wirklich nur f\u00fcr ein Element notwendig, ist die ID das beste Zugriffsmittel. Klassen sind aber wichtiger: Oft ist nicht klar, wie viele Elemente eine spezielle Funktionalit\u00e4t haben m\u00fcssen, daher sollte man f\u00fcr jede Funktion eine Klasse vergeben:<\/p>\n<pre lang=\"html4strict\"><div data-role=\"page\" id=\"page\">\r\n\t<button class=\"send-value exclusive\">Klick<\/button>\r\n<\/div><\/pre>\n<pre lang=\"javascript\">$('.send-value').click(function() {\r\n    \/\/ Button-Value mittels Ajax senden\r\n});\r\n\r\n$('.exclusive').click(function() {\r\n    \/\/ Andere Buttons mit Klasse exclusive deaktivieren\r\n});<\/pre>\n<p>Man erlangt so einen recht gut strukturierten Code, den man einfach wiederverwenden kann. Zudem vermeidet man riesige Funktionsk\u00f6rper in einem einzelnen Listener, in dem man sp\u00e4ter kaum etwas wiederfinden kann.<\/p>\n<h2>Code nach dem Laden der Seite ausf\u00fchren<\/h2>\n<p>Viele J-Query-Plugins bieten bereits eine recht breite Palette an Events, mit denen man arbeiten kann. Will man eigene Event-Ketten aufbauen, muss man in aller Regel nach dem Laden der Seite beginnen.<\/p>\n<pre lang=\"javascript\">$(function() {\r\n    \/\/ Dieser Code wird nach dem Laden der Seite ausgef\u00fchrt\r\n});<\/pre>\n<p>J-Query-Mobile hat hierf\u00fcr noch <a href=\"http:\/\/jquerymobile.com\/demos\/1.0b1\/#\/demos\/1.0b1\/docs\/api\/events.html\">einige andere Events<\/a>, die man stattdessen nehmen sollte:<\/p>\n<pre lang=\"javascript\">$('#page').bind('pageshow', function() {\r\n    \/\/ Dieser Code wird nach dem Laden der Seite ausgef\u00fchrt\r\n});<\/pre>\n<h2>Eigene Events ausl\u00f6sen: $.event.trigger<\/h2>\n<p>Oft kommt man mit den vorgegebenen Events nicht aus. Vor allem wenn man Code wiederverwenden will, muss man diesen oft in verschiedenen Situationen triggern. Ein Beispiel: Ein Listenupdate wird einmal nach dem Laden der Seite und dann immer wieder periodisch ausgef\u00fchrt. Daher ist es schlecht, die Update-Funktion in die Document-Ready-Event zu packen:<\/p>\n<pre lang=\"javascript\">$(function() {\r\n    $.event.trigger('updatelist');\r\n    window.setInterval(\r\n        function() {\r\n            $.event.trigger('updatelist');\r\n        }, 10000);\r\n});\r\n\r\n$('#list').bind('updatelist', function() {\r\n    \/\/ Das Listenupdate...\r\n});<\/pre>\n<p>Die Funktion <strong>$.event.trigger<\/strong> ist hierbei enorm wichtig, in der J-Query-Dokumentation aber kaum zu finden. Diese spricht immer nur von <em>$(selector).trigger(event)<\/em>, welche den Event auf einer konkrete Liste von gematchten Elementen ausl\u00f6st. Dies ist in aller Regel aber eine denkbar schlechte L\u00f6sung, da wir eben bei dem Triggern des Events nicht wissen wollen (und sollten), wer an diesem Event interessiert ist. $.event.trigger hingegen triggert den Event auf allen Elementen, die sich daf\u00fcr registriert haben.<\/p>\n<h2>Auf verschiedene Dateien verteilen<\/h2>\n<p>Da die Verteilung auf viele kleine Events zwar \u00fcbersichtlicher, aber keineswegs k\u00fcrzer ist, wird die entsprechende Javascript-Datei schnell sehr lang. Hier ist es daher empfehlenswert, die Funktionen irgendwie zu gruppieren und auf verschiedene Dateien aufzuteilen. Bei J-Query-Mobile hat man oft mehrere Einzel-Pages in einer Seite. Hier kann man f\u00fcr jede Einzelseite eine eigene Javascript-Datei erzeugen.<\/p>\n<p>Anschlie\u00dfend kann man den JS-Code dann serverseitig wieder zusammenfassen und komprimieren, um die Netzwerklast zu minimieren.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Sobald es sich um mehr als ein kleines Aufklappmen\u00fc handelt, k\u00f6nnen J-Query-Projekte schnell gro\u00df und somit un\u00fcbersichtlich werden. Schon bevor es soweit ist, sollte man sich eine klare Struktur \u00fcberlegen. Es gibt unz\u00e4hlige Projekte im Web und somit auch viele verschiedene Vorlagen. Viele nutzen einfache Funktionsstrukturen, einzelne oder auch mehrere Klassen. Was mir bisher kaum \u00fcber den Weg lief: Mit eigenen Events bietet J-Query eine M\u00f6glichkeit, sauber und vor allem unabh\u00e4ngig zu modularisieren. Ganz im Stile des Observer-Patterns muss eine Datenquelle so nicht mehr wissen, wer genau an ihr interessiert ist.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[91],"tags":[149,158,111,112],"_links":{"self":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts\/511"}],"collection":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/comments?post=511"}],"version-history":[{"count":11,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts\/511\/revisions"}],"predecessor-version":[{"id":537,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/posts\/511\/revisions\/537"}],"wp:attachment":[{"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/media?parent=511"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/categories?post=511"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sgaul.de\/wp-json\/wp\/v2\/tags?post=511"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}