calendar: virtual/physical/auto calendar
Je länger ich darüber nachdenke um so mehr komme ich von der Idee virtual calendar ab.
virtual:
Events für den Kalender per Mapping on-the-fly für die Mitglieder der selektierten Klasse erstellen. Dies eben virtuell im Speicher nach Möglichkeit gecacht.
physical:
Kalender mit realen Events (also in der DB)
auto
auto für automatisch, nicht weil es um KfZ geht...;)
Erstellung von realen Events anhand eines Mapping, indem man in create/write/delete entsprechende Events generiert.
Status Quo:
virtual scheint mir aus Performancegesichtsgründen nicht ratsam. Auf einer Klasse mit vielen records müsste auch ein Cache permanent invalidiert werden, sobald in die Klasse auf die gemappten Felder geschrieben wird. Das passiert in einer rege benutzten DB für z.B. sale_date permanent. Deshalb tendiere ich eher zu einem Feature auto calendar,
Konzept Auto-Kalender:
Konfiguration:
- Feld start_date auf der konfigurierten Klasse mappen
- opt. Feld end_date auf der konfigurierten Klasse mappen oder Feld default_duration ausfüllen
Umsetzung:
- In create/write/delete per Mixin einhaken
- evtl. zusätzliches Feld event_id auf dem Modell hinterlegen (für eindeutige Identifizierung von generierten Events)
Ob schlussendlich Konzept Auto-Kalender etwas für Use Case Jan bringt muss angeschaut werden. Die Funktion get_duration müsste ja sowieso erweitert/überschrieben werden, um die Werte für duration aus den sale lines zu emitteln. Dto. müssen für die Abnahmetermine Events geschrieben werden.
Momentan fühlt sich die generische Umsetzung für mich relativ aufwändig im Vergleich zum Nutzen an. Ich sehe nicht so recht die Verwendung. Demgegenüber ist die Umsetzung als customization für Use Case Jan im Vergleich schnell und einfach umsetzbar. Ich würde das Thema Auto-Kalender von daher gerne hintenan stellen, weil ich den generellen Nutzen momentan nicht sehe. Hierzu gerne Input.
Wo würden den solche generischen Kalender Sinn machen?
- sales, opportunities?
- projects, tasks?