With the 5er version Fast Gallery got so much more handy. The latest changes with the plugable Frontend make development for fast gallery a pleasure as you don't have to be afraid anymore killing the whole module when you only want to switch presentation. It's really a charm.

Well, somebody asked about 
http://www.cooliris.com/ support. I do think this does look really cool. So I looked into it. The bummer is, the cooliris needs a feed... which is kinda cool, but again for Fast Gallery not really handy. Well here is my plan of attack: Use the fast gallery API module (which I started developing, but kinda lost interest).

The in detail plan looks like this:

1. Extend hook_fast_gallery_info

Allow two more parameters: type and source. Type would be "feed" and source would be the base path of where to find the feed (something like fast_gallery_api/get)

2. Fix fast gallery api module

As said this needs some love. Probably we just need to test it a little be in depth, maybe an additional handler and make sure that the feed is being outputted correctly so that cooliris will understand the format.

3. embed cooliris

That's probably going to be the easiest part. Just past in the object tag and point the source to where specified.

I guess 1 and 3 are a matter of 15 minutes, while 2 is going to take some time. So if any of you guys wants to help... Get your hands dirty and start coding. The plattform for patches would be in the fast gallery issue queue.

digg_url = 'http://www.rapsli.ch/cooliris-integration-my-plans'; digg_title = 'Cooliris Integration - My Plans'; digg_bodytext = "With the 5er version Fast Gallery got so much more handy. The latest changes with the plugable Frontend make development for fast gallery a pleasure as you don\'t have to be afraid anymore killing the whole module when you only want to switch presentation. It\'s really a charm."; digg_skin = 'standard';

Heute mal wieder ein wenig an Fast Gallery gebastelt. Hier was dabei herausgekommen ist. Das Galleria Modul wird integriert (Galleria ist dazu nicht notwendig). Fast Gallery hat die nötige Javascript Bibliothek mit dabei.

Galleria Ansicht sieht dann wie folgt aus.

Die Standardansicht sieht wie folgt aus:

Für Entwickler ist zudem weiter interessant, dass das Frontend plugable ist. Das will heissen, es muss lediglich ein Hook implementiert werden, und dann kann ein zusätzliches Frontend inzugefügt werden. Ich bin noch auf der Suche nach coolen Galerien.

Wäre cool, wenn jemand den Hook implementiert und ein Frontend für Fast Gallery schreibt. Die Galleria Ansicht braucht noch ein wenig Arbeit (Ordner und Titel müssen noch unterstützt werden), aber das ist a

Verwandte Beiträge:  Fast Gallery - Introduction for developers digg_url = 'http://www.rapsli.ch/fast-gallery-654-galleria-integration'; digg_title = 'Fast Gallery 6.5.4 - Galleria Integration'; digg_bodytext = "Heute mal wieder ein wenig an Fast Gallery gebastelt. Hier was dabei herausgekommen ist. Das Galleria Modul wird integriert (Galleria ist dazu nicht notwendig). Fast Gallery hat die n\x26ouml;tige Javascript Bibliothek mit dabei.\r\nGalleria Ansicht sieht dann wie folgt aus.\r\n\r\nDie Standardansicht sieht wie folgt aus:"; digg_skin = 'standard';

Seit einigen Wochen setzen wir ernsthaft Scrum als Projektmethodik ein. Noch gibt es vieles zu lernen, aber die ersten Wochen sind sehr positiv verlaufen. Hier ein paar Grundsätze:

• Team besteht aus 4 Entwickler und 1 Designer
• Productowner ist leider nicht auf Kundenseite
• Scrummaster (auch Mitglied des Teams)
• Sprints dauern 2 Wochen
• Team arbeitet pro Woche 3 Tage am Projekt (grundsätzlich Di - Do)

Da die ganzen Scrummethodik noch sehr jung ist, haben wir beschlossen, bereits nach einer Woche eine kleine Retrospektive zu machen. Daraus resultierten 3-4 Punkte konkrete Punkte, welche wir ändern/verbessern wollen (nicht nötig dafür noch eine weitere Woche zu warten, besonders da die Projektdauer sehr kurz ist).

Fazit: Sehr positiv. Besonders hervorzuheben ist vor allem die Motivation und der Teamgeist, welcher viel stärker zur Geltung kommt. Jeder ist bedacht, die Tasks bis zum Sprintende zu erfüllen und auch bereit Aufgaben von anderen Mitgliedern zu erfüllen. Dadurch entsteht ein viel besserer Wissenstransfer.

Negativ: Kommunikation zum Kunden hin noch nicht optimal. Bei offenen Fragen dauert es einfach noch zu lange, bis Antworten zurückkommen. Ist nicht direkt etwas, was wir ändern können, aber muss sicher bei Projektbeginn klip und klar kommuniziert werden und vor allem müssen auch die Konsequenzen aufgezeigt werden: Verzögerung des Projektes.

Und das Beste: Man kann die ganzen Scrumansätze den eigenen Gegebenheiten und Eigenheiten anpassen. Ich kann es also nur weiterempfehlen.

digg_url = 'http://www.rapsli.ch/scrum-einem-drupalprojekt'; digg_title = 'Scrum in einem Drupalprojekt'; digg_bodytext = "Seit einigen Wochen setzen wir ernsthaft Scrum als Projektmethodik ein. Noch gibt es vieles zu lernen, aber die ersten Wochen sind sehr positiv verlaufen. Hier ein paar Grunds\x26auml;tze:"; digg_skin = 'standard';

This blogpost should give a quick kickstart to every developer who is interested in helping to advance Fast Gallery. The architecture is intended to have a swapable storage engine. So far I've only written one storage engine, which means that interfaces are not 100% clearly defined, but would instead need some work when actually going to be used in practice. First a quick overview over the files and what their responsibilities are.

• fast_gallery-image-wrapper.tpl.php: template file to display the image
• fast_gallery.admin.inc: the general admin stuff (UI), that would be used by any storage engine (setting up galleries, scanning galleries...)
• fast_gallery.cache.class.php: incase Imagecache is not available there's a simple caching class, that creates thumbnails and caches them.
• fast_gallery.class.php: this is the heart of the module. Here we recursively explore directories for images and send them to the storage engine or get images from the storage engine and return them to the frontend
• fast_gallery.css: if you are developing, you should know what this is for ;)
• fast_gallery.info: same here
• fast_gallery.install: and same here
• fast_gallery.module: Mostly it's just implementations of hooks and actually displaying the gallery in fast_gallery_alias()
• fast_gallery.test: I started once writing some tests.... this really needs some work!
• FGImage.class.php: Internally Fast Gallery treats images as objects of this class.

Ok, then we have a couple folders:

• images: just some images
• integrations: possible integrations into other modules. So far: features integration
• modules: Other modules for fast gallery. I started once the Fast Gallery API module, which should provide some kind of REST API... but it's not there yet
• storageengine: well this contains some classes and interfaces that are responsible for actually storing and retrieving images and hierarchy retrieved from directories
• tests: just some folders that are used when doing the simpletests

Just some more info on the storageengine folder:

• Istorage.php: contains and interface that all possible storageengines must implement.
• default.config.inc: Well, just some UI stuff for storageeninge specific configuration
• default.storage.inc: the actual storage engine, that stores data into the db, makes sure hierarchy is correct and returns the right images depening on the path.
• node.config.inc, node.storage.inc: sample data to build a nodestorage, which was actually my goal at a given point.... but unfortunately not there yet :(

Oky, this is the first attempt. I'll write another blogpost and describe some of the important concepts in detail.

digg_url = 'http://www.rapsli.ch/fast-gallery-introduction-developers'; digg_title = 'Fast Gallery - Introduction for developers'; digg_bodytext = "This blogpost should give a quick kickstart to every developer who is interested in helping to advance Fast Gallery. The architecture is intended to have a swapable storage engine. So far I\'ve only written one storage engine, which means that interfaces are not 100% clearly defined, but would instead need some work when actually going to be used in"; digg_skin = 'standard';

In der neuen Version von Fast Gallery gibt es mal wieder ein neues Feature. Bilduntertitel können über IPTC ausgelesen werden. Dabei gibt es mehrere zur Auswahl. Sehr oft ist es jedoch der Fall, das noch gar keine IPTC Daten vorhanden sind. In dem Fall können diese jetzt gleich direkt in der Galerie editiert werden und werden dann ins Bild gespeichert.

Patrick war so freundlich und hat dafür einen Patch geschrieben. Fertig sieht es dann in etwa so aus:

Zudem konnte im neuesten Release auch noch ein Bug behoben werden, so dass auch falls der Ordner leer ist, die Unterordnet aufgelistet werden.

Dieses Feature basiert auf dem jQuery Edit in Place Plugin, welches separat heruntergeladen und installiert werden muss.

digg_url = 'http://www.rapsli.ch/inplace-editing-fast-gallery'; digg_title = 'Inplace Editing - Fast Gallery'; digg_bodytext = "In der neuen Version von Fast Gallery gibt es mal wieder ein neues Feature. Bilduntertitel k\x26ouml;nnen \x26uuml;ber IPTC ausgelesen werden. Dabei gibt es mehrere zur Auswahl. Sehr oft ist es jedoch der Fall, das noch gar keine IPTC Daten vorhanden sind. In dem Fall k\x26ouml;nnen diese jetzt gleich direkt in der Galerie editiert werden und werden dann"; digg_skin = 'standard';

Mit Drupal 6.17 wurde innoDB eingeführt. Bisher wurde immer myisam verwendet. Die Standardwerte, welche mit MySQL kommen sind für MyIsam ziemlich gut und man kommt schon sehr weit damit. Verwendet man jedoch die Standardwerte für innoDB, dann hat man einen ziemlich Flaschenhals. 

Mit der Installation von Drupal 6.17 stellte ich fest, dass die Seite massiv langsamer wurde. Devel zeigte mir, dass vor allem Schreibzugriffe (z.B. auf die Cachetabellen) sehr langsam vorangingen... (Faktor 100 langsamer als vorher). So habe ich kurzerhand diese Tabellen wieder auf MyIsam zurückgesetzt und siehe da, es ging wieder schneller.

Heute hatte ich ein bisschen mehr Zeit, um ein wenig herumzuspielen. Schlussendlich habe ich die Lösung gefunden, den Flaschenhals zu öffnen:

innodb_flush_log_at_trx_commit = 2

Standardmässig ist er gar nicht gesetzt. Sobald ich den auf 2 gesetzt habe ist die Seite nur so "geflogen". Performance hat auch mit innoDB massiv zugenommen. Was ist passiert. Wenn innodb_flush_log_at_trx_commit auf 2 gesetzt ist, dann wird nur jede Sekunde etwas auf die Festplatte geschrieben, sonst wird jeder Schreibbefehl auch gleich auf die Festplatte geschrieben, was natürlich viel langsamer ist.

Also... ich bin überhaupt kein MySQL Perfromance Guru, aber das scheint mir eine sehr einfache und effiziente Lösung zu sein.

 

digg_url = 'http://www.rapsli.ch/drupal-langsame-schreibzugriffe-mit-innodb'; digg_title = 'Drupal langsame Schreibzugriffe mit innodb'; digg_bodytext = "Mit Drupal 6.17 wurde innoDB eingef\x26uuml;hrt. Bisher wurde immer myisam verwendet. Die Standardwerte, welche mit MySQL kommen sind f\x26uuml;r MyIsam ziemlich gut und man kommt schon sehr weit damit. Verwendet man jedoch die Standardwerte f\x26uuml;r innoDB, dann hat man einen ziemlich Flaschenhals.\x26nbsp;"; digg_skin = 'standard';

Übersetzungen in Drupal sind so eine Sache und es gibt diverse Funktionen. Ich habe ja selber nicht gewusst, dass es neben t() auch noch tt() gibt und ich muss sagen tt() ist genial :) Hier mal eine kleine Erklärung, welche ich dazu gefunden habe... sehr plausibel erklärt, warum t() nicht überall verwendet werden soll/darf.

Im folgenden ein Auszug aus der Drupal Mailing Liste.

So you're suggesting that currently the &quot;correct&quot; way to make text <br />stored in the database translatable is to use tt()? 

I don't know of a better way. We tried to get people to review approaches for this in core for Drupal 6, but nobody showed up at that time, so no such solution got into Drupal 6 consequently. Given lack of interest it did not get into Drupal 7 either as it seems.

Why is tt() more <br />
correct than t()?  Isn't tt() going to end up orphaning the translations <br />
if the database text gets changed, the same as t()?

I did not look into the current implementation (tt() is using some abstractions :), but the idea is that unlike t(), you provide tt() with more detailed meta information on the &quot;location&quot; of the string, so you tell it that &quot;this is status label number 3 from mymodule&quot;, so when the status label 3 is updated, the string to translate can be updated without leaving orphan strings behind. With t() you lack this metainformation on the string (even in Drupal 7, unless you abuse the context system to hell which is however not supposed to used in this granularity given that it makes translation sharing impossible).

Doesn't tt() still <br />
have the same problem when the database text gets changes to non-english <br />
language? 

It segments this problem to at least the non-default textgroup. There is obviously no way we can tell whether a string is English or not and it is pointless to keep trying to get users to enter English text at all times on a localized site. That would be crazy. 

Is what this is really solving is avoiding a misnomer, <br />
avoiding putting &quot;database defined text&quot; into the &quot;code defined text&quot; <br />
locale group?

The Drupal 6 textgroup system lets you segment strings and as implemented with tt(), it also lets you use the location information to update and look up strings based on the objects they relate to. These are all unavailable if you use t(). Also, t() has some other niceties, like caching short strings for easy lookup. Now if we'd tell people to translate things like taxonomy with t() itself, then you can easily end up with a huge cache of short strings (including all your taxonomy terms) loaded up on every page. Pretty useless and resource consuming. 

We could say you might still somewhat safely use t() in some user input cases, but it would still go with the leftover stale strings, mixing up the English and non-English text in the database and on the translation UI, etc. Textgroups and tt() exploiting them with the location information attempts to solve these problems as well as not letting user input go to the t() cache loaded on every page. which is designed with the UI text mass in mind. 

What about Mike's suggestion to create a support.locale.php file whose <br />
sole purpose is to expose default database strings?  Is that practice <br />
frowned upon?  At this time it seems like the simplest solution, though <br />
if someone decides to add their own custom states and/or priorities they &gt; won't be translatable without also hacking the support.locale.php file. <br />
How is this solved?  What is the proper way to be sure that any text <br />
stored in the database is exposed to the translation system, even text <br />
that may be added later by the user? 

As said, while technically t() might look like it solves your problems, I'd advise against it. See above.

G&aacute;bor

Im Detail würde es dann so aussehen:

<?php

function mymodule_locale($op = 'groups', $group = NULL) {
   switch ($op) {
     case 'groups':       return array('mygroup' =&gt; t('My Group'));   }
}

function mymodule_somefunction() {
   //...
     tt('mygroup:the_location', $string);
   //... }
?>

Weitere Ressourcen:

• http://drupal.org/book/export/html/322729
• http://groups.drupal.org/node/15177

digg_url = 'http://www.rapsli.ch/uebersetzungen-drupal-t-vs-tt'; digg_title = 'Übersetzungen in Drupal t vs tt'; digg_bodytext = "\x26Uuml;bersetzungen in Drupal sind so eine Sache und es gibt diverse Funktionen. Ich habe ja selber nicht gewusst, dass es neben t() auch noch tt() gibt und ich muss sagen tt() ist genial :) Hier mal eine kleine Erkl\x26auml;rung, welche ich dazu gefunden habe... sehr plausibel erkl\x26auml;rt, warum t() nicht \x26uuml;berall verwendet werden soll/darf.\r\nIm"; digg_skin = 'standard';

Am heutigen Tag, habe ich mich ein wenig mit der Drupal Views API herumgeschlagen. Ich habe zum ersten mal ein eigenes Style Plugin für Views geschrieben. Aller Anfang ist schwer und so habe ich mich am Anfang auch ein wenig gequält, aber bin dann schlussendlich sehr schnell vorangekommen.

Wo fängt man am Besten an? Nun, ich lerne am Liebsten von Vorlagen und Beispielen. Ich habe mir also einfach so ein Modul geschnappt, welches ein Style Plugin implementiert und zwar Views Slideshow. Das Modul ist relativ einfach und man blickt schnell durch.

Hookmässig ist eigentlich nur hook_views_api und hook_views_plugins zu implementieren, wobei der hook_views_plugins in meinmodule.views.inc muss. In diesem Hook wird das Plugin dann definiert. Dann gibt es eine weitere Datei, welche eine bestimmte Namenskonvention einhalten muss, welche das eigentliche Plugin implementiert. Hier wird eine Klasse implementiert, welche von einem Standardplugin abgeleitet wird.

Je nachdem, was für ein Plugin man schreiben möchte, kann man die Methoden der Klasse selber implementieren, oder man implementiert die Methode nicht, und lässt die übergeordnete Klasse die arbeit erledigen. Damit man weiss, was für Methoden zur Verfügung stehen ist die Views Dok ausgezeichnet.

Dieser Beitrag ist ziemlich knapp... ja ich weiss, aber im Moment habe ich gerade nicht viel mehr Zeit. Es sei an dieser Stelle nur gesagt, dass es sich doch für das eine oder andere Problem lohnen kann.

digg_url = 'http://www.rapsli.ch/views-api-fuer-entwickler'; digg_title = 'Views API für Entwickler'; digg_bodytext = "Am heutigen Tag, habe ich mich ein wenig mit der Drupal Views API herumgeschlagen. Ich habe zum ersten mal ein eigenes Style Plugin f\x26uuml;r Views geschrieben. Aller Anfang ist schwer und so habe ich mich am Anfang auch ein wenig gequ\x26auml;lt, aber bin dann schlussendlich sehr schnell vorangekommen."; digg_skin = 'standard';

Vor einem halben Jahr habe ich mit Wubi angefangen. Ich konnte weiterhin noch mein gewohntes Windows System drauf haben und hätte zur Not auch wieder wechseln können. Es hat sich dann gezeigt, dass ich immer wie besser mit Linux zurecht komme. Ich wurde sogar euphorisch. PHP Entwickeln und Ubuntu macht einfach mehr Spass und das Verständnis für das *nix System hilft massiv: SVN, Konsole, patches, Rechte usw. ... bei Windows geht das irgendwie verloren.

Nun, ja, ich habe ein halbes Jahr auf einer 12 GB halb virtualisierten Ubuntu Partition gearbeitet. Mit der Zeit wird der Platz ziemlich knapp und so habe ich jetzt endlich endlich den kompletten Umstieg gemacht, und dabei gerade auf Ubuntu 10.04 gewechselt... ich bin schwer schwer begeistert. Ist einfach super genial. Aufstarten braucht ca. 20 Sekunden und dann kann ich mit Arbeiten anfangen, runterfahren geht noch schneller. Super.

Das Doklet unten ist noch recht cool ;) ... was soll ich sagen, ich kanns nur weiterempfehlen. Es lebe OpenSource!

digg_url = 'http://www.rapsli.ch/es-lebe-ubuntu-1004'; digg_title = 'Es lebe Ubuntu 10.04'; digg_bodytext = "Vor einem halben Jahr habe ich mit Wubi angefangen. Ich konnte weiterhin noch mein gewohntes Windows System drauf haben und h\x26auml;tte zur Not auch wieder wechseln k\x26ouml;nnen. Es hat sich dann gezeigt, dass ich immer wie besser mit Linux zurecht komme. Ich wurde sogar euphorisch. PHP Entwickeln und Ubuntu macht einfach mehr Spass und das"; digg_skin = 'standard';

Mittels Rules lassen sich herrliche Dinge machen. Es sind kaum Grenzen gesetzt, was Workflows und solche Sachen angeht. Mit Klicken kommt man schon ziemlich weit. Manchmal kann es aber notwendig sein, dass man eigene Actions für die Rules bereitstellt. Klaro, man kann praktisch alles mit eingebettetem PHP Code machen, aber das ist nicht wirklich eine glamurose Lösung. Hier ein kleines Beispiel:

<?php
/**
* implementation of hook_rules_action_info()
*/
function fast_gallery_rules_action_info() {
  return array(
    'fast_gallery_flush_caches' => array(
      'label' => t('Flush Fast Gallery Cache'),
      'module' => 'Fast Gallery',
    ),
  );
}
?>

Mit dem hook_rules_action_info sage ich dem Rules Modules, dass wir eine Action anbieten. fast_gallery_flush_caches ist die Callbackfunktion, welche aufgerufen wird, wenn die Action ausgeführt wird. Das Label ist der Text, welche im Dropdown aufgelistet wird.

Folgendes Szenario wäre jetzt denkbar. Ich habe irgend eine spezielle Funktion. Ich möchte, dass jedesmal, wenn diese Aktion aufgerufen wird, der Fast Gallery Cache geleert wird. Ganz einfach: Einfach eine Rules mit dem entsprechenden Trigger machen und dann diese Action hinzufügen. Und schon klappt es wunderbar.

Ich werde auf jeden Fall bei meinen zukünftigen Modulen immer schauen, dass solche Integrationen vorhanden sind. Features, Rules und Co. sind schon sehr hilfreich und je mehr Modulmaintainer Integrationen mit diesen Modulen haben, desto flexibler wird Drupal.

digg_url = 'http://www.rapsli.ch/drupal-rules-api'; digg_title = 'Drupal Rules API'; digg_bodytext = "Mittels Rules lassen sich herrliche Dinge machen. Es sind kaum Grenzen gesetzt, was Workflows und solche Sachen angeht. Mit Klicken kommt man schon ziemlich weit. Manchmal kann es aber notwendig sein, dass man eigene Actions f\x26uuml;r die Rules bereitstellt. Klaro, man kann praktisch alles mit eingebettetem PHP Code machen, aber das ist nicht"; digg_skin = 'standard';

Panels kommt mit einigen Modulen daher. Bevor wir ernsthaft mit Panels anfangen, sollten wir wissen, welches Modul wofür zuständig ist:

Chaos Tools Suite (CTools)

Eigentlich ist die gar nicht so chaotisch, wie sie klingt ;) Dort werden diverse Funktionen gebündet, welche in diversen anderen Modulen immer wieder gebraucht werden (hauptsächlich Panels und Views). Dazu gehören unter anderem: Diese Overlays, Exportmöglichkeiten und das Pluginsystem.

Page Manager

Dieser gibt uns die Möglichkeit Templates für Seiten zu erstellen und ersetzt dadurch verschiedene node.tpl.php Dateien. Es gibt zum Beispiel die Möglichkeit folgende Seiten anzupassen: Taxonomy Term Template, User profile Template, Node Template, Node add/edit Form Template.

Die Vorgehensweise ist denkbar einfach: Template editieren, Layout auswählen Inhalte einfügen... schon gemacht. Ausführlicheres Tutorial kommt noch.

Views content panes

Wenn man ein Panels erstellt, dann lassen sich gewisse Elemente in die sog. Panes einfügen: Blöcke, Nodes usw. und eben auch Views. Diese lassen sich natürlich via Blöcke einfügen, aber es ist eigentlich besser diese als Views Panes einzufügen (ein Views Pane kann in der Views hinzugefügt werden, gleich wie Block, sobald man das Modul aktiviert hat). Warum ist ein Views Pane besser als ein Views Block? Es lassen sich diverse Zusatzangaben machen.

Panels

Nur Panels macht nicht viel. Hier wird die Grundfunktionalität gebündelt, aber wenn man nur Panels aktiviert, dann hat man noch nicht sehr viel gewonnen, bzw. kann nicht sehr viel damit machen.

Panels Nodes

Damit lassen sich Nodes als Panels erstellen. Unter "Inhalt erstellen" wird ein neuer Inhaltstyp erscheinen (Panel). Ich kann ein neues Panel erstellen und dann genau gleich für dieses ein Layout wählen und die Panes mit entsprechenden Inhaltselement füllen (auch normaler Text). 

Mini Panel

Ist ähnlich wie Panels Nodes, nur dass sich damit "panelisierte Blöcke" erstellen lassen. Layout auswählen, Panels mit Inhalt befüllen und dann habe ich einen neuen Block, den ich in eine Region legen kann.

Dann gibt es noch ein recht cooles Zusatzmodul

Panels Everywhere

Damit lässt sich der Page Manager erweitern. Im Page Manager lassen sich nur die Elemente bearbeiten, welche im page.tpl.php als $content ausgegeben werden, es lässt sich nicht jedoch das ganze Seitenlayout mit Panels gestalten. Panels Everywhere erlaubt das jedoch.

Folgendes Usecase wäre somit möglich: Ein Theme erstellen, welches keine Regions hat und dafür ein Seitenlayout mit Panels Everywhere erstellen und dort entsprechendes Layout wählen (z.B. Content mit einer rechten Spalte) und jetzt dort entsprechend Blöcke einfüllen und in der Content Spalte den Content ausgeben.

... etwas abstrakt, wenn ich mal dazukomme, werde ich ein paar ausführlichere Tutorials machen.

digg_url = 'http://www.rapsli.ch/eine-einleitung-panels'; digg_title = 'Eine Einleitung in Panels'; digg_bodytext = "\r\nPanels kommt mit einigen Modulen daher. Bevor wir ernsthaft mit Panels anfangen, sollten wir wissen, welches Modul wof\x26uuml;r zust\x26auml;ndig ist:\r\nChaos Tools Suite (CTools)\r\nEigentlich ist die gar nicht so chaotisch, wie sie klingt ;) Dort werden diverse Funktionen geb\x26uuml;ndet, welche in diversen anderen Modulen immer wieder gebraucht werden"; digg_skin = 'standard';

 Views und CCK kennt jeder. Sie gehören schon fast zu einer Webseite und das wird sich in Zukunft noch verstärken, da CCK Teil von Drupal Core ist. Niemand zweifelt an diesen Modulen, viele kennen und verstehen sie und wissen, wie sie eingesetzt werden müssen. So auch ich.

Meiner Meinung nach gibt es noch andere Module, welche eine ähnliche Wichtigkeit haben und welche man genau so verstehen sollte: Panels/Display Suite, Rules und Features.

Ziel von Drupal oder auch einem jedem anderen Framework sollte sein, die Webseitenerstellung zu abstrahieren und zu vereinfachen (eigentlich so, wie das Frontpage mal gemacht hat). In Drupal gibt es dazu die folgenden Module:

CCK

Ist unser Datenmodell-modelier-tool. Damit können wir definieren, wie unsere Inhalte ausschauen, wobei ein zentrales Interface vorhanden ist (der Node). Bespiele müssen an dieser Stelle nicht erwähnt werden.

Views

Ist Datenmodell-abfrage-tool bzw. unser Query-Builder. Es lassen sich mit Views relativ komplexe Queries bauen. Zusätzliche Features ist der eingebaute Templatingmechanismus, sowie die Cachingmöglichkeiten. Das Gute daran: Views und CCK spielen ausgezeichnet zusammen.

Panels/Display Suite

Die Seite gestalten. Weder Views noch CCK sind dazu geeignet. Eine gängige Möglichkeit sind die .tpl Dateien aus dem Theme, aber dann wiederum hat man das Problem, dass gewisse Strukturen ans Theme gebunden sind, was nicht immer wünschenswert ist. Im Weiteren ist es aufwändig diese solche Seiten zu warten und die Flexibilität ist auch nicht die beste (komplexe Sites können eine beachtliche Anzahl an tpl Dateien erfordern). Was also sonst? Eben Panels oder/und Display Suite.

Ich habe immer ein wenig eine Abneigung gegen Panels gehabt. Keine Ahnung warum. Seit ich mich jedoch ein bisschen eingängiger damit beschäftigt habe, bin ich schwer begeistert. Die Display Suite ist super einfach, aber nicht ganz so umfangreich. Sie bezieht sich auf Nodes, Kommentare, Users usw. Panels dagegen geht weiter, es lassen sich ganze Seiten damit gestalten, dazu lassen sich auch Beziehungen zwischen Nodes abbilden... super! Vielleicht mache ich hier mal wieder ein kleines Screencast oder Tutorial

Rules

Aktionen. Workflows abbilden oder irgendwelche sonstigen Ereignisse. Rules ist dein Freund. Ein super mächtiges Werkzeug, welches auch Zeitsteuerung erlaubt (aber das ist leider nicht ganz so eingängig).

Features

Und zu guter letzt: Mein Freund Features, der das Leben so viel einfacher macht. Glücklicherweise unterstützen all diese Module Features. Features erlaubt es, Funktionalität/Struktur zu bündeln und somit auf anderen Seiten wieder einzusetzen. Ich könnte also z.B. ein Bildergalerie Feature basierend auf Views und CCK und Display Suite machen und dann das in ein Feature bündeln und auf einer anderen Seite wieder verwenden.

Kennt man all diese Module und weiss wie damit umgehen, dann hat man schon seeeehr viel gewonnen!

 

Verwandte Beiträge:  Eine Einleitung in Panels digg_url = 'http://www.rapsli.ch/building-drupal-blocks'; digg_title = 'Building Drupal Blocks'; digg_bodytext = "\x26nbsp;Views und CCK kennt jeder. Sie geh\x26ouml;ren schon fast zu einer Webseite und das wird sich in Zukunft noch verst\x26auml;rken, da CCK Teil von Drupal Core ist. Niemand zweifelt an diesen Modulen, viele kennen und verstehen sie und wissen, wie sie eingesetzt werden m\x26uuml;ssen. So auch ich."; digg_skin = 'standard';

Drupal-Zertifizierung. Immer wieder hört man etwas davon, aber geben tut es nicht wirklich etwas. Irgendwie passt es auch nicht so richtig in die Drupalwelt, und wenn schon, dann müsste es von Acquia kommen. Wiejedoch misst man etwas? Rein nur gute PHP-Kenntnisse reichen nicht, auch die Community-Fähigkeiten gehören zu einem guten Drupalianer.

Es gibt ja eigentlich nichts einfacheres. Einfach mal das Profil auf drupal.org anschauen oder auch auf drupalcenter.de und schon weiss man ziemlich viel über die Aktivität einer Person.