Hallo,

ich benötige einen Kalender für eine Webseite.
Das Problem ist halt mit den Terminen, die unterschiedliche Serienmuster haben.
z. B. Täglich, Wöchentlich (jeden 1., 2., und 4. Fr...), Jährlich (jeden Jan, März, August...)

Vorläufig sollen erst nur die Termine für den auswählten Monat angezeigt werden.
Einmal als Monatsblatt und einmal als Listanzeige.
Die Frag die sich mir stellt ist, soll ich pro Tag eine Abfrage an die Datenbank schicken
und das Ergebnis dann ausgeben oder ist es sinnvoller alle mögliche Termine
aus der DB auslesen und dann per Script auswert und anzeigen?
Welche der beiden Methoden ist Ressourcen schonender?

Gruß Ingo

Wie sehen denn die jeweiligen Abfragen aus?

Bis jetzt bin ich noch in der Planung.
Aber damit ich mich nicht in eine Richtung verrenne, habe ich hier
im Brainstorming gefragt.

Soso. Dann binde einfach Google Calendar ein. Das spart humane Ressourcen. ;)

Das ist ein sehr interessantes und nicht ganz einfaches Problem.

Am besten baust du dir eine SQL-Abfrage, die dir alle Termine zurückliefert, die in einem bestimmten Zeitraum (zwischen einem Start- und einem Enddatum) auftreten. Pro Tag eine Abfrage wäre schlecht. Besser pro Serienmuster eine Abfrage oder eine einzige, große Abfrage für alles. Mit der Abfrage brauchst du dann aber nicht 100% genau zu filtern, nur so, dass du schon mal viel weniger Termine rauskriegst als alle, die du in der Datenbank hast. Die Nachverarbeitung musst du dann eh mit PHP machen und dabei kannst du die rausschmeißen, die im gesuchten Monat nicht vorkommen.

Original geschrieben von onemorenerd
Soso. Dann binde einfach Google Calendar ein. Das spart humane Ressourcen. ;)

Zwischenfrage: Kann Google Calendar den deutschen Termin für den Weltspartag berechnen und anzeigen?

Zeig mir eine Kalender-Applikation, die das kann!

Das ist es ja gerade: Ich würde mir gerne eine basteln, die (auch) das kann. Und es wäre eben nett, wenn man einen Vergleich (u. A. zum Testen) hätte.

Ich kenne keine Applikation oder Service wo man Intervalle mit solchen Formeln wie "der letzte Werktag im Oktober" spezifizieren kann. Dieses Beispiel ist ja noch einfach, aber wo endet das? Welche Möglichkeiten sollte es geben und wie sähe das UI dafür aus?

Ich verstehe sehr gut, dass z.B. GCal sowas nicht anbietet. Es ist einfach zu komplex - algorithmisch und in der Bedienung. Sowas implementiert man nicht für nur eine handvoll Use Cases.

Speziell diesen Weltspartag kann man auch in wenigen Minuten für die nächsten X Jahre manuell anlegen. Wer es braucht, importiert diese Termine als XML oder abonniert den öffentlichen Kalender, in dem sie eingetragen sind.

Naja, es gibt ja den iCalendar-Standard (RFC 2445). Und darin kann man sich Muster wie "der letzte Werktag im Oktober" definieren. Das Problem ist nur, dass die Entwickler der meisten (aller?) Kalenderprogramme zu faul sind, den kompletten Standard zu implementieren, weil es der Ottonormalverbraucher vermutlich eh nicht nutzen würden.

Entwickler sind zu faul? Du bist dein eigener Auftraggeber, nicht wahr? (no offense)
Ich bin auch ein Entwickler. Wenn mir der Kunde sagt er hätte das gern, dann bekommt er das. Ich weise darauf hin, wenn etwas totaler Bullshit ist. Aber die Kosten-Nutzen-Rechnung muss der Kunde schon allein machen. Wenn er insistiert und bereit ist, dafür zu bezahlen, dann bekommt er den Käse.
Wenn ich mich wirklich mal weigere, dann sicher nicht aus Faulheit sondern aufgrund rationaler Beweggründe.

Das ist ja sehr schön, wenn du die Wünsche deiner Kunden erfüllst, aber es gibt auch noch die Kategorie der so genannten Standardsoftware, die sich eher am Ottonormalverbraucher orientiert. Die meisten Kalenderprogramme (zumindest die, die Einfluss auf die generelle Akzeptanz des iCalendar-Standards haben) gehören zu dieser Kategorie. Und viele von ihnen sind Open Source, wo Faulheit ein wichtiger Grund sein dürfte, warum Features nicht eingebaut werden.

Was hat denn Open Source mit Faulheit zu tun? :confused:

Ganz einfach,
die Hersteller von Open Source sind zu faul ihre Produkte zu Verkaufen! :teach:

Mich würde aber mal Interessieren was das alles mit meinem Thema zu tun? :dontknow:

Gruß Scotch

Original geschrieben von Scotch
die Hersteller von Open Source sind zu faul ihre Produkte zu Verkaufen!
Auf der Jagd nach dem Orden für den Schwachsinn des Monats oder was? :mad:
Mich würde aber mal Interessieren was das alles mit meinem Thema zu tun?Nichts. Wir gestatten uns, den Thread OT weiterzuführen. Dein Thema wurde bereits erschöpfend behandelt. Du hast keine konkreten Anforderungen oder Anhaltspunkte, um sinnvoll über die Struktur einzelner Codepartien zu diskutieren. Deswegen kann man nicht mehr dazu sagen, als es Hopka bereits getan hat.

Also ich stand auch mal vor einem ähnlichen Problem.
Ich musste Termine auf einer Website anzeigen, die der Administrator in irgendeiner Form erstellen kann.
Die Lösung war folgende:
Der Administrator benutzt Sunbird (http://www.sunbird-kalender.de/index.php) um seinen Kalender zu verwalten. Dort gibt es auch die Möglichkeit diesen zu publizieren (als ics-Format exportieren und auf einen Server hochladen).
Mein PHP Script parst dann den Kalender (sollten fast alle ics Standards mit drinne sein) und filtert beim parsen auch sofort nach einem bestimmten Zeitraum, dessen Anfang und Ende man als Argumente der Funktion übergeben kann, sodass nicht alles geparst und gespeichert werden muss. Das Script erstellt dann ein Array, dass alle Termine enthält, die in diesem Zeitraum liegen (die Regelmäßigen dann auch für die errechneten Daten), auf dass man dann entweder direkt oder per weiteren Funktionen zugreifen kann (GetMonth/GetDay).
Inwiefern meine Klasse, die die Datei parst "schnell" ist oder "Ressourcen spart" kann ich nicht sagen, da ich keinen Vergleich habe. Tatsache ist, dass es zumindest in meinem Fall nicht allzulang dauert, als dass es stören würde. Aber das ist wohl eher ein subjektives empfinden, objektiv kann ich das nicht beurteilen.
Was mir jedoch aufgefallen ist, dass die ics-Datei mit der Anzahl der Termine (natürlich auch wenn diese in der Vergangeheit liegen) größer wird (ist ja logisch) und deshalb auch die Zeit, die das Script zu parsen braucht, steigt. Bis jetzt bleibt jedoch noch alles in Rahmen, obwohl der Administrator seit 1-2 Jahren seine Termine damit verwaltet.