Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring von "Opus\Import\Importer" für Erweiterbarkeit #18

Open
j3nsch opened this issue Jul 11, 2022 · 1 comment
Open

Refactoring von "Opus\Import\Importer" für Erweiterbarkeit #18

j3nsch opened this issue Jul 11, 2022 · 1 comment

Comments

@j3nsch
Copy link
Member

j3nsch commented Jul 11, 2022

Die Klasse Application_Import_Importer unterscheidet beim Import zwischen Sword-Kontext und normalen Importen. Für weitere Kontexte müssten nach diesem Model immer wieder die Funktionen der Klasse erweitert werden. Dabei besteht das Risiko existierende Funktionalität zu brechen und vorallem müssen alle Erweiterungen in den Kerncode einfließen und durch den Review-Prozess gehen.

Die Klasse sollte mindestens in eine Basisklasse und eine Sword-Implementation zerlegt werden. Im Kontext von Sword-Operation würde dann die dafür entsprechende Implementation genutzt werden.

So wären weiter Implementation für neue Anwendungsfälle möglich ohne, den existierenden Code ändern zu müssen.

Das ganze ist nur ein kleiner Schritt in Richtung Erweitebarkeit. Es muss beim Umbau ermittelt werden, warum es hier die Sonderbehandlungen für SWORD gibt und was das übergeordnete Konzept ist, damit Plugins für Formate bzw. Transport-Container unterstützt werden können.

Wir haben in OPUS leider zu viel fest verdrahtete Funktionalität, die für Erweiterungen immer wieder zentrale Änderungen erfordert. Das passiert vor allem deshalb, weil Features in einem engen Zeitrahmen ohne Ausräumen der vorhanden Design-Problem umgesetzt werden müssen.

Die Klasse enthält ausserdem eine Vielzahl von Funktionen für die Behandlung von verschiedenen Datenfeldern. Würden diese Handler als Klasse implementiert, könnten einzelne Verarbeitungsschritte leichter ausgetauscht oder ergänzt werden.

Intern: https://tickets.zib.de/jira/browse/OPUSVIER-4487

@j3nsch
Copy link
Member Author

j3nsch commented Jul 11, 2022

Für den Ausblick, denke ich momentan, dass die handle-Funktionen in Opus\Import\Importer in Zukunft kein Opus\Document direkt manipulieren sollten, sondern wie der kommende BibTeX-Import ein Array befüllen sollten aus dem dann im nächsten Verarbeitungsschritt ein Document-Objekt wird. Unser Datenmodell sehe ich als relativ stabil und damit auch die Struktur dieses Arrays. Wenn alle Import-Formate so arbeiten, kann Code der allemeine Import-Probleme lösen soll, an diesem Punkt, nach der Umwandlung in ein Array, ansetzen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant