Code Walkthrough
De iDeal code zit in twee helper modules:
- SecurityHelper
- CheckoutHelper ( dit zal nog gerefactored worden naar een andere locatie)
SecurityHelper bevat generieke functies voor het signen en encrypten van data en een ssl connectie opzetten. CheckoutHelper bevat de interface naar de iDeal omgeving:
- directory request
- transaction request
- status request
Hoe deze functies aan te roepen is het makkelijkst te zien vanuit de test classes (CheckoutControllerTest, SecurityTest). Je geeft een hash met request parameters aan de functie en krijgt een hash met response parameters terug. Hierin zit dus geen workflow (wat te doen bij een failure, of als een transactie nog niet verwerkt is).
In iDealAccount.rb staan settings, zoals de lokatie van de certificaten en in config/privatedata.rb staat het passwoord en ideal-identifier gedefinieerd. De certificaten zijn geplaatst in config/security.
De checkout_controller wordt gebruikt voor de simpele testshop. Hier komt dan een voorbeeld workflow in.
overpeinzingen
De eerste release was erop gericht om de communicatie met iDeal te doorgronden. Volgens het principe 'Do the simplest thing that could possibly work' en 'you aint gonna need it' hebben we met een minimum aan classes en modules gewerkt. Daar waar de java en php code gebruik maakt van klassen om een response en request te definieren hebben wij gewoon een hash gebruikt. Scheelt al 8 klassen (twee superklassen en drie subklassen in de java code). Ik heb nog niet echt gekeken of dit een beetje kort door de bocht is. Wellicht dat het toch handig is om een response en request objecten te hebben. We kunnen daarin de validaties voor compleetheid plaatsen.
Ik heb wel bewust niet teveel naar de bestaande ontwerpen gekeken om te zien wat het resultaat van Test Driven Design zou worden.
