Aber dafür gibt's heute was Feines: ein SVN-Diff-Export-Tool!

Wer sich nun fragt, was das sein soll – ganz einfach: ein PHP-Script, das aus einem Diff zweier SVN-Revisions die geänderten Dateien und Verzeichnisse exportiert.

Das ist sehr praktisch, wenn man einem Kunden "nur mal eben" die Changes schicken will…und dann im Normalfall per Hand aus der WorkingCopy exportieren würde.

So geht's doch viel einfacher – URL zum Repo (bzw. Repo-Pfad) angeben, ggfls. User/Pass, Start- (und optional End-) -Revison, Export-Verzeichnis, fertig.

Ein paar kleine Hinweise noch:

• es ist eine Quick'n'Dirty-Lösung, dementsprechend ist der Code nicht unbedingt "aufgehübscht".
• ggfls. müssen die Pfade zu "svn diff" und "svn cat" im Script (Zeile 46/47) angepasst werden
• sofern open_basedir gesetzt ist dies am besten deaktivieren: /usr/bin/php -d open_basedir="" /path/to/svnDiffExport.php
• sollte das Script abbrechen sollten memory_limit und max_execution_time geprüft werden
• Subversion sollte in einer aktuellen Version vorliegen, da "svn diff" mit den Optionen "–summary" und "–xml" verwendet wird
• das Script verwendet SimpleXML zum Parsen des Diff-Outputs – dementsprechend muss die PHP-Extension installiert sein
• svn:externals werden nicht exportiert
• Getestet wurde es nur kurz, dafür aber auf Windows und Debian Lenny – auf beiden lief es problemlos
• Wie üblich: Keine Garantie & Haftung! Siehe Lizenz.

Download: svnDiffExport.zip

Ist schon ganz gut gelungen, wie ich finde.

Das Schöne daran: ich kann meine Objekte wie z.B. Services (UserManagement), Zend_Db etc. direkt in den Resource-Plugins (für's Bootstrappen) definieren, sie werden aber noch nicht geladen/initialisiert.

Erst wenn ich mir, wie ich es nenne, eine Komponente "hole" wird der ganze benötigte "Rattenschwanz" geladen.

Warum das so toll ist? Ganz einfach: Wozu soll ich eine DB-Verbindung aufbauen, wenn diese für den Request nicht benötigt wird?

Sollte sie doch an irgend einer Stelle benötigt werden mache ich ein einfaches exTSend_DIContainer::getComponent('database') (sofern ich die Komponente "database" genannt habe) und bekomme ein funktionsfähiges Zend_Db-Objekt zurück.

Da ich noch nicht ausreichend Zeit zum Testen hatte stell ich den Code einfach mal so zur Diskussion, ohne Anspruch auf Vollständigkeit oder Funktionsfähigkeit.

Wer es nützlich findet darf es einsetzen, sollte aber bedenken, dass er mal drüber schauen sollte, ob alles "OK" ist.

Wenn ich mal wieder Zeit finde wird das Ganze auch endlich mal auf exTSend.com aktualisiert…wenn…ja wenn…

Ich würde mich jedenfalls über ein wenig Feedback freuen – so denn überhaupt jemand den leider noch immer lahmenden Blog liest…ich gelobe Besserung in naher Zukunft

Download: exTSend-DIContainer

Da diese teils doch recht aufwändig sind habe ich diese aus dem "normalen" OpenSource-exTSend ausgelagert und das Ganze einfach "exTSendPro" getauft.

"Pro" bedeutet in diesem Fall auch "kostenpflichtig", da die Entwicklung, Tests und Pflege der Plugins Zeit kostet.

Zudem sind es in der Regel Erweiterungen, die primär zum Geld verdienen eingesetzt werden – und da denke ich ganz einfach: Wer Geld verdienen will muss auch Geld ausgeben.

Denn zu guter Letzt ist es doch so, dass ich nunmal mit Programmierung meinen Lebensunterhalt (und meine Hobbies) finanziere.

Eine wohl sehr nützliche Erweiterung ist die PayPal-Klasse, mit der es, zumindest in der aktuellen Version, möglich ist, Zahlungsabwicklungen z.B. aus einem Warenkorb heraus anzustoßen.

Man kann jetzt freilich darüber streiten, ob es denn nicht auch die von PayPal gelieferten Standardklassen tun…

Ich sage "nein", insbesondere, wenn man Wert auf sauberen Code legt und ganz besonders, wenn man möglichst ZF-nah bleiben möchte.

Praktischer Weise unterstützt exTSendPro_Service_PayPal sowohl die PayPal-SOAP-Schnittstelle als auch die NVP-Schnittstelle.

Im Grunde ist es relativ egal, welche man nutzt – der Code für die Verwendung von exTSendPro_Service_PayPal ist der gleiche, da die Parameter intern entsprechend umgesetzt werden.

Gleiches gilt natürlich auch für die erhaltenen Antworten – diese werden bei beiden Übermittlungsarten vereinheitlicht.

Hier mal ein kleiner Auszug, wie so ein Request (SOAP, PayPal-Sandbox) ablaufen würde:

$authModel = new exTSendPro_Service_PayPal_Model_Authentication(<user>, <pass>, <signature>, <cert>, <cert_pass>, <subject>);
$paypalObject = exTSendPro_Service_PayPal::factory(exTSendPro_Service_PayPal::API_SOAP, exTSendPro_Service_PayPal::ENVIRONMENT_SANDBOX, $authModel);
$request = new exTSendPro_Service_PayPal_Request_SetExpressCheckout();
$request->addParameterValue('MaxAmount', $orderTotal);
$request->getParameterByNameAndIndex('MaxAmount', 0)->getAttribute('currencyID')->setValue('EUR');
//...
$result = $paypalObject->execute($request);
if('success' === $result->getStatus()) {
      $parameters = $result->getParameters();
}

Ist doch deutlich einfacher, wenn einem das Request-Object dann auch noch sagen kann, welche Daten wohin müssen und Pflicht sind

Nun ja, viel erzählt…bleibt die spannende Frage "Wo gibt's das Teil"?

Da muss ich leider (derzeit) enttäuschen – bisher ist nur ein Bruchteil der PayPal-API-Funktionen umgesetzt, nämlich der, der Zahlungen ermöglicht.

Und bevor ich das Ganze auf die Öffentlichkeit loslasse möchte ich doch noch einige Funktionen mehr integrieren.

Dazu fehlt aber, wie üblich eben, die liebe Zeit.

Wer sich dennoch dafür interessiert (oder eh nur den ExpressCheckout benötigt) darf sich gerne per eMail melden – mit kleinen Anreizen kriegt man mich bestimmt dazu, den aktuellen Stand zu "überlassen" oder etwas Zeit für die Weiterentwicklung freizuschaufeln

Ach so, bevor ich es vergesse, das zweite derzeit aktiv genutzte "Pro-Modul" ist eine sehr praktische Klasse für mehrseitige Formulare, die es erlaubt, mehrseitige Formulare mit diversen Bedingungen zu erstellen.

So wird z.B. ermöglicht, einen Schritt mehrfach zu durchlaufen was z.B. für Konfigurationsassistenten sehr praktisch ist.

Ebenfalls sehr nützlich ist die Option, bestimmte Schritte in Abhängigkeit von Angaben aus vorherigen Schritten zu gestalten oder sogar ganz zu entfernen.

Bevor nun jemand denkt, ich hätte da eine komplett neue Zend_Form-Implementation erstellt den kann ich beruhigen – exTSendPro_Form_MultiPage handlet nur die die "Mehrseitigkeit", die Formulare werden weiterhin per Zend_Form erstellt und lediglich an exTSendPro_Form_MultiPage zur "Verwaltung" weitergereicht.

Wer dazu mehr erfahren möchte der möge mich bitte kontaktieren – Telefonnummer und Mailadresse stehen ja im Impressum.