Da bei meiner Modifikation des Kits das Aktivieren von neu registrierten Benutzern erforderlich ist, benötigte ich noch die Information, wann sich jemand neu registriert hat. Im User-Admin kann man zwar auch nach Registrierungsdatum sortieren, aber wer will schon ständig checken, ob da jemand hinzugekommen ist? Ich nicht.

Prinzipiell wären ja mindestens zwei Ansätze möglich: Erstens ein Control, dass alle Neuanmeldungen des letzten Monats anzeigt, und zweitens eine Email-Benachrichtigung dafür. Da man bei ersterem ja auch wieder ständig nachschauen muss, entschied ich mich für letzteres.

Um die neue Funktionalität möglichst sicher einzubauen, fügte ich sie nicht in der Registrierungsseite, sondern in der UserUtility-Klasse ein. Welches Skript auch immer eine Registrierung durchführt, wird dazu wohl diese Hilfsklasse verwenden. Diesen (doch recht tief sitzenden) Eingriff wollte ich nicht so ganz zwingend verankern. Schön fände ich, wenn man diese Funktion optional hinzuschalten könnte. web.confg? Jau! :)

...

Huch, wie die Zeit vergeht....:)

Nachdem ich in der vergangenen Woche der Benutzertabelle die Felder Status, Adressinfos und ein Geburtsdatum beschert habe, fehlte mir jetzt im FrontEnd noch eine Möglichkeit, die Benutzer an Geburtstage zu erinnern.Ursprünglich schwebte mir vor, die Geburtstagsinformationen in die Events-Section aufzunehmen. Ich merkte beim näheren hinsehen, dass sich das wohl eher schwierig gestalten sollte. Wie bekomme ich die Geburtstage da hinein? Ein Union-Selekt schied aus, da die User-Tabelle eigenständig ist, die Events aber zur Kategorie Content-Pages gehören. Relativ unvereinbar. Hmm.Sollte ich Events automatisiert in aus den Geburtstagsinfos erzeugen? Zu umständlich, und außerdem redundante Daten. Pfui!Dann fielen mir die WebBoxes ein. Eine WebBox, die die aktuell anliegenden Geburtstage (innerhalb der nächsten 2 Monate) anzeigt, und bei der ich über die Administration jederzeit entscheiden kann, ob und wo Geburtstage angezeigt werden. Bei der nicht angemeldete Benutzer keine...

Ich habe eben die Replikationsmethode des XmlRpc-Servers für den Geo-Datenabgleich mit einem PDA fertiggestellt.

Mit den techn. Details mag ich hier jetzt keinen langweilen, deswegen umreiße ich nur kurz die Arbeitsweise. Falls jemanden die genaue Umsetzung interessiert, bitte nachfragen. ;)

Der XmlRpc-Server nimmt alle im PDA bearbeiteten o. angelegten Datensätze entgegen, und prüft für jeden einzeln, ob dieser bereits existiert oder neu angelegt werden muss. Anlegen ist eher trivial. Weil im PDA nur eine Untermenge von Feldern eines Datensatzes (8 von knapp 100) verarbeitet wird, muss der Abgleich beim Aktualisieren Feldweise geschehen. Außerdem bekommen geänderte u. neu angelegte Datensätze den Status 'update', bzw. 'new'. Dadurch können sie im FrontEnd entsprechend dargestellt werden und lassen sich so auch  leicht herausfiltern, um sie z.B. mit anderen Servern abzugleichen.Dem PDA wird anschließend der komplette Datenbestand im XML-Format zurückgeliefert - natürlich reduziert um die Felder,...

Heute habe ich eine kleine Korrektur in Nicholas Christophers XmlRpcCS-Paket vorgenommen. Der XmlRpcServer war bislang nicht in der Lage, Methoden-Fehler an den Client durchzureichen. Gut, man kann sich damit behelfen NULL zurückzuliefern, wenn ein Fehler auftritt, oder eine Exception auslösen, aber das ist clientseitig natürlich wenig aussagekräftig. Das war mir zu dünn.

Aus Sicht des Servers erschien mir am vernünftigsten, im Fehlerfall eine XmlRpcException zu werfen. Diese verfügt ja schon über die Informationen faultCode und faultString, wie sie in der XmlRpc-Spec definiert sind. Beim Ausprobieren fiel mir jedoch auf, dass das Framework die XmlRpcException an irgendeiner Stelle in eine eigene XmlRpcException kapselt, so dass beim Client nur ein 'Application Error - target method threw an exception' herauskam. Wo war mein Fehlercode? Wo mein Fehlerstring?

Nach ein wenig Sucherei im Code gelang es mir, das Verhalten so umzustellen, dass eine Unterscheidung zwischen XmlRpcException und anderen...

Patrick und ich haben die Alpha-Version von Microsofts' PHP to ASP-Converter ausprobiert, und ihn einfach mal auf die Sourcen des Arena-Frameworks gehetzt. Es war nicht verwunderlich, dass dabei kein lauffähiges Produkt herauskam; dafür habe ich im Framework zuviel herumgetrickst (allein die DBObject-Klasse basiert ja hauptsächlich auf eine Art Reflection-Mechanismus...).

Andererseits waren wir überrascht, wie gut das Ergebnis teilweise aussah. Die DB.class.aspx (formerly known as DB.class.php) schien einen brauchbaren Eindruck zu machen. Das war irgendwie schon erstaunlich. Wenn man sich die Mühe machen würde und die Basisklassen alle manuell aus .aspx in .cs portieren (eher trivial) und mit einem Namensraum versehen würde, hätte man schon ein gutes Stück geschafft.

Mein Fazit: Den Großteil an Fleißarbeit nimmt einem der Converter ab, allerdings bleibt noch eine Menge manueller Nacharbeit übrig. Bei einem derart großen Projekt sicherlich kein Zuckerschlecken. Für kleinere Projekte (die vielleicht...