Kategorie: Uncategorized

  • Javascript Delegation

    Mittels Javascript lassen sich sehr angenehmen Web Applikationen bauen -> aber ich muss sagen, es ist auch nicht ganz so einfach und ich bin kein Fan davon. Vor einigen Jahren kam das Paradigma auf, dass man Events an HTML Objekte anhängt. Mit JQuery sah das dann etwa so aus:

    $('#id').click(function(){…});

    Beim Click auf Container #id wird jetzt die spezifizierte Funktion ausgeführt. Das funktioniert auch sehr gut, ausser, wenn AJAX oder meistens AHAH ins Spiel kommt. Der Ablauf beim sog. Binding ist nämlich wie folgt:

    Seite wird geladen, dann werden die Funktionen an die Objekte gebunden und dann wird gewartet. Wenn jetzt noch weitere Objekte dynamisch via AHAH hinzukommen, oder ersetzt werden, dann ist natürlich diese Funktion nicht mehr ans Element gebunden und die ganze Funktionalität bricht ein.

    Lösung wäre, diese Binding nachträglich durchzuführen, was jedoch meistens nicht sehr praktisch ist. Daher gibt es ein neues Paradigma: Delegation. Ich muss sagen, dass ich davon nicht wirklich eine Ahnung habe, aber ich verstehe die Grundidee:

    Ein Event wird an einen Container Parent Container (nicht direkt an das Element) gebunden -> z.B. das Body Tag. Beim Click auf den Container wird dann sozusagen geschaut, ob das geklickte Element ein Element ist, auf welchem man eine Aktion ausführen möchte. Das wäre dann einfach so was wie ein Switch statement wo gecheckt wird. Wenn jetzt im Container drin HTML Objekte verändert werde (sprich neue Element hinzukommen), dann spielt das gar keine Rolle, da ja ein Event an den Parentcontainer gebunden ist und erst beim Klicken dynamisch geschaut wird, was passieren soll und mit welchem Objekt.

    Ich verwende im Moment ein JQuery Plugin Delegate, welches auch ganz praktisch ist und das ganze Handling übernimmt. Super genial, aber ein bisschen gewöhnungsbedürftig.

    Also, dieses Post soll in keiner Weise versuchen zu erklären, was Delegation ist, aber wenigstens ein Denkanstoss sein. Detaillierter und bessere Erklärungen gibt es viele im Netz und falls jemand gerne Widersprechen möchte: nur zu!

  • Massenuploader für Fast Gallery

    So, Ferien sind vorbei und ich konnte mal wieder ein paar freie Minuten finden, um ein wenig am Fast Gallery zu programmieren. Der Fileupload nur per FTP kann manchmal ein bisschen nervig sein, besonders, wenn man gerade nicht zuhause ist und keinen FTP Client zur Hand hat. Zudem ist er für weniger erfahreren Benutzer nicht sehr Bedienerfreundlich.

    Daher habe ich mich mal an die Arbeit gemacht und den JumpLoader integriert (Screenshots). Ein richtig cooles Teil. Zwar kämpfe ich noch ein wenig mit einer open_basedir() Restriction beim Fileupload, aber da werde ich hoffentlich auch noch drum kommen.

    Falls jemand hier Erfahrung mit Fileupload hat, kann er sich gerne bei mir melden. Es ist wahrscheinlich keine grosse Sache, aber sie muss halt gemacht werden. In der Dev Version ist bereits der aktuellste Code drin.

  • Internet Agenturen im Raum Basel

    Ich schaue mich gerade ein wenig um, was es denn für Arbeitsmöglichkeiten im Webbereich gibt. Dabei schaue ich mir vor allem Agenturen an, z.B. die unic oder namics. Sehr sympatische Firmen, aber gibt es auch etwas in der Region Basel, oder pulsieren in der Schweiz die Internetadern vor Allem in Zürich?

    Kennt jemand etwas in der Region Basel???

  • Warning: Got a packet bigger than ‹max_allowed_packet›

    "Warning: Got a packet bigger than 'max_allowed_packet' bytes query: INSERT INTO watchdog"

    Irgendwie wurde ich nicht schlau aus dieser Meldung, habe aber dann rausgefunden worum es sich handelt.

    Was ist max_allowed_packet? Ich bin dem nicht ganz auf den Grund gegangen, aber es geht irgendwie darum, wenn irgend ein serialisierter String (oder Bild oder was weiss ich) in der Datenbank gespeichert wird und dadurch diesen max_allowed_packet überschreittet. Dieser ist bis MySQL 3.23 auf maximal 16MB beschränkt, wurde danach auf 1GB erhöht (will aber nicht heissen, dass dieser auf allen Hostings so hoch ist.

    Bei mir trat das Problem auf, als ich via Devel modul ein dsm($rows) Befehl aufgerufen habe. Das Problem war, dass $rows ein Array war, welches 1000 weitere Arrays hielt. dsm() funktioniert so, dass es in irgend einer Tabelle gespeichert wird und dann auf der nächsten Seite ausgeben wird. Anscheinend war der Wert jedoch zu gross, was zu dieser Fehlermeldung führt.

    Auf drupalcenter gibt es auch eine Diskussion darüber.

    Das mag jetzt nicht das beste Post sein, aber es hilft vielleicht, in die richtige Richtung zu zeigen.

  • Gewicht eines Moduls – Hook greifen zu spät

    Schon mal das Problem gehabt, dass beim hook_nodeapi die Daten von einem Modul noch nicht vorhanden waren? Z.B. Modul A, lädt über hook_nodeapi gewisse Daten und fügt diesem dem Node Objekt hinzu. Modul B will auf diese Daten zugreifen, die Daten sind jedoch noch gar nicht vorhanden.

    In dem Fall wird der hook_nodeapi von Modul B VOR dem hook_nodeapi von Modul A aufgerufen. Es wird wohl jedem einleuchten, dass der Zugriff nur seriell möglich ist und daher einer der Anfang machen muss.

    Abhilfe? Ist ziemlich einfach. In der Tabelle system ist jedes Modul aufgelistet. Dort muss man jetzt lediglich schauen, dass das Gewicht des Modul je nach dem schwerer oder leichter ist. In unserem Fall müssten wir also sicherstellen, dass Modul B NACH Modul A aufgerufen wird. Module B muss als ein Gewicht bekommen, welches tiefer ist als Modul A, z.B. -1

    That's it. Man muss halt schauen, dass man dadurch nicht anderen Modulen in den Weg kommt.

  • Issue Tracker

    Wer schon mal an einem Projekt gearbeitet hat, an dem mehr als 1 Person beteiligt war, der weiss, wie schwierig die Koordination manchmal sein kann. Alleine? Kein Problem. Man hat einen Bug gefunden -> Schnell flicken oder irgendwo auf ein Post-it schreiben und dann später flicken.

    Was aber, wenn mehrere Entwickler beteiligt sind? Beta Tester? End-Kunden? Dann wird es spätestens so nicht mehr haltbar, denn:

    Der Beta Tester findet einen Fehler. E-Mail schreiben an den Entwickler, aber es gibt ja vielleicht mehrere Entwickler. So nimmt das Chaos seinen Lauf. Daher ist es eigentlich absolut notwendig, einen Issue Tracker zu haben. Natürlich sind auch noch andere Dinge notwendig, z.B. SVN/CVS Server, falls neue Module geschrieben werden und ein Testserver. Möchte jedoch ein bisschen näher auf den Issue Tracker eingehen.

    Was ist ein Issue Tracker (oder auch Bug tracker)? Nun, es ist ganz einfach ein Tool, welches Bugs (Fehler) verwaltet. Ein klassisches Usecase sieht wie folgt aus: Der Beta Tester findet einen Fehler. Er geht zum Bug Tracker und erstellt dort einen neuen Bug (meistens werden diese mit diversen Metadaten gekennzeichnet, unter anderem der Status und die Priorität). Einer der Entwickler kann sich dem Bug widmen und dran arbeiten und über den Status alle anderen Projektteilnehmer darüber informieren.

    Drupal.org ist ein rieser Bug Tracker. Z.B. vom Fast Gallery Modul. Füe jedes Modul ist os ein Bug Tracker vorhanden. Ein Bug Tracker ist jedoch nicht nur für Entwickler sinnvoll, sondern auch für Leute, welche mittels Drupalmodulen eine Seite bauen. Beispiel:

    Ich bin gerade daran eine grössere Plattform für die Verwaltung eines grösseren Bauprojektes am Bauen. Das ganze ist recht kompliziert mit OG, CCK und Views und diversen von OG abhängigen Berechtigungen. Das Projekt ist sehr prototypisch, da der Kunde zum ersten Mal eine solche Plattform einsetzen will. Daher sind auch die Bedürfnisse überhaupt nicht klar definiert. Anforderungen können von Tag zu Tag ändern und es kommen halt auch manchmal Fehler vor: Beschriftung nicht so wie sie sein sollte, Views nicht praktisch, Inhaltstyp braucht noch ein Feld mehr usw.

    Ohne Bug Tracker wäre das Projekt schon lange gestorben. Der Bug Tracker ist der ruhende Pol im Projekt. Er ist auch eine Quelle, welches Vertrauen fördert, da der Kunde sehen kann, dass etwas gemacht wird. Auch wenn vielleicht ein Fehler nicht behoben werden kann, können schon mal Informationen dazu gegeben werden.

    Was sind die wichtige Features eines Bug Trackers:

    • Prioritäten setzen
    • Status setzen
    • Möglichkeit notifications zu verschicken (per E-mail)

    Das ist es eigentlich auch schon. Drupal Project ist eigentlich wunderbar dafür geeignet. Im Moment ist es nur für D5 erhältlich, aber es wird eifrig an einer D6 Version gearbeitet. Aber auch eine D5 Version ist vollkommen ausreichend. Es ist ja lediglich ein Arbeitstool, welches die Funktionalität bringen muss.

    Im Moment setze ich für jedes Projekt einen neuen Bug Tracker auf. Mein Ziel wäre eigentlich, eine Plattform, welche mehrere Projekte verwalten kann. Mehrere Projekte ist kein Problem (siehe Drupal.org), aber es müssen entsprechende Berechtigungen gesetzt werden, sprich Benutzer von Projekt A, darf nicht in Projekt B sein. Ich denke, mittels OG und OG_access liesse sich etwas entsprechendes realisieren, aber ich bin leider noch nicht dazu gekommen.

    Fazit:

    Wer bisher noch ohne Bug tracker in einem Projekt mit mehr als 2 Leuten gearbeitet hat, sollte vielleicht mal die Lage überdenken.

  • Xdebug und Windows Vista – Wackelpartie

    Das mit dem Debuggen unter Vista scheint doch nicht wirklich zu klappen. Xdebug kann zwar eingerichtet werden und wird auch korrekt geladen, aber sobald ich eine Seite besuche, wird der Prozess geschlossen (und ich vermute, es ist irgend etwas mit xdebug), denn sobald ich das Xdebug Modul deaktiviere, dann klappt wieder alles normal. Auf Windows XP war das kein Problem.

    Somit ist der Debugger hier fürs erste mal gestorben, ausser jemand kann mir gerade die Lösung zum Problem sagen.

  • Endlich wieder ein Debugger für PHP

    Endlich. Nachdem ich die letzten Monate ohne Remote Debugging gearbeitet habe, bin ich jetzt wieder dabei, dank einem Post von Krimson. Es hat zwar ein Weilchen gedauert, da ich versucht habe, das ganze in eine alte Eclipse Installation (welche noch PHPeclipse installiert) hatte zu installieren.

    Das klappt nicht. So habe ich jetzt eine frische Installation mit PDT. Funktioniert super und man kann endlich endlich auch über mehrere Seiten hinaus debuggen, was ich mittels PHPeclipse und dbg einfach nicht geschafft habe.

    Wenn man mit PDT arbeitet, dann muss man noch einen kleinen Tweek machen, damit .module Dateien auch geöffnet werden können (http://www.freshblurbs.com/drupal-and-eclipse-pdt). Jo. Jetzt kann es los gehen, da ich noch ein verzwicktes Problem mit Form API lösen muss…

    Als nächster Schritt werde ich noch den Profiler installieren. Geht hoffentlich auch ganz ohne Problem.

    Es lebe Eclipse und auf meinem neuen Rechner startet es sogar super schnell auf 😉

  • Drupal Theme

    Soll jemand sagen, mann könne keine hübschen Themes mit Drupal machen.

    Also es ist durchaus möglich, aber es liegt halt nicht nur am darunter liegenden System sondern an den künstlerischen Fähigkeiten 😉 Sieht man hier, dass es sich um Drupal handelt?

    CoolWeb

  • Fast Gallery 3.2 – stable

    Fast Gallery geht in die nächste Runde. Ich empfehle allen auf diese Version zu aktualisieren, da ein paar echt coole Features dabei sind:

    • Video
    • Verbesserung von internationalen Characters

    Danke an dieser Stelle auch an Alle, welche sich an der Entwicklung von Fast Gallery beteiligt haben. Ist cool zu sehen, wie es sich "von selbst" entwickelt.

    Dann wollen wir doch mal schauen, was die Zukunft noch so alles bringen wird. Beim Update, das Modul ganz deinstallieren und nochmals neu installieren, da es kein Updatescript für die DB hat.