D-Down is coding

Wenn man in Diem eine fest definiert URI in einer JavaScript-Datei angeben möchte, muss man immer an den Scriptname denken. Dieser ist dummerweise nicht einzigartig und kann mehrfach auftreten. Diem selbst setzt am ende jedes HTML-Dokuments die JavaScript-Variable dm_configuration mit diversen Daten, mit unter den Scriptname, bereit. Hier könnte man z.B. die den Wert mit der eigentlichen URI zusammensetzen. Es gibt aber auch eine andere Möglichkeit und zwar über $.dm.ctrl.getHref(). Diese Methode hängt nämlich vor der übergebene URI den Scriptname dran.

$.dm.ctrl.getHref('+/ddMain/index');

Der Validator dmValidatorLinkUrl ist schon was feines. Neben der Validierung einer URL kann es auch eine Seite oder ein Medium validieren. Dies wird ganz einfach über ein Präfix page: bzw. media: gefolgt von der ID des Objekts. Möchte man allerdings im selben Wert eine URL gefolgt von einem Trennzeichen und den Link-Text pflegen, schlägt die Validierung logischerweise fehl. Hier ein Beispiel wie ein solcher Validator aussehen könnte.

class ddValidatorLinkUrl extends dmValidatorLinkUrl
{
  public function doClean($value)
  {
    $splittetValue = explode(' ', $value);

    if (1 < count($splittetValue))
    {
      $url = array_shift($splittetValue);
    }
    else
    {
      $url = $value;
    }

    unset($splittetValue);

    parent::doClean($url);

    // no Exception are thrown so everything went fine
    return $value;
  }
}

Er ist nicht perfekt, da auch die URL Leerzeichen enthalten können. Jedoch sollte der Validator die meisten Anforderungen abdecken.

In der letzten Zeit durfte ich mich mal etwas mit dem CMF Diem auseinandersetzen und wollte aus diesem Grund ein Paar How-To's veröffentlichen die, meiner Meinung nach, in der Dokumentation der offiziellen Homepage nicht zufriedenstellend sind oder sogar gänzlich vermisst werden. Dies sollte nicht missverstanden werden, denn die Dokumentation des Projekts ist durchaus gut, nur weisen sie in manchen Bereichen Lücken auf.

Das Model DmLayout erweitern

In diesem Post möchte ich aufzeigen, wie wir das Layout dahingehen erweitern, dass im Backend ebenfalls eine id für das HTML-Tag body angegeben werden kann. Dazu muss erstmal das Model DmLayout um ein weiteres Feld erweitert werden. Symfony bietet hier eine recht elegante Lösung ein bereits existierendes Model aus einem Plugin zu erweitern, ohne die schema.yml des Plugins anpassen zu müssen. Was in der Praxis bedeutet, dass man die schema.yml des Projekts mit folgenden Zeilen erweitert:

DmLayout:
  package: dmCorePlugin.lib.model.doctrine
  columns:
    body_id:
      type: string(20)
      notnull: false

Im Grunde genommen ist das Schlüsselwort die Direktive "package". Der Wert stellt den Pfad des Models relativ vom Verzeichnis plugin dar. Wobei die Punktnotation als Verzeichnis-Trenner verwendet wird. Danach sollte die Datenbank mit dem kommenden Befehlen entsprechend erweitert werden.

Hinweis: Sicherheitshalber sollte man ein Dump der Datenbank erstellen, bevor man das Kommando ./symfony doctrine:migrate ausführt.

./symfony doctrine:generate-migrations-diff
./symfony doctrine:migrate
./symfony dm:setup

Den Admin-Generator anpassen

Dank der kaskadierenden Eigenschaften die Symfony mit sich bringt, ist das erweitern des Admin-Generators ein leichtes. Es muss lediglich das Module dmLayout in der Applikation admin mit entsprechender Verzeichnis-Struktur hinzugefügt werden und ein Teilbereich der generator.yml Einstellung erweitert werden.

modules
|  
`-- dmLayout
   `-- config
       `-- generator.yml

Der Inhalt der generator.yml:

generator:
 class: dmAdminDoctrineGenerator
 param:
   config:
     fields:
       body_id:
         label: "Body id"
         help: "This ID applied to the body tag"
     form:
       display:
         NONE: [name, css_class, body_id]

Nach dem man das Projekt aktualisiert hat, sollte der Adminbereich entsprechend aussehen.

Den FrontLayoutHelper erweitern

So jetzt haben wir die Information. Doch die voreingestellte Klasse dmFrontLayoutHelper kann mit dieser Information nichts anfangen. Und aus diesem Grund benötigen wir einen eigenen Helper der die Information verarbeiten kann. In meinem Fall habe ich die Klasse unter app/front/lib/view/html/layout/myFrontLayoutHelper.php abgelegt. Die Klasse leitet in diesem Fall von der Klasse dmFrontLayoutHelper ab und überschreibt die Methode renderBodyTag wie folgt:

  public function renderBodyTag($options = array())
  {
    $options = dmString::toArray($options);

    if (($bodyId = dmArray::get($options, 'id', $this->page->getPageView()->getLayout()->get('body_id'))))
    {
      $options['id'] = $bodyId;
    }

    return parent::renderBodyTag($options);
  }

Den neuen FrontLayoutHelper bekannt machen

Zu guter Letzt muss dem Dependency-Injection-Container die neue Klasse bekannt gemacht werden. Dazu erstellen wir unter dem Pfad apps/front/config/dm/ die Datei service.yml und überschreiben den Wert für den Parameter layout_helper.class.

parameters:

  layout_helper.class:        myFrontLayoutHelper   # Responsible for rendering the front layout.

Das war es auch schon.