Framework-API sollte das Setzen von internen Felder (d.h. von Feldern, die vom Framework selbst verwaltet werden) nicht erlauben

[j3nsch]

Aktuell bietet die Framework-API die Möglichkeit interne Felder von außen zu setzen, z.B. ServerState{Created,Published,Modified,Deleted}. Das sollte unterbunden werden, da sonst möglicherweise inkonsistente Zustände provoziert werden können.

Daher hatten wir gerade am Telefon folgende Idee: die Felder können bis zum ersten Aufruf der Methode store() geändert werden. Anschließend hat nur noch das Framework darauf Zugriff.

Thoralfs Idee dazu:

• in der Klasse Opus_Model_Abstract eine Methode aufnehmen

    public function protectField($fieldname) {
      $this->_internalFields[] = $fieldname;
    }

• Nun scheitert folgender Aufruf:

    opus> $d = new Opus_Document();
    opus> $d->setServerDatePublished('2011-11-11T11:11:11+01:00');
    opus> $d->store()
    opus> $d->setServerDatePublished('2011-11-11T11:11:11+01:00');
    opus> $d->protectField('ServerDatePublished');
    opus> $d->setServerDatePublished('2011-11-11T11:11:11+01:00');
    Caught exception Opus_Model_Exception: Access to internal field not allowed: ServerDatePublished
    #0 /home/tklein/opus4-zib/framework/library/Opus/Model/Abstract.php(106): Opus_Model_Abstract->getField('ServerDatePubli...')
    #1 /home/tklein/opus4-zib/server/scripts/common/console.php(49) : eval()'d code(1): Opus_Model_Abstract->__call('setServerDatePu...', Array)
    #2 /home/tklein/opus4-zib/server/scripts/common/console.php(49) : eval()'d code(1): Opus_Document->setServerDatePublished('2011-11-11T11:1...')
    #3 /home/tklein/opus4-zib/server/scripts/common/console.php(49): eval()
    #4 /home/tklein/opus4-zib/server/scripts/opus-console.php(46): require_once('/home/tklein/op...')
    #5 {main}
    opus> 

Das Ausschließen von Feldern für das Editiern "von außen" (d.h. der Aufruf von protectField) könnnte im Bootstrap erfolgen.

[j3nsch]

Mit der auf Doctrine basierten Umsetzung der Datenbankanbindung in OPUS 4.8 ändert sich natürlich der Code komplett. Das Konzept von geschützten Feldern sollte aber auch für die neue Implementation geprüft und gegebenenfalls im Datenmodell berücksichtigt werden.

Sollte es Permissions für Nutzer geben, die auf der Ebene einzelner Felder geprüft werden. Ich denke es macht keinen Sinn einfach set-Funktionen zu blockieren. Die Einschränkung, dass diese Felder nur noch innerhalb der Model-Klasse, also nicht über die set-Funktion geändert werden können, schränkt die Möglichkeiten der Implementation beträchtlich ein. Im alten Framework sind Datenmodell, Datenbankanbindung, Workflow-Logic und weitere Funktionalität wie die Behandlung von Event für die DOI-Registrierung miteinander vermischt. Das macht Änderungen schwierig. Es macht den Code unübersichtlich. Die Klassen für die einzelnen Modelle sollten wesentlich weniger Verantwortung haben.