Benutzer:Dan-yell/Kalender-Konzeption/technische Umsetzung: Unterschied zwischen den Versionen

Aus München Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 6: Zeile 6:
Und folgende Vorteile: (als Gedankenexperiment) Demonstrationscharakter für professionelle Lösung
Und folgende Vorteile: (als Gedankenexperiment) Demonstrationscharakter für professionelle Lösung


==Collaborative Bearbeitung einer Termin-Datenbank==
==Funktion 1: Collaborative Bearbeitung einer Termin-Datenbank==
Ziele: Transparenz und Nachvollziehbarkeit, Nutzerrechteverwaltung, bequeme Eingabe- und Importmöglichkeiten, komfortables Einfügen von [[Benutzer:Dan-yell/Kalender-Konzeption/Tags|Tags (hier mehr dazu)]].
Ziele: Transparenz und Nachvollziehbarkeit, Nutzerrechteverwaltung, bequeme Eingabe- und Importmöglichkeiten, komfortables Einfügen von [[Benutzer:Dan-yell/Kalender-Konzeption/Tags|Tags (hier mehr dazu)]].
===Professionelle Lösung===
===Professionelle Lösung===
Zeile 18: Zeile 18:
** Jeder Termin ist eine eigene Wiki-Seite
** Jeder Termin ist eine eigene Wiki-Seite


==Terminzusammenstellung nach Tags==
==Funktion 2: Terminzusammenstellung nach Tags==
Ziel: Befehl zur Tag-gestützten Terminauswahl wird durch Parameter in der iCalendar-URL gegeben.
Ziel: Befehl zur Tag-gestützten Terminauswahl wird durch Parameter in der iCalendar-URL gegeben.
===Professionelle Lösung===
===Professionelle Lösung===
Zeile 31: Zeile 31:
* Yahoo! Pipes
* Yahoo! Pipes


==Ausgabe als iCalendar-Feed==
==Funktion 3: Ausgabe als iCalendar-Feed==
===Professionelle Lösung===
===Professionelle Lösung===
* Auswahl aus der Datenbank wird gemäß dem [https://de.wikipedia.org/wiki/ICalendar ICalendar-Syntax (.ics, .ifb, .iCal, .iFBf)] bei jedem Feed-Abruf zusammengestellt.
* Auswahl aus der Datenbank wird gemäß dem [https://de.wikipedia.org/wiki/ICalendar ICalendar-Syntax (.ics, .ifb, .iCal, .iFBf)] bei jedem Feed-Abruf zusammengestellt.

Version vom 6. Juni 2018, 10:13 Uhr

Diese Seite ist in Arbeit

Professionelle Lösungen bedeuten eine zumindest teilweise Neuprogrammierung, vermutlich in PHP. Sie sollten unter einer Creative-Commons-Linzenz veröffentlichbar sein und durch Dritte nachvollziehbare Strukturen besitzen Lösungen durch Nutzung bestehender Services haben dagegen folgende Nachteile: Und folgende Vorteile: (als Gedankenexperiment) Demonstrationscharakter für professionelle Lösung

Funktion 1: Collaborative Bearbeitung einer Termin-Datenbank

Ziele: Transparenz und Nachvollziehbarkeit, Nutzerrechteverwaltung, bequeme Eingabe- und Importmöglichkeiten, komfortables Einfügen von Tags (hier mehr dazu).

Professionelle Lösung

  • Ein Entwurf besteht bereits im Bearbeitungssystem von http://www.Lifeguide-München.de
    • Benutzergruppen mit unterschiedlichen Bearbeitungsrechten
    • Bearbeitungnen nachvollziehbar (nur Autor und Datum, nicht Änderung!)
    • Wesentliche Lücken bestehen z.B. bei der Einbindung von Tags

Lösung durch Nutzung bestehender Services

  • Mediawiki mit "gesichtete Versionen"-Erweiterung
    • -> Realistische Option, stellt aber besondere Anforderung an die weiteren Schritte
    • Jeder Termin ist eine eigene Wiki-Seite

Funktion 2: Terminzusammenstellung nach Tags

Ziel: Befehl zur Tag-gestützten Terminauswahl wird durch Parameter in der iCalendar-URL gegeben.

Professionelle Lösung

  • URL-gesteuerte Abfrage von Daten (vgl. die sofortige Generierung beliebig dimensionierter Bilder durch Mediawiki-Server: [1], [2], [3])
  • Dateiendung (.ical, .html, .PDF) bestimmt, in welchem Format die gefilterten Terminergebnisse ausgegeben werden.
  • Optional: weitere Parameter für bevorzugte Sprache, Sortierung, Zeitraum, etc.

(Not)Lösung durch Nutzung bestehender Services

  • Bei Nutzung von Mediawiki als Datenbank: Nutzung der Erweiterung DynamicPageList
    • Kein URL-gesteuerter Abruf, Tagauswahl müsste fest ins Wiki eingetragen werden
    • Einzige mögliche Operatoren: NOT, AND
  • Online-Tabellenkalkulation
  • Yahoo! Pipes

Funktion 3: Ausgabe als iCalendar-Feed

Professionelle Lösung

Lösung durch Nutzung bestehender Services

Herausforderungen

  • Aktualität
    • Var. 1: Überarbeitung der Datenbank: Jeden Tag läuft ein script/bot darüber und ändert einen Aktualitäts-Tag oder archiviert die Veranstaltung
    • Var. 2: Bei der Terminzusammenstellung werden vergangene Termine auch ohne eigenen Tag aussortiert
    • Extras: Präzise (relative und/oder absolute) Zeiträume können angegeben werden, z.B. "zukünftiges und max. 7 Tage altes" oder "alles vom 15. bis 28. Juni 2015".
  • Geschwindigkeit
    • Wichtig, damit Bearbeitende sofort Rückmeldung über das geänderte Feed bekommen
    • Wahrscheinlich kein Problem, wenn direkt auf die Datenbank zugegriffen wird

Einbindung des iCalendar-Feeds

  • Drupal (Anleitungen):
Importing and exporting iCalendar (.ics) feeds is one of the strongest features of the All-in-One Event Calendar system
  • Alternativen, falls Funktion bei weiteren Systemen fehlt oder unbefriedigend ist:
http://time.ly/
  • Mit zusätzlichem Programmieraufwand: Eigener iframe, der vom Server des Feedgenerators miterzeugt wird (z.B. vgl. Funktionalität von Google calendar oder einfach nur Terminliste)

Andere interessante Vorstöße