[kopfaquarium]

Hallo,

mir qualmt gerade der Kopf, da ich nicht weiß, an welcher Stelle in der Anwendung ich die Möglichkeit zur Administration von dieser integrieren soll. Es gibt verschiedene Möglichkeiten und alle haben ihre Vor- und Nachteile.

Die Situation:
Es gibt eine bestehende Anwendung, welche aufgrund neuer Anforderungen angepasst werden soll. Da mir einige Sachen dabei nicht so gefallen, werde ich die Anwendung wohl mehr oder weniger von Grund auf neu schreiben. Daher habe ich jetzt auch die Möglichkeit einige Entscheidungen noch einmal zu überdenken und bestimmte Sachen besser zu lösen.
Ein solcher Punkt ist die Verwaltung der Software (Systemeinstellungen, Verwaltung der Inhalte, usw.) Probiert habe ich bisher die beiden Lösungen die Anwendung komplett auf der Anwendung heraus zu administrieren (Frontend) und die Anwendung in zwei Bereiche (Frontend und Backend) aufzuteilen. In dem einen bewegen sich die Nutzer und in dem anderen wird die Anwendung verwaltet.

Verwaltung im Backend
Bei der Lösung mit dem abgetrennten Frontend und Backend sind sehr durchwachsen. Auf der einen Seite ist alles ordentlich getrennt und die Anwendung kann zentral an einer Stelle verwaltet werden. Die Oberfläche kann speziell auf diese Bedürfnisse abgestimmt werden. Allerdings ist hier die Implementierung von neuen Funktionen sehr komplex und aufwendig. Schließlich muss die Funktion im FE (für die Nutzer) implementiert werden, aber auch im Backend, damit diese verwaltet werden kann – doppelter Code, höhere Fehleranfälligkeit, usw.

Ein Beispiel dazu: Ich wollte nachträglich der Anwendung einen Kleinanzeigen-Markt spendieren. Als erstes habe ich die Verwaltung dessen entwickelt. Bei der Entwicklung des Frontends haben sich aber einige neue Wünsche ergeben und so hat sich die Datenbankstruktur noch einmal geändert. Dies hatte natürlich zur Folge, dass nun die Sache nicht mehr administriert werden konnte, obwohl die Oberfläche schon entwickelt wurde. Diese musste zum Schluss also noch einmal angepasst werden (doppelte Arbeit).

Verwaltung im Frontend
Die Erfahrungen mit der ersten Lösung (Verwaltung im Frontend) war bisher sehr gut. Der Programmcode war überschaubar und nicht an zwei Stellen verankert. Auf Funktionen aus der Entwicklung für das Frontend konnte auch bei der Verwaltung zurückgegriffen werden (Beispielsweise auf Formulare, die auch die Nutzer ausfüllen können). Problematisch war dabei aber die Integration von Systemfunktionen (Wo sollte ich diese am besten im Frontend unterbringen?)

Der Code ist dabei immer sehr überschaubar gewesen. Außerdem haben die User, die die Anwendung/Inhalte verwaltet dabei, gleichzeitig die Anwendung auf Funktionstüchtigkeit geprüft. Schließlich haben sie das gleiche wie die "normalen" Benutzer gesehen, nur um ein paar Funktionen zur Verwaltung ergänzt.

Das Problem:
Wie gesagt, bisher bin ich mit der Lösung alles ins Frontend zu integrieren nicht schlecht gefahren. Allerdings haben sich jetzt bei dieser Anwendung neue Anforderungen ergeben, die diese Konzept mehr oder weniger über den Haufen werfen. Ab sofort soll es nämlich nicht mehr eine zentrale Oberfläche im Frontend geben, sondern mehrere unterschiedliche.

Je nach dem wo die Anwendung aufgerufen wird, werden unterschiedliche Templates ausgegeben. Teilweise unterscheiden sich auch die Funktionen (nicht in jeder Oberfläche sollen alle Funktionen enthalten sein – das ist Standortabhängig).

Die Verwaltung in einer zentralen Oberfläche ist damit hinfällig. Spricht also alles wieder für die Auftrennung in Frontend und Backend. Allerdings habe ich ja die Probleme, die ich oben angesprochen habe. Derzeit fallen mir drei Problemlösungen für die neue Anforderung ein:

• Es gibt kein Backend – Alles wird im Frontend verwaltet
  Vorteile
  • "Eine" Oberfläche und es kann auf bestehenden Code zurückgegriffen werden.
  • Verwalter testen auch gleich die Anwendung mit
  • Es müssen bei Änderungen nicht zwei "Anwendungen"/Oberflächen gepflegt werden.
  • Die Fehleranfälligkeit sinkt
  Nachteile
  • Es gibt im Frontend mehrere unterschiedliche Oberflächen -> Wo sollen jetzt die Daten gepflegt werden?
  • Theor. müsste jede Wartungsfunktion in jede Oberfläche integriert werden, damit diese sich in das jeweilige Aussehen einpasst.
• Neben dem Frontend gibt es auch ein Backend, in dem alles verwaltet wird
  Vorteile
  • Es müssen nicht mehrere Verwaltungsoberfläche gepflegt werden.
  • Es können auch Informationen verwaltet werden, die im Frontend nicht abgebildet werden (z.B. Systemfunktionen)
  Nachteile
  • Funktionen/Models müssen in zwei Oberflächen abgebildet werden
  • Die Anwendung wird erheblich komplexer und aufwendiger zu warten
• Verwaltung im Frontend – aber nur in einer Oberfläche
  Vorteile
  • Programmcode muss nur einmal geschrieben werden.
  • Fehleranfälligkeit ist stark reduziert
  • Neue Funktionen lassen sich leichter und schneller integrieren
  Nachteile
  • Evtl. können nicht alle Funktionen einer Anwendung in einer Oberfläche abgebildet werden.
  • Welche der Oberflächen soll jetzt dafür verwendet werden (welche hat Priorität?)

Ich hoffe mein Problem, meine Lösungsansätze und die Argumente sind in diesem langen Beitrag deutlich geworden. Welche Lösung würdet ihr bevorzugen (Warum?) oder habt ihr noch einen anderen Lösungsansatz?

Vielen Dank für eure Tipps,
Christian

[Basti]

Hallo Christian.

Für deine Entscheidung ist sicher wichtig, wie der Rest deiner Architektur aussieht. Ich habe ein Web-CMS entwickelt, das im Moment noch ohne Backend auskommt, es aber auch eigentlich Wurscht ist, ob du das nun Front- oder Backend nennst. Jedes Modul kennt seine eigenen Formulare, mit der die Benutzer mit unterschiedlichen Rechten die Daten manipulieren können. Wo die nun eingebunden werden, davon weiß das Modul selbst ja gar nichts. Ein Backend ist also nichts anderes, als vor allem ein Rahmen mit bestimmten Navigationselementen, um diese Module kompakter präsentieren zu können, also z.B. im Falle eines CMS eine Liste aller Seiten auf einer Ebene mit den Buttons „bearbeiten“ und „löschen“ und Optionen, die Seite zu verschieben.

Es wird also keine Arbeit doppelt gemacht, sondern lediglich die Zugänge zu den Modul-Formularen werden den jeweiligen Anforderungen entsprechend umgesetzt.

Hier wäre also die Frage, ob du sowas, wie eine gemeinsame Basis für alle Komponenten entwickeln kannst, ganz gleich, wo und wie sie eingebunden werden.

Falls es sich um eine Web-Applikation handelt, schau dir doch z.B. mal eZ Publish an. Hier gibt es verschiedene Zugänge auf eine Site und für diese kannst du jeweils einzelne Templates überschreiben, die in dem System sehr mächtig sind. Du kannst also auch wieder dein Modul programmieren und dann je nach Access Point landest du in einem Template, das den gleichen Zugriff auf den Inhaltsknoten hat, wie das entsprechende Template eines anderen Zugangs.

Das ist in einer Web-Applikation nicht problematisch umzusetzen. Musst eigentlich nur verschiedene Themes (oder nenn es, wie du willst) anlegen und je Zugriffspunkt eine Reihenfolge festlegen, in welchen Themes nach dem Template gesucht werden muss.

Beispiel:
Modul Kleinanzeigen, View „edit“, drei Zugänge: frontend, backend1 und backend2, 4 Themes: base, frontend, backend1, backend2, folgende Theme-Reihenfolge für die Zugänge:

frontend: frontend, base
backend1: backend1, frontend, base
backend2: backend2, frontend, base

Wenn du jetzt über backend2 reingehst, sucht er nach Templates in folgender Reihenfolge:

themes/backend2/components/classifieds/edit
themes/frontend/components/classifieds/edit
themes/base/components/classifieds/edit

Und die Templates müssen eben nur bei Bedarf neu geschrieben werden. Eine weitere Option wäre in dem Fall (Web-App) auch, hier XSLT zu ermöglichen, um die Templates nicht komplett überschreiben zu müssen, sondern die Ausgabe auch einfach nur ein wenig umbiegen zu können. Mit den Style-Sheets läuft das dann entsprechend.

Basti

[kopfaquarium]

Zitat von Basti

Falls es sich um eine Web-Applikation handelt

Ja, es handelt sich um eine Web-Applikation.

So richtig habe ich deinen Gedankengang mit den verschiedenen Templates und Interfaces noch nicht verstanden. Ich versuche das mal so wiederzugeben, wie ich das aufgefasst habe.

Alle Formulare und Methoden zur Verwaltung sollen in die jeweiligen Modul integriert werden. Soweit war dies auch geplant, da die Anwendung auch unabhängig von einzelnen Module funktionieren soll. Die beiden Einheiten Controller und Modell wären somit gleich. Alle Ausgabe-Templates sollen in einem Ordner "views" liegen, welcher wiederum Unterordner mit der Bezeichnung der Controller enthält. Pro Aktion im Controller gibt es eine Template-Datei (so ist es bisher). Für die einzelnen Oberflächen muss es aber jetzt mehrere dieser Dateien geben, die zwar immer das gleiche ausgeben aber halt immer mit einer anderen HTML-Struktur.

Jetzt gibt es aber das "Problem" das sich die Oberflächen teilweise erheblich voneinander unterscheiden. Die eine Oberfläche soll hauptsächlich über Terminal-Systeme aufgerufen werden. Daher werden hier für komplexe Formulare Assistenten eingesetzt, die durch die einzelnen Schritte führen. Bei einer anderen Oberfläche ist mehr Platz und da soll die Navigation durch Reiter erfolgen. Hier unterscheidet sich also nicht nur das Template, sondern auch die Verarbeitung der Formulare voneinander.

Das würde ja eigentlich bedeuten, dass ich bei der Verarbeitung im Controller und Modell schon Rücksicht auf die auszugebene Oberfläche nehmen muss und auch hier die verschiedenen Ausgabe-Möglichkeiten implementieren und fest an eine Oberfläche binden muss. Ändert sich dann aber an den Oberflächen etwas (eine neue wird hinzugefügt etc.) würde dies ja auch Auswirkungen auf diesen Bereich haben.

Irgendwie ist das auch nicht so richtig prickelnd oder habe ich etwas falsch verstanden? Wie wäre bei deiner Methode denn das URL-Design?


Grüße,
Christian

[Basti]

Zitat von kopfaquarium

Pro Aktion im Controller gibt es eine Template-Datei (so ist es bisher).

Damit kommst du aber nicht weit, oder? Mag sein, dass das oft hinhaut, aber mitunter muss ein Controller ja auch unterschiedliche Views einbinden können, es sei denn diese sind so komplex, dass du sie als eine View zusammenfassen kannst (ein Wizard zum Beispiel).

Jetzt gibt es aber das "Problem" das sich die Oberflächen teilweise erheblich voneinander unterscheiden. Die eine Oberfläche soll hauptsächlich über Terminal-Systeme aufgerufen werden. Daher werden hier für komplexe Formulare Assistenten eingesetzt, die durch die einzelnen Schritte führen. Bei einer anderen Oberfläche ist mehr Platz und da soll die Navigation durch Reiter erfolgen. Hier unterscheidet sich also nicht nur das Template, sondern auch die Verarbeitung der Formulare voneinander.

Klar, dann brauchts natürlich nicht nur unterscheideliche Views, sondern auch unterschiedliche Controller. Sinnvoll halt, den ganzen Krempel zum Manipulieren der Daten wirklich in der Model-Schicht zu belassen und in den Controllern nur zu kontrollieren, ob das so hinhaut und den Benutzer zu führen. Mit Vererbung kannst du hier sicherlich einige Redundanzen raussparen, wie z.B. das Überprüfen der Rechte des Benutzers und was sich halt sonst noch überschneidet. Gäb dann also z.B. einen Controller Classified_Edit_Web, um beim Beispiel Kleinanziegen zu bleiben und einen Classified_Edit_CommandLine, die beide von einem Classified_Edit abgeleitet sind. Der für die Kommandozeile könnte auch vom Web-Controller abgeleitet sein und nur das nötige überschreiben. Die Controller kannst du dann ja auch automatisch einbinden lassen, ähnlich den Templates (Wenn GesuchterController_Frontend nicht existiert, dann schaue anch GesuchterController und binde den ein).

Wie wäre bei deiner Methode denn das URL-Design?

Das System muss lediglich unterscheiden können, welche Oberfläche angefragt ist. Dazu kannst du über eine andere (Sub-)Domain gehen, über einen anderen Port, kannst das am Benutzer festmachen, an einem URI-Parameter, Cookie, IP des Requests, Uhrzeit, oder natürlich auch einem Teil des Pfades im URI. Vielleicht braucht jede Oberfläche auch sein eigenes URI-Design, keine Ahnung. Dazu baust du halt z.B. je Zugang einen eigenen FrontController oder zumindest einen eigenen Router.

Basti