[Basti]

Hallo.

Ich hab vor einem Jahr oder so schonmal eine ähnliche Anfrage gestellt und wieder fallen gelassen. Jetzt ist es konkret. Ich brauche einen WYSIWYG-Editor für mein CMS. Mein Plan ist, den WYMeditor anzupassen.

Neben der eigentlichen Umsetzung ist da auch noch ein wenig Konzeptionsarbeit gefragt. Ich könnte mir vorstellen, dass als Auftrag abzugeben. Allerdings sind meine Mittel im Moment sehr begrenzt und von daher wäre es vielleicht eine Idee, ein kleines Team von Leuten zusammenzustellen, die Ahnung von jQuery oder JS im Allgemeinen haben und an dem CMS mitarbeiten wollen und denen Spaß und eine geringe Entschädigung genug Lohn sind, da mitzuwirken.

Hier mal mein die Anforderungen für meinen „Traum-Editor“:

- Möglichkeit, Komponenten einzubinden. Das wären dann z.B. ein Adressblock oder eine Termine-Tabelle oder ein Mitarbeiter-Kurzprofil oder ähnliches, im Editor einfügbar als DIV (ähnlich einem einzeiligen Absatz), der z.B. Icon und Komponentenname enthält und „aufklappbar“ ist, damit dann das eigentliche Formular (vielleicht AJAX) entfaltet.

- Diese Komponenten müssen verschiebbar sein, löschbar, eventuell braucht es noch den Zugriff auf zuvor gelöschte Komponenten.

- Bilder können höchstens proportional skaliert werden und dann auch nur innerhalb von definierbaren Maximalwerten. Sie können entweder quasi als eigenständiger Ansatz rechts-, linksbündig oder zentriert oder mit Textumfluß rechts- oder linksbündig erscheinen. Hier sollte konfigurierbar sein, was möglich ist und was nicht. Bilder frei im Text platzierbar zu machen ist quatsch – höchstens die Zeilenhöhe wird nicht überschritten.

- Komponenten, die nicht über die ganze Breite gehen, sondern auch wie Bilder, ev. sogar „hinter“ Bildern (z.B. anklickbare slideshow) eingebunden werden können wäre fein.

- Die Popups müssten als DIVs erscheinen, die auch beim scrollen zentriert bleiben, den Hintergrund „deaktivieren“ und mit irgendwelchen Formularen gefüllt werden können (Media Browser, …).

- Der Bug beim Skalieren von Bildern im Firefox muss natürlich raus.

Jo, das ist eine ganze Menge. Wichtig sind vor allem die Komponentengeschichte. Die DIV-Popups sind sicher keine große Sache. Die Skalierbarkeit der Bilder und der Bug scheinen mir da schon irgendwie aufwändiger zu sein. Hab schonmal rumgesucht im Quellcode, schnall aber nicht recht, wo das programmiert ist. Ist das ein Browser-Feature, dass der editor nur benutzt? In dem Fall müsste man das wohl nachprogrammieren, wenn die Browser nicht mehr als das hergeben. Komponenten mit Textumfluß sind auch erstmal nicht so wichtig.

Fühlt sich jemand von euch angesprochen? Ich würde mich über Rückmeldung freuen. Vielleicht mit einem Angebot für die Umsetzung oder dem Angebot, daran mitzuarbeiten oder Ideen, Kritik und Rückfragen.

Basti

[Neq']

Zitat von Basti

Jo, das ist eine ganze Menge. Wichtig sind vor allem die Komponentengeschichte. Die DIV-Popups sind sicher keine große Sache. Die Skalierbarkeit der Bilder und der Bug scheinen mir da schon irgendwie aufwändiger zu sein. Hab schonmal rumgesucht im Quellcode, schnall aber nicht recht, wo das programmiert ist. Ist das ein Browser-Feature, dass der editor nur benutzt? In dem Fall müsste man das wohl nachprogrammieren, wenn die Browser nicht mehr als das hergeben. Komponenten mit Textumfluß sind auch erstmal nicht so wichtig.

Nein die Div-Popups sind tatsächlich keine große Sache. Das Resizen der Bilder ist ein Browserfeature. Das läuft über die Methode "execCommand()" denen man eben die gewünschten Commands übergibt. Wenn man "insertimage" verwendet, wird das Bild eingefügt und der Browser macht es skalierbar. Normalerweise sollte das resizen vom Browser aus schon funktionieren, bin mir aber grade nicht sicher ob das im Firefox wirklich standardmäßig implementiert ist, im IE ganz sicher.

Zitat von Basti

Fühlt sich jemand von euch angesprochen? Ich würde mich über Rückmeldung freuen. Vielleicht mit einem Angebot für die Umsetzung oder dem Angebot, daran mitzuarbeiten oder Ideen, Kritik und Rückfragen.

Angesprochen fühlen würde ich mich definitiv. Das Angebot klingt verlockend, nur ob ich die nötige Zeit mitbringen kann weiß ich nicht.

Patrick

[Basti]

Hallo Patrick.

Zitat von Neq'

Das Resizen der Bilder ist ein Browserfeature. Das läuft über die Methode "execCommand()" denen man eben die gewünschten Commands übergibt. Wenn man "insertimage" verwendet, wird das Bild eingefügt und der Browser macht es skalierbar. Normalerweise sollte das resizen vom Browser aus schon funktionieren, bin mir aber grade nicht sicher ob das im Firefox wirklich standardmäßig implementiert ist, im IE ganz sicher.

Doch, doch. Sollte normalerweise schon auch im FF funktionieren. Tut es auch in den älteren WYMeditor-Versionen und in anderen Editoren. Ich denke, ich werde das erstmal komplett rauslassen und diese Komponenten, die vom Text umflossen werden können im Editor auch als „Block“-Komponenten darstellen.

Am Besten wäre es, wenn man einen Komponenten-Baum abbilden könnte, denn genau das ist ja in der Regel die Struktur einer Seite.

Als Beispiel eine Mitarbeiter-Seite eines Unternehmens. Da wäre dann vom Seitentyp her vorgegeben:

- Überschrift
- Text
- 0-n mal die Komponente „Mitarbeiterblock“; diese besteht aus:

-- Überschrift (z.B. „Freie Mitarbeiter“ oder „Abteilung XY“)
-- Beschreibungstext
-- 0-n mal Komponente „Kurzprofil“:

--- Bild (150*200)
--- Text (ohne weitere Komponenten, ohne Links, nur ein Absatz)

Die Schwierigkeit ist halt, diesen Baum abzubilden. Die Komponenten müssten eigentlich eine feste Breite haben.

Eine Alternative zum Einbetten von DIVs in einen Editor wäre, mehrere Editor-Instanzen „übereinander“ zu setzen, mit diesen DIVs zwischendrinnen und z.B. einer gemeinsamen Menüleiste (bzw. Werkzeugleiste). Schwierig hier dann nur, die DIVS quasi Absatzweise hoch- und runterschieben zu können.

Ich werde mich mal an einen Prototypen (ohne „echten“ Editor) machen.

Basti

[Basti]

Hier also besagter Prototyp ohne Editierfunktion:

http://dev.bastian-fenske.de/cms-editor/editor_01.php

Basti

[Neq']

Zitat von Basti

Hier also besagter Prototyp ohne Editierfunktion:

http://dev.bastian-fenske.de/cms-editor/editor_01.php

Basti

Verstehe ich das richtig und im Grunde muss es nicht in einem WYSIWYG-Editor eingebunden werden (den im Grunde ist ein WYSIWYG-Editor nichts anderes als ein eingebundener Frame der per execCommand gewisse Befehle entgegen nimmt und verarbeitet)? Jetzt wäre es natürlich möglich das du jedem Div-Container (oder Listen-Element, ist im Endeffekt egal) den Effekt ermöglichst den Inhalt per Klick zu verändern bzw. einen WYSIWYG-Editor für den jeweiligen Abschnitt zu generieren. Oder möchtest du das unbedingt alles in einem WYSIWYG-Editor haben?

[Basti]

Hast mich richtig verstanden. Meine Idee war ursprünglich, das alles in einen Editor zu packen, aber ich vermute so geht es einfacher. Wenn es dann auch nur einige wenige Auszeichnungen gibt, würde eine Wiki- (oder phpbb-)Syntax ja auch reichen.

Weitere Fragen (zu den dort genanten) wären:

- Wie kann ich die Daten speichern bzw. senden?
- Wie lässt sich z.B. ein Absatz in eine Überschrift umwandeln und umgekehrt? (Buttons in der Werkzeugleiste? Pull-Down-Menü?)
- Wie werden neue Komponenten erstellt (Ajax?)

Größtes Problem wird sein, umzusetzen, dass gewisse Komponenten nur an gewisse Stellen geschoben werden dürfen.

Definierbar muss z.B. sein:

- In dieser Komponente ist eine optionale Überschrift möglich, gefolgt von einem optionalen Text und einer Liste von 0-n Komponenten vom Typ „Termin“.
- In dieser Komponente hier sind beliebig viele Komponenten „Image“ erlaubt, jedoch nur linksbündig mit maximal 300 Pixeln breite.

Basti

[Neq']

Zitat von Basti

- Wie kann ich die Daten speichern bzw. senden?

Nun mittels dem DOM ist es natürlich nicht sonderlich schwer durch einen HTML-Tree zu wandern und die Elemente die du haben willst zu zählen. Ich stelle mir vor (so etwas ähnliches hab ich schonmal gemacht) das du einfach durch deine Liste (oder Div-Container) iterierst und ein Array mit ID -> Inhalt erstellst, so kannst du den Tree speichern und auch einzelne ID's senden.

Zitat von Basti

- Wie lässt sich z.B. ein Absatz in eine Überschrift umwandeln und umgekehrt? (Buttons in der Werkzeugleiste? Pull-Down-Menü?)

Ja ist natürlich deiner Fantasie bzw. deinen Vorstellungen vorbehalten, man könnte auch einfach sagen, wenn der Tag "h1" verwendet wird, wandelt sich das Element automatisch in eine Überschrift um und umgekehrt.

Zitat von Basti

- Wie werden neue Komponenten erstellt (Ajax?)

Kommt darauf an was du brauchst. Musst du den Tree sofort mit Inhalt befüllen kommt natürlich AJAX ins Spiel. Willst du nur eine neue Komponente erstellen wird natürlich nur auf das DOM zurückgegriffen.

Zitat von Basti

Größtes Problem wird sein, umzusetzen, dass gewisse Komponenten nur an gewisse Stellen geschoben werden dürfen.

Definierbar muss z.B. sein:

- In dieser Komponente ist eine optionale Überschrift möglich, gefolgt von einem optionalen Text und einer Liste von 0-n Komponenten vom Typ „Termin“.
- In dieser Komponente hier sind beliebig viele Komponenten „Image“ erlaubt, jedoch nur linksbündig mit maximal 300 Pixeln breite.

Stimmt, dieses Problem halte ich schon für wesentlich kniffliger. Hier muss bei jedem verschieben eines Elements zu einer anderen Stelle schon beim Mouseover eine AJAX-Request abgesendet werden ob ich mein Element hier überhaupt droppen darf bzw. ob die Anzahl der Pixel oder der Komponenten noch passt. D.h möglich wär es schon, nur ich weiß nicht inwiefern die AJAX-Requests sich auf die Serverlast auswirken (es wird bei jedem Move ein AJAX-Request an das PHP-File ausgeführt welches die benötigten Daten aus der Datenbank holt).

Patrick

[Basti]

Hallo Patrick.

Zitat von Neq'

Nun mittels dem DOM ist es natürlich nicht sonderlich schwer durch einen HTML-Tree zu wandern und die Elemente die du haben willst zu zählen. Ich stelle mir vor (so etwas ähnliches hab ich schonmal gemacht) das du einfach durch deine Liste (oder Div-Container) iterierst und ein Array mit ID -> Inhalt erstellst, so kannst du den Tree speichern und auch einzelne ID's senden.

Komponenten sind jedoch auch irgendwelche Formulare, deren Inhalte eigentlich in einen anderen Containern gespeichert werden sollten. Vielleicht wäre es geschickt, den Baum zu speichern, in dem auch, wie im Editor jeder Absatz etc. einen eigenen Knoten darstellt und für jeden Knoten einen standardisierten Container anzulegen, in den verschiedene Variablen gesetzt werden können. Aber so ganz klar hab ich das noch nicht, wie ich das serverseitig überhaupt abbilden möchte.

Ich denke, es macht Sinn zu unterscheiden zwischen Komponenten, die quasi nur als Container fungieren, quasi nichts anderes sind als einer Definition, welche Komponente sie wie enthalten darf, kann, muss. Dann gibt es grundlegende Bausteine, die in allen möglichen Komponenten verwendet werden, wie z.B. Bild, Absatz etc. und dann eben dann „wirkliche“ Komponenten.

Mal sehen…

Stimmt, dieses Problem halte ich schon für wesentlich kniffliger. Hier muss bei jedem verschieben eines Elements zu einer anderen Stelle schon beim Mouseover eine AJAX-Request abgesendet werden ob ich mein Element hier überhaupt droppen darf bzw. ob die Anzahl der Pixel oder der Komponenten noch passt. D.h möglich wär es schon, nur ich weiß nicht inwiefern die AJAX-Requests sich auf die Serverlast auswirken (es wird bei jedem Move ein AJAX-Request an das PHP-File ausgeführt welches die benötigten Daten aus der Datenbank holt).

Ich denke, das passt schon vom „Benutzerfeeling“ her nicht. Da müsste es schon eine direkte Rückmeldung geben. Ich denke da eher daran, dass jede Komponente eine Schnittstelle hat, über die mit definierten Parametern schnell geprüft werden kann, obs passt oder nicht. Wenn eine Komponente also irgendwo hin verschoben werden soll, dann könnte der Ablauf sein:

- Ist der Komponenten-Typ hier (im Ziel-Container sozusagen) prinzipell erlaubt?
- Ist er an der Stelle erlaubt?
- Gibt es Optionen, die die Komponente einschränken?
- Wenn ja, übergib die Optionen an eine Test-Methode der Komponente, die was damit anzufangen weiß.

Basti

[Neq']

Hi Basti.

Zitat von Basti

Komponenten sind jedoch auch irgendwelche Formulare, deren Inhalte eigentlich in einen anderen Containern gespeichert werden sollten. Vielleicht wäre es geschickt, den Baum zu speichern, in dem auch, wie im Editor jeder Absatz etc. einen eigenen Knoten darstellt und für jeden Knoten einen standardisierten Container anzulegen, in den verschiedene Variablen gesetzt werden können. Aber so ganz klar hab ich das noch nicht, wie ich das serverseitig überhaupt abbilden möchte.

Was so gesehen vielleicht sogar interessant werden könnte. Wenn du den Baum in der Struktur für jeden Knoten die Id (die er auch im HTML bekommt) mitgibst, könntest du somit direkt auf die Id zugreifen, so würde der Container wegfallen. Die Baum-Struktur ändern ist dann keine riesengroße Sache mehr. Naja über die serverseitige Abbildung würde ich mir (jetzt) noch keine Sorgen machen, da du via JSON sehr schön Arrays, Listen, Objekt-Listen wie auch immer du es nennen willst erstellen kannst.

Zitat von Basti

Ich denke, es macht Sinn zu unterscheiden zwischen Komponenten, die quasi nur als Container fungieren, quasi nichts anderes sind als einer Definition, welche Komponente sie wie enthalten darf, kann, muss. Dann gibt es grundlegende Bausteine, die in allen möglichen Komponenten verwendet werden, wie z.B. Bild, Absatz etc. und dann eben dann „wirkliche“ Komponenten.

Natürlich, es wird nur eben sehr schwer das Ganze umzusetzen, stell ich mir zumindest vor.

Zitat von Basti

Ich denke, das passt schon vom „Benutzerfeeling“ her nicht. Da müsste es schon eine direkte Rückmeldung geben. Ich denke da eher daran, dass jede Komponente eine Schnittstelle hat, über die mit definierten Parametern schnell geprüft werden kann, obs passt oder nicht. Wenn eine Komponente also irgendwo hin verschoben werden soll, dann könnte der Ablauf sein:

- Ist der Komponenten-Typ hier (im Ziel-Container sozusagen) prinzipell erlaubt?
- Ist er an der Stelle erlaubt?
- Gibt es Optionen, die die Komponente einschränken?
- Wenn ja, übergib die Optionen an eine Test-Methode der Komponente, die was damit anzufangen weiß.

Stimmt, halte ich auch für eine interessantere Möglichkeit, sozusagen per Dropout (fallen lassen) wird der AJAX-Request an den Knoten gesendet und der gibt ein "ok" oder "failed". Schöner wäre es aber trotzdem wenn z.B der Knoten in einem grün leuchtet wenn man ihn fallen lassen darf und rot wenn nicht. Aber das ist dann wohl noch einen Schritt zu weit entfernt.

Patrick

[Basti]

Hallo Patrick.

Danke für dein Mitdenken.

Ich würde gerne den kompletten Baum einer Seite an den Browser schicken, dort dann aufbereiten, so dass dort schon alle Infos zusammen sind, welche Komponenten wo wie erlaubt sind etc.

Dazu wäre es wahrscheinlich geschickt, die Daten komplett in XML abzubilden und die Komponenten-Oberflächen als nachladbare Templates verfügbar zu machen und das eben clientseitig zu montieren.

Vielleicht könnte man das sogar so vereinheitlichen, dass die Komponenten selbst gar keinen eigenen JavaScript-Part benötigen, sondern sich der „Editor“ ein Feld mit Werten dann einfach wieder aus der Komponente rauszieht.

Argh, das ist wie ein Blindflug hier in für mich völligem Neuland sowas anzugehen. In PHP hab dann immer gleich ein paar Optionen parat mitsamt Vor- und Nachteilen, aber hier muss ich mich halb blind vortasten.

Basti

[Neq']

Hallo Basti.

Wie sieht's aus? Bist du bezüglich Konzept schon weiter gekommen? Wenn du JavaScript-Technisch Hilfe benötigst stehe ich dir gerne zur Seite, kann auch per Messenger (ICQ) sein bzw. würde ich am Projekt mitarbeiten.

Ansonsten stehe ich dir gerne weiterhin in diesem Thread mit meinen, hoffentlich, Denkanstößen zur Verfügung.

Patrick

[Basti]

Hi Patrick.

Vielen Dank. Ja, es geht voran, aber langsam. Bin einfach noch nicht so flüssig in JavaScript und jQuery und andere Aufträge und Anfragen brauchen auch Aufmerksamkeit. Vielleicht kann ich später noch eine neue Version hochladen…

Sitze auch gerade an einer Oberfläche/Konzept für die Website meines Partners hier im Büro und komm so langsam in die Materie rein:

http://dev.bastian-fenske.de/kuehnundmutig/

Macht in jedem Fall total Spaß.

Basti

[Neq']

Hi Basti,

ich hab mal schnell über den Code von dem angehängten Link überflogen. Auf die Schnelle ist mir z.B aufgefallen das du die Mehrdimensionalen-Arrays in JSON notieren solltest, so ein JSON-String sieht für deine Zwecke dann ca. so aus:

test = {'Projekt1': [{'num_rows':3,'color':'#3465a4'}], 'Projekt2':[{'num_rows': 3,'color':'#FF9900'}] }

Es gibt in jQuery auch eine each-Funktion, das funktioniert ungefähr so wie die foreach-Schleife in PHP. Von dieser solltest du auch öfters gebrauch machen (ich weiß, du verwendest sie in JavaScript notation, aber dann hat dein Framework keinen Sinn mehr).

So ein paar Kleinigkeiten auf der Schnelle.

Patrick

[Basti]

Hi.

Danke für die Tipps.

Hab jetzt nochmal einen Snapshot hochgeladen. Schwere Baustelle…

Ich hab jetzt zwischen die Blöcke (erstmal statisch) Felder gelegt, über die man neue Komponenten einbauen können soll. Die sollten dann die Info enthalten (bzw. diesen die Info zugeordnet werden), welche Komponenten da erlaubt sind und ebenso sollen dann beim Rumschieben bestehender Komponenten diese dort abgesetzt werden können (wenn erlaubt).

http://dev.bastian-fenske.de/cms-editor/editor_04.php

Basti

[Artemis]

Wenn ich etwas editieren will, wir an den Anfang immer einiges an HTML geschrieben, welches, wenn ich das nicht entferne im Text bleibt.

[Basti]

Ja, danke. Ist eben gerade „under heavy development“.

Basti

[Basti]

Nochmal von Vorne:

Jeder Seitentyp besteht (u.A.) aus einer Definition. In XML ausgedrückt könnte die so aussehen:

<?xml version="1.0" encoding="UTF-8"?>

<pagetype_definition id="mitarbeiter_seite">

	<section id="mitarbeiter_seite__ueberschrift">
		<component type="text.heading1" />
	</section>

	<section id="mitarbeiter_seite__freie_inhalte">
		<disallow_component type="profile"/>
	</section>

	<section id="mitarbeiter_seite__profile">
		<allow_section type="abteilung"/>
	</section>

</pagetype_definition>

Perspektivisch müssten diese Seitentypen dann vererbbar sein mit Einhängepunkten oder so, aber das ist erstmal nicht wichtig (geht in meiner jetzigen CMS-Fassung auch noch nicht).

Eine Sektion ist sowas, wie ein Container der entweder feste Inhalte (Komponenten oder Sektionen) gesetzt werden oder in den frei Komponenten gepackt werden können, einschränkbar durch Angaben von entweder disallow_component („Alle Komponenten außer“-) oder allow_component („Nur diese Komponenten“-). Außerdem kann mit allow_section noch angegeben werden, dass bestimmte (Unter-)Sektionen erlaubt sind.

Sektionen enthalten also entweder:

1. Platz für 0-n beliebige Komponenten, oder

2. Platz für 0-n Komponenten, die nicht von einem oder mehreren bestimmten Typen sind, oder

3. Platz für 0-n Komponenten oder Sektionen von einem bestimmten Typ oder aus einer Liste von erlaubten Typen, oder

4. Eine oder mehrere Komponenten und/oder Sektionen in einer festgelegten und unveränderlichen Reihenfolge.

Diese Definition wird dann durch bereits bestehende Komponenten der zu bearbeitenden Seite „gefüllt“, muss aber als solches für den Editor erhalten bleiben.

Eine „Untersektion“ könnte so aussehen:

<?xml version="1.0" encoding="UTF-8"?>

<section_definition id="abteilung">

	<section id="abteilung__ueberschrift">
		<component type="text.heading2" />
	</section>

	<section id="abteilung__kurzer_text">
		<component type="text.paragraph" />
	</section>

	<section id="abteilung__profile"">
		<allow_component type="profil"/>
	</section>

</section_definition>

Komponenten können selbst wiederum Komponenten enthalten (Das Mitarbeiter-Profil enthält z.B. eine Bild-Komponente, sowie vielleicht eine Absatz-Komponente für eine kurze Beschreibung).

Der Unterschied zwischen Komponenten und Sektionen besteht darin, dass Sektionen lediglich Definitionen von je einer Menge von Komponenten darstellen und keine eigene Funktionalität besitzen, im Editor auch nicht „aufklappbar“ komprimiert werden, sondern höchstens durch einen dünnen Rahmen oder so dargestellt werden sollen.

Jo, wie kommt das nun alles zusammen, in die Datenbank, in den Editor, in das System von Seiten-Versionierung, -Indizierung, Benutzerrechten…

Fühlt sich an, wie ein zu großes Stück Speck im Mund…

Basti

[Basti]

Hi.

Ich hab das PHP-seitig jetzt mal grob umgesetzt:

PHP-Code:

<?php

class Section
{
    protected $sName;
    protected $sType;
    protected $aDefinition;

    protected $aChildren = array();
    
    public function __construct($sName, $sType = 'free', $aDefinition = array())
    {
        $this->sName = $sName;
        $this->sType = $sType;
        $this->aDefinition = $aDefinition;
        
        switch($sType) {

            case 'fixed':

                foreach ($this->aDefinition as $sPosition => $mContent) {
                    
                    if ($mContent instanceof Section) {
                        
                        $this->aChildren[$sPosition] = $mContent;
                    
                    } else {
                        
                        $this->aChildren[$sPosition] = null;
                    }
                }
            break;
            
            case 'free':
            case 'allow':
            case 'disallow':
                break;

            default:
                throw new Exception('Unknown section type "' . $sType . '"');
        }
    }

    public function init($aComponentList = array())
    {
        $aSubSectionList = array();

        foreach ($aComponentList as $aComponent) {
            
            $sPosition = $aComponent['position'];
            
            if (false !== (strpos($sPosition, '.'))) {
                
                list($sPosition, $sSubPosition) = explode('.', $sPosition, 2);
                $aSubSectionList[$sPosition][$sSubPosition] = $aComponent;
                $aSubSectionList[$sPosition][$sSubPosition]['position'] = $sSubPosition;
                
            } else {
                
                if (!$this->isAllowed($sPosition, $aComponent))
                    throw new Exception('Component "' . $sPosition .'" not allowed in section "' . $this->sName . '"');

                $Component = $this->buildComponent($aComponent);

                $this->aChildren[$sPosition] = $Component;
            }
        }
        
        foreach($aSubSectionList as $sSubSection => $aList) {
            
            if (!$this->subSectionExists($sSubSection))
                throw new Exception('Subsection "' . $sSubSection . '" doesnt exist in section "' . $this->sName . '"');
                
            $this->aChildren[$sSubSection]->init($aList);
        }

        return $this;
    }
    
    protected function isAllowed($sName, $aComponent)
    {
        if (ctype_digit($sName)) {
            
            // Components in fixed sections must have named indices
            if ($this->sType === 'fixed')
                return false;
            
            $sType = $aComponent['type'];
            
            switch($this->sType) {

                case 'allow':
                    return in_array($sType, $this->aDefinition);
    
                case 'disallow':
                    return !in_array($sType, $this->aDefinition);
                    
            }
            
        } else {

            // Components in not fixed sections must have numerical indices
            if ($this->sType !== 'fixed')
                return false;
        }
        return true;
    }
    
    protected function subSectionExists($sId)
    {
        return array_key_exists($sId, $this->aChildren) && $this->aChildren[$sId] instanceof Section; 
    }
    
    protected function buildComponent($aData)
    {
        $iId      = (int) $aData['id'];
        $iVersion = (int) $aData['version'];
        $sType    = $aData['type'];
        $aOptions = $aData['options'];
        
        $sClass = class_exists('Component_' . $sType) ? 'Component_' . $sType : 'Component';
        
        return new $sClass($iId, $iVersion, $sType, $aOptions);
    }

    public function getArray()
    {
        $aDefinition = array();
        foreach ($this->aDefinition as $sKey => $mValue) {

            if ($mValue instanceof Section)    
                $mValue = 'Section';

            $aDefinition[$sKey] = $mValue;
        }
        
        $a = array(
            'type'       => 'Section',
            'definition' => $aDefinition,
            'children'   => array()
        );

        if (!empty($this->aChildren)) {
            
            foreach ($this->aChildren as $sPosition => $Child) {            

                $a['children'][$sPosition] = is_null($Child) ? null : $Child->getArray();
            }
        }
        return $a;
    }
}

PHP-Code:

<?php

class Component
{
    protected $iId;
    protected $iVersion;
    protected $sType;
    protected $aOption;

    public final function __construct($iId, $iVersion, $sType, $aOptions)
    {
        $this->iId      = $iId;
        $this->iVersion = $iVersion;
        $this->sType    = $sType;
        $this->aOptions = $aOptions;
        
        $this->init();
    }
    
    protected function init()
    {
    }

    public function getArray()
    {
        $a = array(
            'type'    => 'Component.' . $this->sType,
            'id'      => $this->iId,
            'version' => $this->iVersion,
            'options' => $this->aOptions
        );

        if (!empty($this->aChildren)) {
            
            foreach ($this->