Bitte mal Kritik

[hotti]

Terminverwaltung

Backend ist auch verlinkt. Es geht bestimmt schöner... bitte mal um Hinweise, auch zur Eintragerei.

Danke im Vorab!

[ChrisB]

Hi,

Terminverwaltung

Backend ist auch verlinkt. Es geht bestimmt schöner... bitte mal um Hinweise, auch zur Eintragerei.

• /demoterms.html?yearly=34;yearly=35;day=15;month=5;year=2014 – das schreit so laut nach „schöneren“ URLs per rewriting, dass es in den Ohren schmerzt. Der yearly-Parameter, hier doppelt vorhanden, bei anderen Tagen nur einfach – der soll vermutlich den jeweiligen Event identifizieren? Wenn ja, wozu – das tut das Datum alleine doch auch schon. Und es macht die Seite anfällig für Manipulation von außen – wenn ich einen der yearly-Werte in bspw. 33 ändere, bekomme ich angezeigt, dass *heute* Muttertag wäre … also weg damit, und Termine abhängig vom Datum aus der Datenbank(/-haltung) lesen.

• „Jährlich wiederkehrende Termine bearbeiten” – will ich nicht, ich will einen nur einmaligen Termin eintrage – „ich finde aber den Link dazu nicht!!!1elf“ (Zitat unbedarfter Nutzer). Würde ich simpel „Termine bearbeiten/erstellen“ o.ä. draus machen.

• beim Anlegen eines einmaligen Termins „Jahr von, bis“ angeben zu müssen, mag zwar noch tolerabel sein – aber Termine derart *angezeigt* zu bekommen, ist verwirrend und damit Nutzer-unfreundlich (Bsp. gestern, 14.5.: „Einmalig: Heute ist Mittwoch (Jahr von-bis: 2014-2014)“ – die Angabe in den Klammern geht gar nicht, IMHO).

• Validierung Eingabedaten verbesserbar bis teilw. mangelhaft. Nicht-nummerischer Monat/Jahr werden zwar abgefangen – als Start-Jahr 2014 und End-Jahr 1007 gibt aber keine Misserfolgsmeldung, wird scheinbar klaglos angenommen, Termin taucht aber anschließend nicht in der Übersicht auf. Am exorbitant frühen Jahr scheint es nicht zu liegen, Start 2014 und Ende 2013 ergibt den gleichen Effekt. Erst wenn der Filter von 2014-2014 auf 2014 bis *irgendwas* geändert wird, tauchen diese Termine auch auf – wobei 2014-2013 ausreicht, um Termine mit Start-/Endjahr 2014/1007, 2014/2010 und 2014/2011 erscheinen zu lassen.

• ebenfalls nicht abgefangen wird bspw. Monat 4 und Tag 31, obwohl es keinen 31. April gibt.

• immerhin der 29.2. funktioniert korrekt, wird nur für Schaltjahre auch angezeigt. (Wobei auch hier wieder das Problem der URL-Manipulation besteht, /demoterms.html?yearly=41;day=29;month=2;year=2013 zeigt mir den Termin für den 29.2.2013 an. /demoterms.html?yearly=;day=29;month=2;year=2013 immerhin noch „Termine am 29.02.2013“.)

• ein Eintrag für die Jahre 2012 - 2016 taucht im Filter erst auf, wenn ich auch tatsächlich Jahre <= 2012 und >= 2016 auswähle – der Termin findet aber auch im Jahr 2013 statt, und trotzdem zeigt mir der Filter ihn bei Einschränkung auf 2012 - 2015 nicht an. Solche Überlappungen sollten auch berücksichtigt werden – wenn ich einen von jemand anderem angelegten Termin, der im Frontend-Kalendar am 16.5.2014 angezeigt wird, bearbeiten will, dann will ich nicht erst die(/eine) korrekte Jahres-range raten müssen, damit er in der Auflistung im Backend auch auftaucht.

– Start-/Übersichtsseite /demoterms.html zeigt „Termine am 15.05.2014 (heuriger Tag)“ – abgesehen von zumindest für meinen Geschmack zu viel Lokalkolorit, ich würde (heutiger Tag) oder schlicht (heute) bevorzugen – wenn ich dann auf /demoterms.html?yearly=34;yearly=35;day=15;month=5;year=2014 wechsle, was den gleichen Tag anzeigt, ist der plötzlich nicht mehr „heurig“ – inkonsequent.

MfG ChrisB

[hotti]

Moin,

@Felix, valigator war type, mit einem Schlag gesättigt, danke ;)

Herzlichen Dank Euch beiden.

Im Prizip sinds 2 Dinge, die ich ändern muss und die betreffen das Thema Multiple Models:

Das Model 'Monatliche Darstellung' befragt das Model 'Jährliche Darstellung' und das ist momentan das Backend für die jährlich wiederkehrenden Einträge, daraus resultieren die langen URLs, weil die Übergabe per URL gemacht wird.

Für einmalige Termine wird es ein weiteres Modell geben, evntl. optimiert mit Suchfunktion und die Uhrzeiten kommen auch noch hinzu.

Bis dann ;)

[Felix Riesterer]

Lieber hotti,

Terminverwaltung

da meckert der Validator. Das muss nicht sein...

Liebe Grüße,

Felix Riesterer.

[Meinereiner]

Es geht bestimmt schöner...

Was genau möchtest Du mit dem Tool bezwecken? Ist das nur für Dich selbst oder möchtest Du das allgemein für "jedermann" bereitstellen?

Falls letzteres, wirf mal einen Blick auf den Google Calendar. Genau SO stell ich mir sowas vor:

• Direkte Terminübersicht bei Monatsansicht, ohne einzelne Tage anklicken zu müssen.
• Direkteintrag beim Anklicken eines Tages
• Terminverschiebung per Drag&Drop

Klar, sowas baut man nicht mal eben selbst schnell nach. Aber wenn es solche Sachen schon so gut gibt, warum sollte man dann ein "schlechteres" Tool verwenden? (Datenschutzgründe und Google mal außen vor)

[tami]

hi,

(Datenschutzgründe und Google mal außen vor)

http://blog.mdosch.de/2013/08/30/android-kontakte-und-kalender-ueber-owncloud-synchronisieren/???
mfg

tami

[Meinereiner]

hi,

(Datenschutzgründe und Google mal außen vor)

http://blog.mdosch.de/2013/08/30/android-kontakte-und-kalender-ueber-owncloud-synchronisieren/???

Mir geht's weniger um die Synchronisation der Daten als vielmehr um die übersichtliche und einfach zu bedienende Weboberfläche des Google Calendars (deshalb auch der Wink dorthin). Ich bezweifle mal, dass ich die bei Owncloud dann auch habe, oder? Dort werden ja sicherlich nur die Daten abgelegt, um sie nicht mit Google zu teilen. Ich will meine Termine nicht am Handy verwalten, sondern nur dort angezeigt bekommen/erinnert werden...

[M.]

Mahlzeit,

http://blog.mdosch.de/2013/08/30/android-kontakte-und-kalender-ueber-owncloud-synchronisieren/???

Mal ausprobiert?
Klappt nicht wirklich so, dass man es benutzen kann. Mittlerweile bin ich komplett auf Seafile umgestgiegen als Clound und Baikal als CardDAV- und CalDAV-Server.
Es gibt sicher Funktionen, die ownCloud gegenüber Seafile hat, aber keine, die ich persönlich brauche.

[hotti]

hi,

Falls letzteres, wirf mal einen Blick auf den Google Calendar. Genau SO stell ich mir sowas vor:

Backend (administrative) und Darstellung in EINEM, genau das zu trennen ist mein Ziel. So werde ich auch mehrere Backends programmieren, ganz wie gewünscht und nach Bedarf ;)

• Direkte Terminübersicht bei Monatsansicht, ohne einzelne Tage anklicken zu müssen.

Oops, war eines meiner Ziele: Tage mit Terminen als Link zum Template durchzureichen und in der Monatsansicht klickbar zu machen.... kann ich aber auch raus nehmen und je Monat ALLE Einträge listen ;)

Klar, sowas baut man nicht mal eben selbst schnell nach.

Generalprobe war gestern, klar, die hat ein bischen länger gedauert und ForumSelf gibt mir immer gute Tipps ;)

Aber wenn es solche Sachen schon so gut gibt, warum sollte man dann ein "schlechteres" Tool verwenden?

Sag bloß noch, dass es ALLES schon gibt. Egal, was es an meinen Kalendern noch nicht gibt, geht demnächst ratz fatz und das funktioniert so wie es soll ;)

[hotti]

Was genau möchtest Du mit dem Tool bezwecken? Ist das nur für Dich selbst oder möchtest Du das allgemein für "jedermann" bereitstellen?

Ursprünglich geplant für eine Chronik rückwirkend über sehr sehr viele Jahre mit sehr sehr vielen Ereignissen..

[..] wirf mal einen Blick auf den Google Calendar.

Da ist z.B. der Oktober 1582 falsch dargestellt (Greg. Reform). Für heutige Ansprüche ist G+Cal absolut komfortabel, aber für eine Chronik ungeeignet.

Schönes Wochenende ;)

[M.]

Mahlzeit,

Terminverwaltung

Ich nutze sowas viel, aber ohne Zugriff über verschiedene Endgeräte ist für mich ein Terminplaner nutzlos.
Wieso baust du nicht auf CalDAV auf, dann hast du dieses Problem gelöst und bedienst andere Endgeräte.

Für PHP gibts da sabre/dav und ein kompletter Server auf dieser Basis Baikal. Nutze ich auf meinen Server und greife mit jedem CalDAV-Client drauf zu. Ob es was bei CPAN gibt, weiss ich nicht.

Aber grundsätzlich ne gute Sache wobei ich mich grad wieder frage, ob du nicht wieder mal das Rad neu erfindest ;) Vorallem ohne CalDAV im Hintergrund erweckt das den Eindruck.

[hotti]

hi Duda,

Aber grundsätzlich ne gute Sache wobei ich mich grad wieder frage, ob du nicht wieder mal das Rad neu erfindest ;)

Nein, isses nicht ;)

Aber was wirklich neu ist:
Die Beziehungen zwischen verschiedenen Terminarten (Jährlich, monatlich, fix usw.) und deren Darstellung werden bei mir im MVC über die Modelle geregelt.

(Also nicht über DB-Design oder Klassenhierarchien)

Und da geht, nach meiner anfänglichen Panne mit den unsinnig langen URLs (danke ChrisB) ab heute die Post ab, der Code wird klein und überschaubar und performant isses auch ;)

Schnittstellen für 3rd-Party-Anwendungen (Import/Export) sind im Handumdrehen programmiert...

Termingerechte Grüße,
  Horst

PS: Die Datenabstraktion über den MySQL Layer macht die wundervolle Perl-Funktion tie(), in PHP gibts nichts Vergleichbares.

Mein "Date::Calc Modul" habe ich nach dem benannt, der Mitte 16.JH die Berechnung fortlaufender Tage eingeführt hat: J.J. Scaliger. Der Julianische Tag heißt zwar in meinem Modul Scaliger.pm auch jd, hätte jedoch eher die Bezeichnung Scaliger-Tag verdient.

[hotti]

PS:

Mein "Date::Calc Modul" habe ich nach dem benannt, der Mitte 16.JH die Berechnung fortlaufender Tage eingeführt hat: J.J. Scaliger. Der Julianische Tag heißt zwar in meinem Modul Scaliger.pm auch jd, hätte jedoch eher die Bezeichnung Scaliger-Tag verdient.

Apropos "Rad neu erfinden":

In meinem Perl-Modul Scaliger.pm arbeite ich mit automatischen Getter-Methoden, das geht mit Perl schon lange, mindestens seit dem Jahr 2001 zu machen, da frage ich bei dem diesbezüglichen PHP-Voodoo auch, was zuerst da war, die Henne oder das Ei ;)

Scaliger.pm unterscheidet außerdem zwischen Programmier- und Benutzerfehlern:

  
my $sca = Scaliger->new( date => "29.2.2013" );  
                             |   ^ ab hier sind Benutzereingaben zu erwarten  
                             |  
                             ^ bis hier ist Programmierer zuständig  

Was die Fehlerbehandlung in der Anwendung extrem vereinfacht, beide Fälle werden über das Exception-Model abgewickelt. Schließlich kann ja auch nur im Kalendermodul selbst festgestellt werden, ob ein gültiges Datum eingegeben wurde und was daran evntl. falsch ist ;)

[M.]

Mahlzeit,

Aber was wirklich neu ist:
Die Beziehungen zwischen verschiedenen Terminarten (Jährlich, monatlich, fix usw.) und deren Darstellung werden bei mir im MVC über die Modelle geregelt.

(Also nicht über DB-Design oder Klassenhierarchien)

Solange das für den Benutzer keinen Mehrwert bietet, ist das vielleicht programmiertechnisch ne Innovation, aber interessiert keine Sau ;) Sorry, aber in dem Fall bin ich Benutzer und da interessiert mich der Code nicht.

Schnittstellen für 3rd-Party-Anwendungen (Import/Export) sind im Handumdrehen programmiert...

Dann würde ich dir weiterhin calDAV empfehlen, da die Anzeige dadurch Plattformunabhängig wird.

PS: Die Datenabstraktion über den MySQL Layer macht die wundervolle Perl-Funktion tie(), in PHP gibts nichts Vergleichbares.

Damit konnte ich bisher gut leben ;) Wenns was nicht gibt, schreib ich mir was oder nutze was anderes, das passt. Es gibt in Lua Dinge, die mir in Perl fehlen, in C Dinge, die ich in PHP vermisse usw. Ist nunmal so *g*

Also von einem Kalender erwarte ich in jedem Fall Anzeigen und Bearbeiten von jedem Endgerät aus (PC, Tablet, Handy ....). Wenn du das umsetzt wäre dein Projekt für mich interessant (ob ich deshalb umsteige, weiss ich nicht). Wenn der Kalender nur auf den Browser beschränkt ist, ist er für mich nicht relevant weil kaum nutzbar.
Aber es gibt vermutlich andere Anwender, denen das reicht, also macht mein Anspruch dein Projekt nicht schlecht ;)

[hotti]

hai ;)

Solange das für den Benutzer keinen Mehrwert bietet, ist das vielleicht programmiertechnisch ne Innovation, aber interessiert keine Sau ;)

Also gut, für den Programmierer (vielleicht interessierts ja jemanden):
Mit Multiple Models habe ich die Möglichkeit, dass nur _ein_ Model den Data-Layer bindet und nicht jedes Model; falls der Layer mal ausgetauscht oder geändert werden muss, betrifft das nur nur ein Model. Es ist eine kanonische Bindung, weil sie über das Model erfolgt, somit ist die Klassenbindung auch variabel.

Zwei Models und ein DataLayer Beispiel:

Model:Class        Model:Class                DataLayer
/user.html:User    /usergroup.html:UserGroup  MySQL::UserGroup

Kanonisch: Model /user.html befragt Model /usergroup.html nach Benutzergruppen (Multiple Models, 2 Models in MVC)
    Nur /usergroup.html ist an den DataLayer gebunden
Nicht-Kanonisch: Model /user.html fragt die Klasse UserGroup
    Nur /usergroup.html ist an den DataLayer gebunden
Direkt: Model /user.html bindet den Layer MySQL::UserGroup
    Beide Models binden den DataLayer

PS: Die Datenabstraktion über den MySQL Layer macht die wundervolle Perl-Funktion tie(), in PHP gibts nichts Vergleichbares.

Damit konnte ich bisher gut leben ;) Wenns was nicht gibt, schreib ich mir was oder nutze was anderes, das passt. Es gibt in Lua Dinge, die mir in Perl fehlen, in C Dinge, die ich in PHP vermisse usw. Ist nunmal so *g*

Perl tie() mit PHP nachzubilden ist Unfug, das gibt Makkaroni mit Zawiebeln ;)

Also von einem Kalender erwarte ich in jedem Fall Anzeigen und Bearbeiten von jedem Endgerät aus (PC, Tablet, Handy ....). Wenn du das umsetzt wäre dein Projekt für mich interessant (ob ich deshalb umsteige, weiss ich nicht). Wenn der Kalender nur auf den Browser beschränkt ist, ist er für mich nicht relevant weil kaum nutzbar.

Für mich gibts noch Einiges nachzulesen, bevor ich weitermache, die Ziele sind schon klar ;)

--Horst

[hotti]

hi,

PS: Die Datenabstraktion über den MySQL Layer macht die wundervolle Perl-Funktion tie(), in PHP gibts nichts Vergleichbares.

Damit konnte ich bisher gut leben ;) Wenns was nicht gibt, schreib ich mir was oder nutze was anderes, das passt. Es gibt in Lua Dinge, die mir in Perl fehlen, in C Dinge, die ich in PHP vermisse usw. Ist nunmal so *g*

Weil tie() so schön ist ;)

  
# Termin im Backend edit/update  
# Data-Layer binden  
my $yy = tie my %data, 'MySQL::Yearly', (base => 'myweb')  
   or die $@; # mögliche EX, DB nicht erreichbar, etc...  
  
# Klick auf Edit  
# Daten abholen über Termin-ID  
$yy->validate($id)  
    or return $self->errorP(descr => "ID is not valid", title => 'Eingabefehler');  
  
# Alle Eingabefelder werden befüllt  
foreach my $f( qw(month day descr title von bis sta sto)){  
   $self->{STASH}{$f} = $self->ents($self->trim($self->param($f)));  
}  
# ID kommt in ein hidden-Field  
$self->{STASH}{id} = $id;  
  
# nach der Prüfung der Eingaben  
# alles zurück in den Data-Hash  
foreach my $f( @fields ){  
  $data{$f} = $self->trim($self->param($f));  
}  
$yy->write; # persistent in DB  
  
# fertig ;)