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
© Copyright 2024 ExpyDoc