/blog/wvk

Ein sehr guter Punkt, auf den mich Phillip gestern Abend hingewisen war, ist nun umgesetzt: Das Anlegen von neuen Kunden/Hostingaccounts ist nun in Transaktionen gekapselt, die voneinander vollkommen unabhängig sind. Gleichzeitig habe ich die Speicherung der temporären Transaktionsdaten aus der session-Variable herausgeholt und als normale AR-Entität in die Datenbank ausgelagert. Das geschah mit dem Hintergedanken, dass so eine Transaktion ja universell sein soll und es durchaus vorkommen könnte, dass man mal Arbeit anfängt und sich dann für die Mittagspause ausloggt. Oder eine Transaktion könnte Schritte enthalten, die von verschiedenen Benutzern ausgeführt werden müssen, z.B. die Bestätigung eines neuen Kennworts: Der Admin startet die Transaktion, eine Mail wird an den Kunden verschickt, dieser bestätigt sein neues Kennwort und damit ist die Transaktion erst abgeschlossen.

Nun wo also Arbeit über mehrere Sitzungen verteilt werden kann, macht es Sinn, die angefangenen Transaktionen gleich auf der Admin-Startseite anzeigen zu lassen. Dazu gibt's jetzt also ein neues Applet was genau dieses tut:

Diese Liste umfasst einen Link zu den jeweils offenen Transaktionen. Dazu wird pro Transaktion gespeichert, welcher Controller und welche Aktion aufgerufen werden muss, um die Arbeit weiterzuführen. Außerdem werden die Zeiten gespeichert, an denen die Transaktion gestartet bzw. bearbeitet wurde und von wem. Summa summarum schaut die Entity also so aus:

consolvix_transactions(id, number, user_id, controller, action, description, data, created_at, updated_at)

Das data-Feld enthält die als YAML serialisierten "Sitzungs"-Daten.

Als API-Funktionen stehen jedem Controller nun start_transaction, transaction_started?, cleanup_transaction', 'load_transaction sowie save_transaction zur Verfügung.:

• start_transaction(description, action, controller=nil) erstellt ein neues Transaktionsobjekt mit den angegebenen Daten.
• load_transaction lädt, sofern als Parameter eine gültige TID angegeben wurde, die Daten aus der Datenbank nach @transaction, welches danach dem Controller/den Views zur Verfügung steht.
• transaction_started? prüft nur, ob dieses Objekt NIL ist oder nicht.
• load_transaction sollte als before_filter aller Aktionen eingesetzt werden, die auf die transaktionen zugreifen möchten. Eingebunden wird der Filter über use_transaction_for :aktion1, :aktion2, ...
• save_transaction kommt entsprechend als after_filter an die Aktionen, die die Daten möglicherweise verändert haben könnten. Dies kann über save_transaction_for :aktion1, :action2, ... bewerkstelligt werden.

Am Beispiel "Anlegen eines Hosting-Accounts" passiert nun Folgendes: wird create_hosting_account aufgerufen, so wird eine neue Transaktion gestartet (sofern nicht als parameter bereits eine gültige TID übergeben wurde) und nach cha_do_create/1 weitergeleitet. Wird cha_do_create/[schritt-nummer] ohne gültige TID aufgerufen, wird erst geschaut, ob offene Transaktionen (für den aktuell eingeloggten Benutzer) vorhanden sind. Wenn nicht, wird nach create_hosting_account umgeleitet. Wenn eine Transaktion vorhanden ist, wird diese fortgeführt. Wenn mehrere Transaktionen offen sind, wird nach cha_select_transaction umgeleitet, wo der Benutzer die gewünschte Transaktion auswählt und schließlich wieder nach cha_do_create umgeleitet wird. Jederzeit kann abort_create aufgerufen werden, was die Transaktion beendet und löscht.

Ich werde jetzt mal sehen inwieweit es Sinn macht, alle "erstellen"- und "bearbeiten"-Dialoge in Transaktionen zu verpacken. Ich denke aber, dass es nur bei Aktionen mit mehr als einer Eingabemaske Sinn macht, da die zu speichernden Daten mindestens einmal gePOSTet werden müssen. Aber man könnte natürlich genausogut bei ein-formularigen Aktionen einen "Zwischenspeichern"-Button einbauen. Was sagen die Usability- und anderen Experten dazu?