Modulentwicklung für UliCMS

In diesem Dokument werden die Namenskonventionen des UliCMS Projekts beschrieben.

Bitte beachten SIe, dass der Entwickler von UliCMS sich das Recht vorbehält, die Veröffentlichung von Modulen und Themes in der Paketquelle und in UliCMS eXtend abzulehnen, wenn diese von den in diesem Dokument beschriebenen Vorgaben abweichen.

Modulnamen

  • Erlaubt sind Buchstaben, Unterstriche und Zahlen
  • Der Modulname darf nicht mit einer Zahl anfangen.
  • Ein Modulname der aus mehreren Wörtern besteht sollte nur Kleinbuchstaben verwenden und Unterstriche als Worttrenner
  • Ausnahme von der vorherigen Regel sind Libray Module die eine PHP-Klasse oder ein Framework enthalten. Hierbei darf der Klassenname als Modulbezeichnung verwendet werden (z.B. CrawlerDetect, geoPlugin)
  • Namen von Modulen deren Hauptzweck darin besteht, den Index für extended_search aufzubauen müssen mit ix_ geprefixt werden. Beispiel: ix_blog
  • Module deren Hauptzweck ist, die Funktionalität eines anderen Moduls zu erweitern oder zu verändern, müssen mit dem Namen des Basismoduls geprefixt werden. Beispiel: blog_statistics_dashboard

Klassen

  • CamelCase: Jedes Wort hat einen Großen Anfangsbuchstaben, danach Kleinbuchstaben
  • Ausnahmen von der vorherigen Regel werden gemacht, wenn Abkürzungen enthalten sind. z.B. ist folgendes erlaubt, VATCalculationController, da VAT eine Abkürzung für "value added tax" ist.
  • Datenmodelle (Models) sind in einem Orten mit dem Namen objects enthalten.
  • Controller sind in einem Ordner mit dem Namen "controllers" enthalten. Ausgenommen davon ist die main_class.
  • PHP-Klassen eines Moduls müssen in der jeweils passenden DIrektive der Datei metadata.json registriert werden. z.B. objects, controllers, helpers
  • Klassen müssen die entsprechende Basisklasse (sofern vorhanden) extenden. Alle Controller müssen z.B. so definiert werden:
    class MyClass extends Cotroller {
    }
  • Alle Controller mit Ausnahme der main_class müssen mit *Controller enden.
  • Die Main Class wird ähnlich wie das Modul an sich benannt, jedoch mit CamelCase: z.B. MyAwesomeModule

Funktionen

  • camelCase - Erstes Zeichen muss ein Kleinbuchstabe sein. Jedes weitere Wort muss einen großen Anfangsbuchstaben haben z.B. myCoolFunction()
  • Funktionen die public sind, aber nicht direkt vom Client (Browser) aus aufgerufen werden dürfen müssen mit einem Unterstrich geprefixt werden.  z.B. _myCoolFunction()
  • Parameter müssen auch camelCase sein.
  • Bei globalen Funktionen ist auch die Benennung mit Unterstrichen erlaubt. z.B. my_cool_function()

JavaScript

  • Scripts, die Abhäng von jQuery sind, müssen entweder in der Hook after_jquery_include oder im <body> eingebunden werden.
  • Javascripts sollten alle in einem Ordner enthalten sein, der entweder "js" oder "scripts" benannt ist.
  • Ausgenommen von der vorherigen Regel sind Module, deren Hauptzweck darin besteht, eine JavaScript Datei berereitzustellen.

CSS

  • CSS Dateien sollten in einem Ordner der "css" oder "stylesheets" benannt ist, enthalten sein.
  • Wenn ein Modul nur eine einzige CSS-Datei enthält, darf sich diese auch im Hauptordner eines Moduls befinden.

Grafikformate

  • Für Bilder ohne Transparenz sollte das JPEG-Dateiformat verwendet werden.
  • Für Bilder mit Transparenz sollte das PNG-Dateiformat verwendet werden.
  • Von der Verwendung von GIF, TIFF, BMP und sonstiges Grafikformaten wird abgeraten.
  • Für Favicons sind Icon-Formate erlaubt (z.B. *.ico)
  • Bilder sollten nicht zu groß sein (Dateigröße), aber auch nicht zu stark komprimiert. Bei JPEG empfehle ich eine Kompressionsrate zwischen 80 und 90 Prozent.

Kommentare

  • Schwer verständliche Codeblöcke und Funktionen sollten kommentiert werden.

Sicherheit

  • Controller-Funktionen die nur von bestimmten Benutzern aufgerufen werden dürfen, müssen in der Datei metadata.json per "controller_function_permissions" Direktive eine Berechtigung zu gewiesen bekommen
    Beispiel (Auszug):
    {
       "controller_function_permissions": {
        {
           "MyClass::addItem" : "mymodule_add_item",
           "MyClass::deleteItem" : "mymodule_delete_item",
       }

    }
  • Um die Sicherheit in älteren UliCMS Versionen die die "controller_function_permissions" Direktive nocj nicht unterstützen sicherzustellen, sollten zusätlich manuelle ACL Berechtigungsprüfungen am Anfang der Funktion eingefügt werden.

Der Entwickler behält sich das Recht vor, diese Richtlinien jederzeit ohne vorherige Ankündigung zu ändern.

Don't click this link