Widgets - Stud.IP

Gerd Hoffmann, Uni Oldenburg
Ablauf




Impuls-Referat:
Gruppenarbeit:
Diskussion der Ergebnisse:
Workshop-Abschluss
20 Min.
30 Min.
10 Min.
lib/classes:
Anzeige

◦
◦
◦
Widget.php
WidgetContainer.php
WidgetElement.php
Db

◦
WidgetHelper.php
Datenbank-Tabellen:

widget_user

widget_default
public/templates/widgets:

widget-layout.php

widget.php
Widgets in:

Helpbar

Sidebar

Startseite
public/plugins_packages/core
◦


Umfragen, Meine aktuellen Termine, Schnellzugriff, Ankündigungen
[Profile]
Florian Bieringers Ansatz im Dev-Branch zu StEP 290:
neue Klasse

lib/models/WidgetLayout.php
◦
zeigt HomepagePlugins als Widgets im Profile an



plugin-type –- HomepagePlugin statt PortalPlugin

plugin-method –- getHomepageTemplate statt getPortalTemplate
noch nicht im Trunk
Bisher:


Profile-Widgets und Startseiten-Widgets haben separate
Lösungen
eher Einzellösungen für verschiedene Widget-Kategorien
Bisher:

Verteilung des Widget-Systems über mehrere Verzeichnisse

harte Codierung statt dynamischer Zuteilung
◦
Widgets müssen im Anzeige-Kontext durch Anweisungen erzeugt werden
Allgemeine Überlegung:
„Widget“ - Window Gadget (Gadget – „Zubehör“)

Widgets sind in der Regel wenig komplex und zeigen lediglich
Informationen an, die im System an anderer Stelle schon
vorhanden sind

◦

dementsprechend werden Web-Widgets häufig in Form kleiner Fragmente
von HTML und JavaScript angeboten
Programme für den Betrieb von Widgets werden als „WidgetEngines“ bezeichnet
Vorschlag:
bisher

lib/plugins/core
◦
PortalPlugin.class.php


neu
lib/widgets


core

db

engine
Vorschlag:
generische Lösung für systemweite Widgets

◦
=> Stud.IP-weiter Einsatz von Widgets möglich

ein Verzeichnis, welches das Widget-System enthält

ein Controller sieht automatisch nach, ob es für ihn Widgets
gibt

unterstützende Admin-Oberfläche für root
Vorschlag:

root soll entscheiden können, in welchem Kontext welche
Widgets angeboten werden

es soll Default-Widgets geben, welche die Benutzenden nicht
deaktivieren können

ein Widget soll einen Preset haben, der angibt, wo es benutzt
werden kann
Vorschlag einer visionären Architektur:




Wo ist das vorhandene Widget-System aus Anwender- oder
Entwickler-Sicht defizitär ?
Was sind eure persönlichen Anforderungen ?
Welches sind die zur Umsetzung passenden softwaretechnischen Konzepte für den Kern von Stud.IP ?
Was fehlt noch ?

für Widgets soll es einen eigenen Plugin-Typ geben

Widgets hängen sich in ihren Kontext selbständig sein

das Konzept zu Sidebar- und Helpbar-Widgets soll so bleiben,
wie es ist

der/die Entwickler/-in legt durch Angabe eines Presets fest, in
welchem Kontext sein/ihr WidgetPlugin angezeigt werden soll

jedes Widget kann „Core-Widget“ sein – nicht nur StartseitenWidgets





Core-Widgets sollten in: /public/plugins_packages/core
Root soll WidgetPlugins als Default aktivieren können, das heißt
sie sind durch die Benutzenden dann nicht deaktivierbar
die Rollenverwaltung der Widgets für die Startseite soll für die
systemweiten Widgets übernommen werden
zur Sicherstellung der korrekten Anzeige systemweiter Widgets
soll eine Widget-Engine erstellt werden
sie soll von der Widget-Verwaltung der Startseite abgeleitet
werden

der/die Entwickler/-in eines Plugins legt durch Einfügen eines
Widget-Containers fest, ob Widgets in seinem/ihren Plugin
erlaubt sind
Vielen Dank

Download Report