Archiv für den Monat: Juli 2010

Achtung: Newsletter-Problem

Quizfrage: Wie speichere ich folgendes, zugegebenermaßen sehr komplexe und nicht grad oft vorkommende Szenario in einer MySQL-Datenbank ab:

Es soll gespeichert werden, ob ein Nutzer zustimmt, einen Newsletter zu bekommen oder nicht

Ja, ich weiß, realitätsfern und Spezialanwendung, akademischer Aspekt und und und. Schon klar, aber als Denksportaufgabe für angehende Doktoren in Theopraktischer-Quanteninformatik bestimmt ein netter Tagesfüller.

Ein möglicher Ansatz – nochmal: wir reden hier über wirklich experimentelle Ansätze, die noch nie ein Mensch zuvor … usw, also weiter – also ein möglich Ansatz wäre folgender:

Man benutze ein Feld vom Typ varchar. Varchar, weil man nie weiß, ob sich evtl. mal die Anforderung ändern könnte. Stichwort hierbei: Skalierbarkeit! Denn wie schnell ändert sich so eine Anforderung und sollte man dann den falschen Datentypen ausgewählt haben (weil man natürlich mal wieder mit primitiven Ansätzen fern jeder akademischen Laufbahn daran gegangen ist und dachte, man könnte als Laie ein derart komplexes System auch nur im Ansatz verstehen), dann, ja dann dampft die Kacke! Also, varchar.

Und auch die Größe des varchar soll und muss disktutiert werden. Ein sicherlich guter Ansatz wäre, das Feld auf 255 Zeichen zu begrenzen – im Spezialfall kann das natürlich noch nach oben korrigiert werden, was aber wieder zu lasten der Konfiguration der Seitlichen Ausrichtung gehen kann und wird und nicht sollte.

Den Verschiedenen Zuständen geben wir die folgenden Namen: ‚active‘ beschreibt den Zustand des „wollenden Empfängers“ (genaue Definition erfolgt in einer Subklasse) und ‚inactive‘ den des dazu konträhren Zustandes. Für alle anderen wählen wir “ als den wohlbekannten Universaloperator auf der Menge der möglichen Zustände über „Ja“ und „Nein“ (präziser wäre ein oder, was aber im allgemeinen Sprachgebrauch eher verwirrt war und nicht mehr an seinen Platz fand. Das und war so nett und sprang kurzfristig ein.).

Wie man nun sieht, kann man selbst komplexe Vorgänge be- und verarbeiten, wenn man nur ruhig und logisch an die Sache heran geht und die Aufgaben in kleinen Abschnitten betrachtet (ist auch viel einfacher, eine Lupe zu benutzen anstelle eines Verkleinerungsglasses.).

Der Vollständigkeit halber sei noch folgender Zwischenruf erwähnt, der einen Eklat innerhalb des Beratungsgremiums hervorrief, als ein hochnäsig-arronanter Programmierer in geistiger Verwirrung den Satz ausrief:

Man benutzt ein (tiny)int-Feld und 0 und 1 zum speichern der Zustände Nein und Ja!

Unvorstellbar, wie dumm doch manche sind…

webEdition kann nicht gestartet werden. session.save_path = “

Aufruf des webEdition Login Fentsers und … *boom* Eine Fehlermeldung, aber was für eine:

WebEdition kann nicht gestartet werden: 0 – Die Variable session.save_path zeigt auf “. Dieses Verzeichnis gibt es nicht auf Ihrem Server!

*puh* Kramwühlsuch, warum, wieso, weshalb, ich hab doch nix verändert…*kopfkratz*

Nach langer Suche kontaktiere ich den Support meines Hosters, der löst das Problem in Sekunden:

In der Datei „/webEdition/we/include/conf/we_conf.inc.php“ muss ein Eintrag geändert werden, von

// Domain or IP address of the database server
define("DB_HOST","localhost");

auf diesen Wert

// Domain or IP address of the database server
define("DB_HOST","127.0.0.1:3306");

Aussage des Support-Mitarbeiters zu meiner Frage „Warum funktioniert das nicht mir localhost?“

Der Zugriff auf localhost ist aus Sicherheitsgründen deaktiviert!

Schön und gut, aber warum sagt die Fehlermeldung was über session.save_path?

Ganz einfach: webEdition versucht auf die Datenbank zuzugreifen, aufgrund der Blockade von localhost scheitert diese Verbindung. Allerdings gibt es dazu keine Rückmeldung, webEdition macht einfach weiter und liest die Konfigurationsdaten aus (zumindest versucht webEdition, dass zu machen). Unter diesen vielen Konf.-Daten ist auch die session.save_path, diese wird mit “ initialisiert. Da nun der Zugriff fehlschlägt, bleibt der Wert “ erhalten und nun prüft webEdition irgendwann, ob das Verzeichnis für die Sessions überhaupt vorhanden ist. Da dies nicht der Fall ist kommt o.a. Fehlermeldung – die natürlich völlig falsch ist.

Also, liebe webEdition-Leute: Bitte das ganze mal überprüfen, denn mit _dieser_ Meldung konnte ich nix anfangen. Ein Hinweis von wegen „Konnte die DB nicht öffnen, Fehlercode xyz“ wäre da um Längen besser gewesen.

jQuery Datepicker in Deutsch

jQuery’s Datepicker ist eine tolle Sache, leider funktioniert das ganze für deutsche Sprache nicht wie in der Doku beschrieben.

Allerdings habe ich in Dennis Blog einen super Eintrag entdeckt, wie es doch geht. Ein paar kleine Umformatierungen, da ich bei mit sowohl jQuery wie auch mootools einsetze und das ganze kann losgehen.


jQuery(function(jQuery)
{
jQuery.datepicker.regional['de'] = {clearText: 'löschen', clearStatus: 'aktuelles Datum löschen',
closeText: 'schließen', closeStatus: 'ohne Änderungen schließen',
prevText: ' nextText: 'Vor>', nextStatus: 'nächsten Monat zeigen',
currentText: 'heute', currentStatus: '',
monthNames: ['Januar','Februar','März','April','Mai','Juni',
'Juli','August','September','Oktober','November','Dezember'],
monthNamesShort: ['Jan','Feb','Mär','Apr','Mai','Jun',
'Jul','Aug','Sep','Okt','Nov','Dez'],
monthStatus: 'anderen Monat anzeigen', yearStatus: 'anderes Jahr anzeigen',
weekHeader: 'Wo', weekStatus: 'Woche des Monats',
dayNames: ['Sonntag','Montag','Dienstag','Mittwoch','Donnerstag','Freitag','Samstag'],
dayNamesShort: ['So','Mo','Di','Mi','Do','Fr','Sa'],
dayNamesMin: ['So','Mo','Di','Mi','Do','Fr','Sa'],
dayStatus: 'Setze DD als ersten Wochentag', dateStatus: 'Wähle D, M d',
dateFormat: 'dd.mm.yy', firstDay: 1,
initStatus: 'Wähle ein Datum', isRTL: false};
jQuery.datepicker.setDefaults(jQuery.datepicker.regional['de']);
});

Den Code bindet ihr einfach in euer JavaScript ein und ruft euren Datepicker ganz normal nun in Deutsch auf.

Viel Erfolg…