BOINC Projektwebseiten verbessern

Aus Rechenkraft
Zur Navigation springen Zur Suche springen

Projekt zur Verbesserung der BOINC Projektwebseiten

Zur Zeit ist ein ändern des Aussehens der Projektwebseiten durch einen Projektbetreiber nur mit Änderungen im PHP-Quellcode des Projektes möglich. Dies setzt entsprechendes Wissen voraus und die geänderten Dateien sind danach nicht mehr so einfach zu aktualisieren, da Konflikte manuell bereinigt werden müssen. Dies ist ein erhöhter Aufwand für den Administrator des Projektes und führt dazu das der Quellcode des gesamten Projektes nicht mehr aktualisiert wird.

Ziel des Projektes

  • öffentlich zugängliche Projektwebseiten sollen übersichtlicher und aufgeräumter präsentiert werden (Benutzerfreundlichkeit)
  • redaktionelle Inhalte sollen einfach zu ändern/ergänzen sein, möglichst mit WYSIWYG-Editor (Administratorfreundlichkeit)
  • jedem Projekt soll es ermöglicht werden der Projektwebseite ein eigenes Aussehen zu geben (wiedererkennbarkeit)
  • Projektwebseiten sollten in jedem Browser und Betriebssystem gleich aussehen (Standardkompatibilität)
  • Ein Update des BOINC Quellcodes soll eigene Änderungen am Aussehen nicht überschreiben (Zukunftssicherheit)

Möglichkeiten der Umsetzung

Es gibt mittlerweile drei Richtungen in die ein solches Projekt gehen kann und die bereits von unterschiedlichen Personen geplant bzw. verfolgt werden.

Integration der Projektwebseite in ein bestehendes CMS

Hier wurde bereits vor längerer Zeit Drupal als System ausgewählt. Diese Integrierung wird von Einstein@home unter der Mitarbeit von Matt Blumberg (gridrepublic.org) geleitet.

Vorteile: stark für redaktionelle Inhalte da ein CMS dafür konstruiert wurde, viele Templates bereits vorhanden und Gemeinschaften welche dabei helfen können

Nachteile: ein CMS benötigt auch immer eine eigene Datenbank, Problem der Kopplung mit der BOINC-DB und der Erreichbarkeit wenn BOINC-Server ausgefallen (Webseite sollte weiterhin erreichbar sein)

unbedingt erforderliche Kenntnisse: PHP, SQL

Ein Content Management System (CMS) erlaubt die Erstellung redaktioneller Inhalte mittels WYSIWYG-Editor. Meist erfolgt die Speicherung der Texte in einer Datenbank und die Anzeige wird über eine Template Engine realisiert. Beispiele hierfür sind: Drupal, Joomla, typo3, Contao, ...

Erstellung zusätzlicher Stylesheets

Weitere Stylesheets, auf Basis der vorhandenen white.css und dark.css, welche das Aussehen von Drupal und/oder Wordpress imitieren. Dies ist die gewünschte Lösung von Dr. David Anderson.

Vorteile: wenig Änderungen am bestehenden Quellcode erforderlich, keine Ã?nderungen an der Datenbank nötig

Nachteile: aktueller Aufbau ist nicht Standardkompatibel, CSS allein erlaubt keine Umfangreiche Anpassung der Seite - der HTML-Aufbau muss auch immer mit betrachtet werden und der steht in mehreren Dateien inmitten des PHP-Quellcodes

unbedingt erforderliche Kenntnisse: CSS, HTML

Stylesheets werden von Browsern dazu benutzt festzulegen wie die Elemente einer Webseite angezeigt werden sollen. Dies reicht von einfachen Einstellungen wie Schriftart, -farbe, -größe bis hin zur Möglichkeit der aufklappbaren Menüstruktur (z.B. Drop-Down). Dies hängt jedoch auch immer von der vorhandenen HTML-Struktur ab.

Integration einer Template Engine in die Projektwebseiten

Durch eine vorgefertigte fremdgewartete Template Engine kann man einfach den Präsentationscode vom Anwendungscode trennen, ohne Eingriffe in die bestehende Datenbankstruktur. Erste Planung und ein Grobkonzept mit der Smarty Template Engine sind bereits von Christian Beer in Angriff genommen worden (siehe WebTemplateProposal).

Vorteile: klare Trennung zwischen Präsentations- und Anwendungsebene, Templates können, nach neuesten Standards, selbst erstellt und angepasst werden, keine Ã?nderungen an der Datenbank notwendig

Nachteile: WYSIWYG für redaktionelle Teil fehlt (kann jedoch nachgerüstet werden), sehr hoher Aufwand der Integrierung da umfangreiche Ã?nderungen am Quellcode erforderlich

unbedingt erforderliche Kenntnisse: PHP, HTML, CSS

Eine Web Template Engine führt den Präsentationscode mit dem Anwendungscode zusammen. Meist wird dies so gelöst das für jede anzuzeigende Seite (oder auch Gruppe von Seiten) eine HTML-Datei mit Platzhaltern erstellt wird, welche dann zum Zeitpunkt des Abrufens durch den Benutzer von dem eigentlichen PHP-Code mit den tatsächlichen Werten ersetzt werden. Zum Erstellen eines Templates muss man nicht genau wissen was der PHP-Code macht, es reicht welche Platzhalter in der darzustellenden Seite verfügbar sind.

Anmerkung: Ich habe mich deshalb für eine Template Engine entschieden weil ich finde das die derzeitige Struktur des Quellcodes und der Datenbank keine Integration in ein CMS zulassen, bzw. dadurch neue Probleme eingeführt werden. So sollte die CMS-DB auf einem anderen Server als die Projekt-DB liegen, da im Falle eines Ausfalls damit immer noch etwas angezeigt werden kann. Es fehlt auch an einer Schnittstelle wie das CMS Daten aus der BOINC-DB bekommt und wer die Nutzeranmeldung vollzieht. Man sollte sich nur einmal anmelden müssen und das CMS weiß welche Rechte ich habe usw. Somit ist auch bei der CMS Variante eine entsprechende Neustrukturierung des Quellcodes erforderlich, welche ich als sehr Umfangreich einschätze da eventuell auch eine Neustrukturierung der Datenbank vorgenommen werden muss. Die Variante mit Template Engine dagegen kann auf der BOINC-DB aufbauen und viel des bereits vorhandenen Quellcodes weiternutzen. Es ist lediglich ein Aufräumen des Codes hinsichtlich der Trennung Präsentations- und Anwendungscode erforderlich. Diese Variante ist auch Zukunftsorientierter da die einmal ausgewählte Template Engine leicht durch eine andere ersetzt werden kann, da der Unterbau (Anwendungscode) bereits vorhanden ist.

ähnliche Projekte

Wordpress nach BOINC Verknüpfung

Es gibt bereits ein Modul für Wordpress welches über einen 'external database authentication' Mechanismus die Authentifizierung von BOINC Teilnehmern des Projektes bei eine Wordpress Installation ermöglicht (WordPress Integration). Dies ist jedoch keine Integration in obigem Sinne da man weiterhin auf die vorhandenen Projektwebseiten angewiesen ist und Wordpress nur eine 'Zusatzleistung' für redaktionelle Inhalte für den Teilnehmer ist.