Modellgetriebene Softwareentwicklung in der Praxis SS14 eJSL

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Kurs
Kursname Modellgetriebene Softwareentwicklung in der Praxis SS 14
Kurstyp Praktikum
Dozent Priefer
Semester SS 14
Studiengang Master
Link http://homepages.thm.de/~dprf53/lehre.html


Diese Seite dokumentiert die Ergebnisse des Gruppenprojektes der Gruppe "eJSL" für das Modul "Modellgetriebene Softwareentwicklung in der Praxis" im Sommersemester 2014.

Der Projektverlauf wurde im THM-Redmine dokumentiert. Der Quellcode wird in einem Repository im THM-Gitorious zu Verfügung gestellt.

Das Projekt besteht als einer (vorgegebenen) Modellsprache und Generatoren für Joomla-Extensions.

Sprints

Sprint 1 (02.09. - 03.09.)

Der erste Spring wurde am 01.09. durchgeplant. Nach der Definition von Aufgabenkategorien und spezifischen Tasks wurde der Zeitaufwand für jeden einzelnen mithilfe der Planning-Poker-Methode abgeschätzt. Teilweise gab es große Unterschiede bei der Abschätzung des Aufwandes, so dass es zu längeren Diskussionen kam.

Aufgaben

  • Analyse der Referenzanwendung (Weblinks)
    • Ticket [11751] Analyse des alten eJSL-Projekts
    • Ticket [11702] Analyse der Referenzimplementierung: Template
    • Ticket [11747] Analyse der Referenzimplementierung: ExtensionPackage
    • Ticket [11698] Analyse der Referenzimplementierung: Component
    • Ticket [11700] Analyse der Referenzimplementierung: Module
    • Ticket [11701] Analyse der Referenzimplementierung: Plugin
    • Ticket [11746] Analyse der Referenzimplementierung: Library
  • Erstellung eines Modells aus einer Referenzimplementierung (Weblinks)
    • Ticket [11686] Analyse des gesamten Metamodells eJSL
    • Ticket [11716] Erstellung eines Modells für Weblinks
    • Ticket [11738] Analyse des Metamodells eJSL (Spezifisch, Jeder sein Teil)
  • Implementierung von Generatoren
    • Ticket [11780] Analyse des Metamodells eJSL (Spezifisch, Jeder sein Teil)
    • Ticket [11726] Erstellung von Grundstruktur für Generator
    • Ticket [11740] Vorbereitung des Repositories
    • Ticket [11721] Generator für Module
    • Ticket [11724] Generator für Template
    • Ticket [11719] Generator für Manifest
    • Ticket [11720] Generator für Component
    • Ticket [11722] Generator für Plugin
    • Ticket [11725] Generator für ExtensionPackage
    • Ticket [11723] Generator für Library
  • Review der Generatoren
    • Ticket [11736] Vergleich der generierten Extension mit der Referenzimplementierung
  • Erstellung von Constraints (Validierung)
    • Ticket [11753] Erstellung eines Validators für eJSL
    • Ticket [11754] Erstellung eines Formatters für eJSL
    • Ticket [11755] Erstellung von QuickFixes für eJSL

Sprint 2 (04.09. - 10.09.)

Aufgaben

  • Anpassung von Generatoren an aktuelle Joomla-Spezifikation mithilfe Referenzen
    • Ticket [11751] Analyse des alten eJSL-Projekts
    • Ticket [11702] Analyse der Referenzimplementierung: Template
    • Ticket [11747] Analyse der Referenzimplementierung: ExtensionPackage
    • Ticket [11698] Analyse der Referenzimplementierung: Component
    • Ticket [11700] Analyse der Referenzimplementierung: Module
    • Ticket [11707] Analyse der Referenzimplementierung: Manifest
    • Ticket [11701] Analyse der Referenzimplementierung: Plugin
  • Erweiterung des Validators
    • Ticket [11866] Implementierung von Validierung für bisher nicht in Referenzmodell verwendete Regeln
    • Ticket [11867] Refactoring
    • Ticket [11845] Anpassung von Manifest
  • Review
    • Ticket [11853] Review von Validatoren und Formatter
    • Ticket [11868] Implementierung von erweitertem Referenzmodell
    • Ticket [11854] Vergleich der generierten Extension mit der Referenzimplementierung
  • Dokumentation des Projektes in Wiki
    • Ticket [11851] Dokumentation von Formatter
    • Ticket [11870] Dokumentation von Module-Generator
    • Ticket [11869] Dokumentation von Template-Generator
    • Ticket [11849] Dokumentation von Component-Generator
    • Ticket [11850] Dokumentation von Validator
    • Ticket [11999] Einleitungstexte formulieren und Syntax anpassen
    • Ticket [11872] Dokumentation von Package-Generator
    • Ticket [11863] Dokumentation des Plugin Generators
    • Ticket [12002] Dokumentation von eJSL
    • Ticket [11888] Dokumentation des Manifests

Impediments

  • Unerwartete externe Änderungen an Grammatik
    • Ticket [11875] Beheben von Problemen durch Merge
    • Ticket [11874] Anpassung der Generatoren an geänderte Grammatik

eJSL

eJSL (extended Joomla! Specific Language)

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Diagramm der eJSL


Beispiel Weblinks.eJSL

 1 eJSLModel "Weblinks" {
 2 
 3   datatypes {
 4     Datatype "String",
 5     Datatype "Int"
 6   }
 7 
 8   entities {
 9     Entity WebLink {
10       attributes {
11         Attribute Title: String
12         Attribute alias: String
13         Attribute url: String
14         Attribute hits: Int
15       }
16     }
17   }
18   pages {
19     IndexPage Weblinks {
20       *Entities WebLink
21     }
22     DetailsPage Weblink {
23       *Entities WebLink
24     }
25     IndexPage Categories {
26     }
27     DetailsPage Category {
28     }
29     DetailsPage Form {
30     }
31     DetailsPage ModulPage {
32       *Entities WebLink
33     }
34   }
35   extensions {
36     Component weblinks {
37       Manifestation {
38         authors {
39           Author "Joomla! Project" {
40             authoremail = "admin@joomla.org"
41             authorurl = "www.joomla.org"
42           }
43         }
44         copyright = "Copyright (C) 2005 - 2014 Open Source Matters, Inc. All rights reserved."
45         license = "GNU General Public License version 2 or later; see LICENSE.txt"        
46       }
47       languages {
48         Language en-GB {
49           keyvaluepairs {
50             Key COM_WEBLINKS = "Weblinks"
51           }
52         }
53       }
54       sections {
55         Frontend section {
56           *Pages Categories, Category, Weblink, Form
57         }
58         Backend section {
59           *Pages Weblinks, Weblink
60         }
61       }
62     }
63     Module weblinks {
64       Manifestation {
65         authors {
66           Author "Joomla! Project" {
67             authoremail = "admin@joomla.org"
68             authorurl = "www.joomla.org"
69           }
70         }
71         copyright ="Copyright (C) 2005 - 2014 Open Source Matters, Inc. All rights reserved."
72         license = "GNU General Public License version 2 or later; see LICENSE.txt"
73       }
74       languages {
75         Language en-GB {
76           keyvaluepairs {
77             Key MOD_WEBLINKS = "Weblinks"
78           }
79         }
80       }
81      *Page ModulPage
82     }
83   }
84 }

Analyse

An Anfang steht die Analyse der Extension-Typen in Joomla. Dabei soll herausgefunden werden, welche Teile generiert werden können und wie Daten aus dem Modell eingesetzt werden müssen. In der Analyse werden die Ordnerstrukturen ermittelt und auch notwendige Dateien.

Für die Analyse wurden als Beispiele u.a. THM Groups und das Joomla eigene Weblinks genutzt.

ExtensionPackage

Ein Package hat folgende Struktur:

Für das Package werden die Erweiterungen entsprechend dem erstellten Model generiert.

Manifest

Die Manifest-Datei ist fast völlig generisch. Die Daten sollen aus dem Model ausgelesen werden.

Quelle

Joomla Package Tutorial

Library

Auf dem Bild ist die Struktur der THM Groups Library dargestellt.

Die Bibliothek soll auf jeden Fall eine Manifest-Datei beinhalten. Die Struktur kann frei gestaltet werden.

Manifest

Schematischwiederkehrend

<?xml version="1.0" encoding="UTF-8"?>
<extension type="library" version="3.4.0" method="upgrade">

Generisch

Im eJSL vordefinierte Tag-Informationen:

  • authors
  • creationdate
  • copyright
  • license
  • link
  • version
  • description

Der Wert "authors" wird auf "Author" referenziert, welcher folgende Werte im Manifest zusätzlich eintragen soll.

  • name
  • authoremail
  • authorurl

Beispiel der Komponente "Weblinks":

<name>com_weblinks</name>
<author>Joomla! Project</author>
<creationDate>April 2006</creationDate>
<copyright>(C) 2005 - 2014 Open Source Matters. All rights reserved.</copyright>
<license>GNU General Public License version 2 or later; see LICENSE.txt</license>
<authorEmail>admin@joomla.org</authorEmail>
<authorUrl>www.joomla.org</authorUrl>
<version>3.0.0</version>
<description>COM_WEBLINKS_XML_DESCRIPTION</description>

Wobei der Inhalt der Description immer am Ende der Installation angezeigt wird.

Nicht im eJSL vordefinierte Tags:

  • files
    • filename
    • foldername
  • languages
  • dependencies
  • updateservers

Quelle

Component am Beispiel von Weblinks ("weblinks")

Frontend-Teil

Der Frontend-Teil wird in die Website eingebunden und ist dort sichtbar.

  • components/com_[weblinks]/
  • Component-Einstiegsdatei: [weblinks].php
  • Manifest: Ist immer im Backendteil
  • Ordner:
    • controllers/
    • helpers/
    • models/
    • views/
  • View-Beispiel für Category-View mit normaler HTML-Anfrage:
    • Einstiegsdatei: /views/[category]/view.[html].php
    • Template: /views/[category]/tmpl/default.php


Backend-Teil

Der Backend-Teil wird im Administrationsmenü angezeigt und dient der Verwaltung.

  • administrator/components/com_[weblinks]/
  • Gleiche Struktur, wie Frontend-Teil
  • Aber mit Manifest: [weblinks].xml

Weiterführendes


Templates

Ein Template ist das Aussehen einer Joomla-Seite. Templates haben Felder in denen die Komponenten und Module angezeigt werden können, dabei wird in jedem Feld eine Komponente oder mehrere Module angezeigt.

Es gibt zwei Typen von Templates: Front-end Templates und Back-end Templates.

Ordner Struktur

  • Template
    • site/
      • css/
      • html/ (Joomal override files)
      • images/
      • templateDetails.xml
      • index.php
    • admin/
      • (Siehe site)

templateDetails.xml

 1 <?xml version="1.0" encoding="utf-8"?>
 2 <extension version="3.3" type="template">
 3   <name>mynewtemplate</name>
 4   <creationDate>2008-05-01</creationDate>
 5   <author>John Doe</author>
 6   <authorEmail>john@example.com</authorEmail>
 7   <authorUrl>http://www.example.com</authorUrl>
 8   <copyright>John Doe 2008</copyright>
 9   <license>GNU/GPL</license>
10   <version>1.0.2</version>
11   <description>My New Template</description>
12   <files>
13   <filename>index.php</filename>
14     <filename>templateDetails.xml</filename>
15     <folder>images</folder>
16     <folder>css</folder>
17   </files>
18   <positions>
19    <position>breadcrumb</position>
20    <position>left</position>
21    <position>right</position>
22    <position>top</position>
23    <position>user1</position>
24    <position>user2</position>
25    <position>user3</position>
26    <position>user4</position>
27    <position>footer</position>
28   </positions>
29 </extension>

index.php

 1 <?php defined( '_JEXEC' ) or die( 'Restricted access' );?>
 2 <!DOCTYPE html>
 3 <html xml:lang="<?php echo $this->language; ?>" lang="<?php echo $this->language; ?>" >
 4   <head>
 5     <jdoc:include type="head" />
 6     <link rel="stylesheet" href="<?php echo $this->baseurl ?>/templates/mynewtemplate/css/template.css" type="text/css" />
 7   </head>
 8   <body>
 9     <jdoc:include type="modules" name="top" /> 
10     <jdoc:include type="component" />
11     <jdoc:include type="modules" name="bottom" />
12   </body>
13 </html>

Quellen

Module

Module sind leichtgewichtige und flexible Erweiterungen die zum Rendern der Seite eingesetzt werden. Ein gutes Beispiel für ein Module ist das Login-Module. Module können aus statischem HTML oder Text bestehen. Module werden vom Joomla! Model Manager verwaltet.

Dateistruktur

  • mod_helloworld.php
  • mod_helloworld.xml
  • helper.php
  • tmpl/
    • default.php

mod_helloworld.php

Diese Datei ist der Haupteinstieg in das Modul. Sie führt alle nötigen Initialisierungs-Routinen aus, führt Helper-Routinen aus, um nötwendige Daten zu sammeln, und includiert das Template, welches die Ausgaben des Moduls anzeigt.

 1 <?php
 2  
 3 // no direct access
 4 defined( '_JEXEC' ) or die( 'Restricted access' );
 5 // Include the syndicate functions only once
 6 require_once( dirname(__FILE__).'/helper.php' );
 7  
 8 $hello = modHelloWorldHelper::getHello( $params );
 9 require( JModuleHelper::getLayoutPath( 'mod_helloworld' ) );
10 ?>

helper.php

Diese Datei beinhaltet die Helfer-Klassen welche benutz werden um die eigentliche Arbeit zu erledigen, vom erhalten der Informationen bis zum Darstellen im Modul (normalerweise von einer Datenbank oder einer anderen Quelle).


 1 <?php
 2 class modHelloWorldHelper{
 3     /**
 4      * Retrieves the hello message
 5      *
 6      * @param array $params An object containing the module parameters
 7      * @access public
 8      */    
 9     public static function getHello( $params )
10     {
11         return 'Hello, World!';
12     }
13 }
14 ?>

tmpl/default.php

Das ist das Module-Template. Diese Datei nimmt die Daten von mod_helloworld.php un generiert den HTML-Text der auf der Seite angezeigt wird.

1 <?php 
2 // no direct access
3 defined( '_JEXEC' ) or die( 'Restricted access' ); 
4 echo $hello; 
5 ?>

mod_helloworld.xml

Diese Datei enthält Informationen über das Modul. Es definiert die Dateien die vom Joomla! installer installiert werden müssen und spezifiziert die Konfigurationsparameter für das Modul.


 1 <?xml version="1.0" encoding="utf-8"?>
 2 <extension type="module" version="3.1.0" client="site" method="upgrade">
 3   <name>Hello, World!</name>
 4   <author>John Doe</author>
 5   <version>1.0.0</version>
 6   <description>A simple Hello, World! module.</description>
 7   <files>
 8     <filename>mod_helloworld.xml</filename>
 9     <filename module="mod_helloworld">mod_helloworld.php</filename>
10     <filename>index.html</filename>
11     <filename>helper.php</filename>
12     <filename>tmpl/default.php</filename>
13     <filename>tmpl/index.html</filename>
14   </files>
15   <config>
16   </config>
17 </extension>

Quellen

Plugins

Plugins sind ebenfalls Erweiterungen von Joomla!. Sie werden in verschiedene Plugin Typen unterteilt. Folgende Plugin-Typen sind in der Version Joomla! 3.x in der jeweiligen Ordnerstruktur enthalten:

  • root/
    • plugins/
      • authentication/
      • captcha/
      • content/
      • editors/
      • editors-xtd/
      • extension/
      • finder/
      • quickicon/
      • search/
      • system/
      • twofactorauth/
      • user/
      • index.html


Entwickelte Plugins müssen einem Plugin-Typ unterteilt werden, um es lauffähig zu machen. Die Pluginerweiterung enthält standardgemäß folgende Dateien:

  • PLUGINNAME.php
  • PLUGINNAME.xml
  • index.html

Die Dateibezeichnungen müssen standardmäßig die gleiche Bezeichnung wie den Namen des Ordners enthalten. Anhand des Beispiel-Plugins "Weblinks" sähe die Ordnerstruktur folgendermaßen aus:


Im Metamodell sind die Plugin-Typen folgendermaßen unter "PluginKinds" hinterlegt:

  • authenticate
  • captcha
  • content
  • contact
  • editors
  • extensions
  • finder
  • quick_icons
  • search
  • system
  • user
  • xml_rpc

Manifest

In der Manifest-Datei sind folgende Einträge enthalten:

 1 <?xml version="1.0" encoding="utf-8"?>
 2   <extension version="3.1" type="plugin" group="plugintyp">
 3   <name>plg_plugintyp_pluginname</name>
 4   <author>Joomla! Project</author>
 5   <creationDate>September 2014</creationDate>
 6   <copyright>Copyright (C) 2005 - 2014 Open Source Matters. All rights reserved.</copyright>
 7   <license>GNU General Public License version 2 or later; see LICENSE.txt</license>
 8   <authorEmail>admin@joomla.org</authorEmail>
 9   <authorUrl>www.joomla.org</authorUrl>
10   <version>3.0.0</version>
11   <description>PLG_PLUGINTYP_PLUGINNAME_XML_DESCRIPTION</description>
12 
13   <files>
14    <filename plugin="pluginname">pluginname.php</filename>
15    <filename>index.html</filename>
16   </files>
17 
18   <languages>
19    <language tag="en-GB">en-GB.plg_plugintyp_pluginname.ini</language>
20    <language tag="en-GB">en-GB.plg_plugintyp_pluginname.sys.ini</language>
21   </languages>
22 
23   <config>
24    <fields name="params">
25   <fieldset name="basic">
26   <field ...>
27   </field>
28   </fieldset>
29   </fields>
30   </config>
Schematisch wiederkehrend

Zeile 1 - 2

Generisch

Zeile 3 - 30

Pluginname.php

Die PHP-Datei im Plugin-Paket enthält von Joomla vordefinierte Ereignisfunktionen, welche je nach Plugin-Typ genutzt werden können.
In nachfolgender Auflistung werden die vordefinierten Ereignisse nach Bereichen dargestellt:

authentication

  • onUserAuthenticate
  • onUserAfterLogin
  • onUserAfterLogout

captcha

  • onInit
  • onDisplay
  • onCheckAnswer

content

  • onContentPrepare
  • onContentAfterSave
  • onContentBeforeSave
  • onContentAfterDelete
  • onContentBeforeDelete
  • onContentChangeState
  • onCategoryChangeState
  • onContentBeforeDisplay

editors

  • onInit
  • onSave
  • onGetContent
  • onSetContent
  • onGetInsertMethod
  • onDisplay

extension

  • onExtensionAfterInstall
  • onExtensionAfterUninstall
  • onExtensionAfterUpdate

finder

  • onFinderDelete
  • onFinderAfterSave
  • onFinderBeforeSave
  • onFinderChangeState
  • onFinderCategoryChangeState
  • onFinderAfterDelete

quickicon

  • onGetIcons

search

  • onContentSearchAreas
  • onContentSearch

user

  • onUserAfterSave
  • onUserAfterDelete
  • onUserLogin
  • onUserLogout
  • onContentPrepareData
  • onContentPrepareForm
  • onUserBeforeSave

Quellen

Generatoren

Die Generatoren für die einzelnen Extentions werden einzeln implementiert. Hier wird beschrieben, welche Dateien und Ordner erzeugt wurden und welche Besonderheiten es bei den einzelnen Generatoren gibt.

Bei der Implementierung wurden die Entwicklungen des Projektes vom letzten Jahr Modellgetriebene_Softwareentwicklung_in_der_Praxis_SS13 genutzt und so angepasst, dass nicht viel neu entwickelt werden musste.


Template-Generator

Der Template-Generator generiert ein Template-Extension die in Joomla 3.3 installiert und verwendet werden kann. Hierbei wird nur das Grundgerüst des Modules generiert, individuelle Inhalte müssen vom Entwickler selber implementiert werden.

Wiederkehrende Teile

Die die "TemplateDetails.xml" ist bei jedem Template gleich, daher wird die Grundstruktur dieser Datei vom Generator erstellt und mit den Daten aus dem Model gefüllt. Es werden auserdem Ordner für CSS, JavaScritp, fonts, imagesm language erstellt. Dieser Ordner haben aber keinen Inhalt, da dieser Inhalt individuell ist und nur von einem Anwendungsentwickler gefüllt werden kann. Der Language-Ordner wird mit den in der Instanz erstellten Sprachen gefüllt.

In die component.php Datei werden alle in der Instanz des Models angegebenen Possitionen eingetragen. An diese Positionen können später Componenten oder Module eingebunden und angezeigt werden.

Im CSS-Ordner werden bereits vordefinierte CSS Einträge erstellt. Diese CSS-Dateien werden auch in der component.php eingebunden. Im CSS-Ordner werden die Dateien mod_name.css, mod_name_rtl.css mit den aus dem Model erstellten CSS-Informationen gefüllt. Diese konnten mit Key-Value-Paaren definiert werden. Der Generator schreibt diese Paare auch in eine der dafür angelegten CSS-Dateien.

Die Language-Dateien werden auch mit Key-Value-Paaren gefüllt.

Generierte Ordner und Dateien

  • index.php
  • component.php
  • templateDetails.xml
  • css/
    • general.css
    • offline.css
    • error.css
    • mod_name.css
    • mod_name_rtl.css
  • fonts/
  • html/
    • modules.php
  • javascript/
  • images/
    • dummyImage
  • language/
    • lang_name/
      • lang_name.ini
      • lang_name.sys

In jedem Ordner wird durch die Methode generateJoomlaDirectory() eine index.html erstellt.

Module-Generator

Der Module-Generator generiert eine Module-Extension die in Joomla 3.3 installiert und verwendet werden kann. Hierbei wird nur das Grundgerüst des Modules generiert, individuelle Inhalte müssen vom Entwickler selber implementiert werden.

Generische und wiederkehrende Teile

Der Generator erstellt die Manifest-Datei und füllt diese mit generischem Inhalt aus dem Model. Dazu gehören Eigenschaften wie: creationDate, copyright, license, version, description. Werte die im Model nicht angegeben sind, werden mit Standardwerte die im Generator eingebaut sind gefüllt. Es wird eine Liste mit Files in der Manifest erstellt. Hierbei sind aber nur die Dateien eingetragen, die auch durch den Generator erstellt wurden. Benutzer erstellte Dateien müssen dann an dieser Stelle per Hand eingefügt werden, da diese immer individuell sind. Auch der Inhalt der verschiedenen PHP Dateien (z.B. der helper.php) müssen per Hand ausgefüllt werden, da diese Daten komplett individuell sind. Der Generator erstellt hier nur die Dateien und füllt sie mit einer Grundstruktur die dann aber vom Anwendungsentwickler ausgefüllt werden müssen.

Es werden für alle Sprachen, die in der Instanz des Models angegeben sind ein Language-Tag in der Manifest-Datei und die zugehörigen Language-Dateien erstellt. Sind keine Sprachen angegeben, wird der Ordner und die Tags nicht generiert.

Generierte Ordner und Dateien

  • mod_name.php
  • helper.php
  • mod_name.xml
  • tmpl/
    • default.php

Component-Generator

Der Generator für die „Component“-Erweiterung ist einer der aufwendigsten Generatoren, da „Component“ eine Erweiterung mit vielen Dateien und Komponenten ist. Wie alle Erweiterungsgeneratoren baut er auf „AbstractExtensionGenerator“ auf und erbt so die Funktions-Infrastruktur für die Pfadverwaltung und die Datei- und Ordnergeneratoren.

Die Komponente wird mit dem Namen „com_NAME“ benannt. Es werden nach und nach folgende Dateien mit generierbaren Inhalt und Grundgerüst erstellt, dabei entstehen drei Ordner (Sprachen, Frontend, Backend). Der generierbare Inhalt wird aus dem eJSL-Modell entnommen oder statischer Inhalt eingesetzt, der überall gleich ist.

  • com_NAME.xml (Manifest)
  • language/ (Sprachen)
    • de_DE/ (Sprachordner und Dateien, für jede definierte Sprache)
      • de_DE.com_NAME.ini
      • de_DE.com_NAME.sys.ini
  • admin/ (fürs Backend)
    • sql/ (Datenbank-Schema für Installation etc.)
      • install.mysql.utf8.sql
      • uninstall.mysql.utf8.sql
      • updates/mysql/0.0.1.mysql.utf8.sql
    • views/
      • com_NAME/
        • view.html.php
        • tmpl/default.php
      • PAGE/ (für jede Page, die definiert ist)
        • view.html.php
        • tmpl/default.php
    • models/
      • PAGE.php (für jede Page, die definiert ist)
    • controllers/
      • PAGE.php (für jede Page, die definiert ist)
    • NAME.php (Start-Datei)
    • controller.php (Default-Controller)
  • site/ (fürs Frontend)
    • views/
      • com_NAME/
        • view.html.php
        • tmpl/default.php
      • PAGE/ (für jede Page, die definiert ist)
        • view.html.php
        • tmpl/default.php
    • models/
      • PAGE.php (für jede Page, die definiert ist)
    • controllers/
      • PAGE.php (für jede Page, die definiert ist)
    • NAME.php (Start-Datei)
    • controller.php (Default-Controller)

Für die Datenmodelle werden schon passende Ansichten im Front- und Backend zur Präsentation der Daten generiert. Dies geschieht mit JTable. Für Erweiterungen (nicht generische Teile) werden Platzhalter generiert, die vom Anwendungsentwickler ausgefüllt werden können.

Ziel dieses Generators ist, ein Component-Skelett aus einem eJSL-Modell generieren zu können, welches direkt in Joomla installiert werden kann.

Plugin-Generator

Der Plugin-Generator wurde für die Joomla! 3.x Versionen definiert.
Es stellt lediglich ein Grundgerüst mit standartisierten Definitionen dar, welche für jeden Plugin-Typ äquivalent generiert werden.
In den nachfolgend aufgelisteten Schritten kann mit dem Plugin-Generator und dem vorhandenen zu verwendenden Metamodell ein Plugin folgendermaßen generiert werden:

  1. Schritt: Modellbezeichnung hinzufügen
  2. Schritt: "extensions" auswählen
  3. Schritt: "Plugin" auswählen und Namen des Plugins hinzufügen
  4. Schritt: "Manifestation" auswählen um die .XML Datei zu erstellen
  5. Schritt: "authors" auswählen welcher auf "Author" verweist, um dem Manifest einen Autoren hinzuzufügen, welcher eine "authoremail" und "authorurl" beinhalten kann
  6. Schritt: Zusätzliche Felder können dem Manifest hinzugefügt werden: "creationdate", "copyright", "license", "link", "version", "description"
  7. Schritt: Plugin-Typ auswählen. Zur Auswahl stehen: "authenticate", "captcha", "content", "contact", "editors", "extensions", "finder", "quick_icons", "search", "system", "user", "xml_rpc". Der Plugin-Typ ist von hoher Bedeutung, um das Plugin in den richtigen Bereich einordnen zu können.
  8. Schritt: "languages" -> "Language" auswählen und das global verwendete Kürzel verwenden (Bsp: de-DE für Deutsch, en-GB für Englisch)
  9. Schritt: "keyvaluepairs" -> "Key" auswählen. Hierbei ist wichtig, dass der Keybezeichner großgeschrieben wird (Bsp: PLG_PLUGINTYP_PLUGINNAME)
  10. Schritt: Den letzten Schritt wiederholen, welche die Beschreibung des Plugins in der jeweiligen Sprache enthält (Bsp: PLG_PLUGINTYP_PLUGINNAME_XML_DESCRIPTION)

Anmerkung: Die kursiv enthaltenen Wahlmöglichkeiten sind in der neuen Joomla! Version 3.x nicht verfügbar.

Nachdem alle Schritte vorgenommen wurden, wird folgende Struktur vom Plugin-Generator erstellt:

Validierung

Mithilfe von Validierung können Prüfungen für das Modell durch geführt werden, die mit einer Grammatik nicht oder nur schwer umsetzbar wären. Anhand einer Grammatik kann die syntaktische Korrektheit eines Modells geprüft werden. Bei der Validierung liegt der Fokus hingegen auf der Prüfung von Modellen auf logische Korrektheit.

Für die Implementierung von Validierung für eJSL wurden mehrere Alternativen in Betracht gezogen:

  • OCL
  • XText
  • Java (mit EMF Validation Framework)

Eine Java-Umsetzung mithilfe des EMF Validation Frameworks wurde von vornherein ausgeschlossen, da es für neuere Eclipse-Versionen aus der Dokumentation entfernt wurde. Es wird daher angenommen, dass die direkte Nutzung nicht mehr vorgesehen ist.

Die Object Constraint Language bietet den Vorteil, dass sie standardisiert und nicht an eine bestimmte Entwicklungsumgebung gebunden ist. Letztendlich fiel die Entscheidung jedoch auf XText-Validierung. Da eJSL stark von Eclipse-Technologien abhängig ist, bietet die OCL keinen Vorteil in der Praxis. XText wird bereits für andere Bereiche eingesetzt so dass für die Validierung keine neue Sprache erlernt werden muss.

Constraints

Vor der Implementierung wurden zunächst das Metamodell und das Referenzmodell analysiert. Dabei wurden folgende Constraints gefunden:

  • Eindeutigkeit von Bezeichnern
    • Attributnamen
    • Autornamen
    • Klassennamen
    • Datentypen
    • Entitätsnamen
    • Erweiterungsnamen
    • Schlüsselnamen
    • Sprachbezeichner
    • Methodennamen
    • Seitennamen
  • Einmalige Referenzierung
    • Entitäten, Seiten
  • Schema für Strings
    • E-Mail von Autoren
    • URL von Autoren
  • Kardinalitäten und Rekursion
    • nur jeweils ein Backend und Frontend
    • Erweiterungspakete dürfen nicht weitere Erweiterungspakete enthalten

Validierungsmeldungen

Eclipse untersützt drei verschiedene Schweregrade für Validierungsmeldungen: Info, Warning und Error.

Für die Validierung von eJSL wurden diese Schweregrade mit folgender Semantik eingesetzt:

  • INFO: (nicht verwendet, wird sonst bspw. für TODOs in Kommentaren verwendet)
  • WARNING: der analysierte Aspekt ist problematisch, die Sinnhaftigkeit der betroffenen Deklaration ist fraglich
  • ERROR: der analysierte Aspekt ist fehlerhaft, generierte Bestandteile sind evtl. nicht einsetzbar, die Validierung des Modells schlägt fehl

Implementierung

Für die Implementierung wird eine Klasse von AbstractEJSLValidator abgeleitet. Sie stellt u. a. Methoden zum Melden von Validierungsproblemen bereit. Validierungsmethoden werden innerhalb dieser mit der Check-Annotation markiert. Um auf das Teilmodell zugreifen zu können, wird der entsprechende Bestandteil (von EObject implementierende Klasse) als Parameter definiert.

Beispiel: Die häufigste Prüfung für eJSL ist die Sicherstellung von eindeutigen Bezeichnern. Hierfür wird über die entsprechenden Objekte iteriert und die Bezeichner in einem Set zwischengespeichert. Sollte das Einfügen in das Set fehlschlagen, so wurde ein mehrdeutiger Bezeichner gefunden und ein Validierungsproblem wird gemeldet.

@Check
def checkEntityAttributesAreUnique(Entity entity) {
        var attributes = new HashSet<String>

        for (attribute : entity.attributes) {
                if (!attributes.add(attribute.name)) {
                        error(
                                'Attribute names must be unique.',
                                attribute,
                                EJSLPackage.Literals.ATTRIBUTE__NAME,
                                AMBIGUOUS_ATTRIBUTE_NAME
                        )
                }
        }
}

QuickFixes

Mithilfe von QuickFixes kann der Anwendungsentwickler Fehler automatisch durch Eclipse beheben lassen. Mithilfe von XText lassen sich QuickFixes für Validierungsfehler implementieren. Die Verknüpfung zwischen QuickFix und Validierungsfehler wird über die Verwendung eines gemeinsamen Error-Code-Strings hergestellt.

Für eJSL wurde von der Implementierung von QuickFixes abgesehen, da keine sinnvollen Einsatzmöglichkeiten gefunden wurden. Bei der Verwendung von mehrdeutigen Bezeichnern ließe sich bspw. eine Ziffer anhängen. In den meisten Fällen wäre eine solche Lösung allerdings nicht im Interesse des Anwendungsentwicklers.

Formatting

Mit Hilfe von Formattern wird festgelegt, nach welchen Regeln die automatische Formatierung (Strg+Shift+F) von Eclipse durchgeführt wird. Für die Implementierung wird eine Klasse von AbstractDeclarativeFormatter abgeleitet, welche eine Instanzvariable c vom Typ FormattingConfig bereitstellt. Über dieses Objekt können Formatierungseinstellungen vorgenommen werden.

Es können sowohl allgemeine, grammatikunabhängige als auch grammatikspezifische Formatierungseinstellungen vorgenommen werden. Um Einstellungen für spezielle Grammatikregeln vornehmen zu können, wird auf diese mithilfe von automatisch generierten Konstanten in EJSLGrammarAccess referenziert.

Allgemeine Regeln:

  • nicht an eJSL-spezifische Grammatikregeln gebunden
  • Umbrüche und Einrückung für Blöcke, Kommentare und überlange Zeilen
  • Whitespaces um "," und ":"

Grammatikspezifische Regeln:

  • direkter Zugriff auf Grammatik über generierte Konstanten in EJSLGrammarAccess