Ruby à la PHP

Geplaatst door Danny Lagrouw di, 11 jul 2006 10:50:00 GMT

Ondanks hun enthousiasme voor Ruby en Rails grijpen mensen nog vaak naar PHP als ze een “echte” website maken. Kijk bijvoorbeeld maar eens naar het aantal Ruby-blogs en Ruby-forums dat met PHP wordt opgezet. Dat leidt dan tot enige hoon van bezoekende Rubyisten, maar op zich is het wel begrijpelijk.
  • Veel mensen hebben meer ervaring met PHP, en kunnen daar dus sneller mee overweg.
  • De “kant-en-klare” software die in PHP verkrijgbaar is (zoals blogging software, cms-en e.d.) heeft jaren voorsprong op hun Ruby/Rails tegenhangers; en dat merk je in stabiliteit, gebruiksgemak, hoeveelheid features, documentatie en ondersteuning.
  • Door die jaren voorsprong is er ook meer keuze in PHP-land voor dat soort software.
  • Webhosting… probeer maar eens een Rails site in Nederland te laten hosten. En ook de hosting in het buitenland kent zo zijn problemen. Niet voor niets las ik in een verslag van RailsConf, “Shared hosting + Rails == Suck; Avoid if you can; Rails is ‘a bit of a pig’ compared to the average PHP site”.

Een vierde reden (er zijn er vast nog meer) ontdekte ik toen ik een inschrijfformulier online wilde zetten voor het volgende Profict-event (dit keer helaas geen Ruby, maar Java en Ajax). Het inschrijfformulier verstuurt een mail naar mij, met de inschrijfgegevens. Bovendien worden de gegevens via een http-request op de achtergrond doorgegeven aan een event-organisatie-systeem dat ik in Rails heb gebouwd (achteraf hoorde ik van Remco dat zo’n systeem in vijfvoud is gebouwd tijdens de RAD-race, maar gelukkig: Reuse is vastly overrated). Welnu, hoe maak je zo’n mailformulier, bestaande uit welgeteld één script om de gegevens te mailen en door te sturen? Juist, in PHP. Even afgezien van het feit dat de betreffende provider geen Ruby heeft geïnstalleerd: ik zou eigenlijk met Ruby hetzelfde willen kunnen doen als met PHP. Dus een .rhtml bestand dat de form parameters binnenkrijgt, daar een mail van bakt, en een nette “bedankt en tot ziens”-pagina terugstuurt naar de bezoeker.

Grappig genoeg is dit een van de eerste vragen die ik, maanden geleden, aan mijn destijds naburige Ruby-guru stelde. Ruby à la PHP, kan dat? Natuurlijk kan dat, bromde Remco tussen twee JSP-tags door. Met ERB of eRuby. En nu ik me dezelfde vraag weer stelde, besloot ik de proef op de som te nemen. Weliswaar puur theoretisch, want voordat de provider Ruby heeft draaien is het event waarschijnlijk al voorbij. ERB is inderdaad goed bruikbaar, alleen moet je er wel iets voor doen: je moet je .rhtml template inlezen, voeden aan ERB, en het resultaat, voorafgegaan door HTTP headers, terugsturen naar de webbrowser. Dat wil je niet telkens opnieuw doen (voor de slimmerikken die mij met bovenstaande verwijzing naar DHH om de oren willen slaan: lees vooral de laatste zin in zijn artikel). Gelukkig heeft iemand een scriptje geschreven dat dit voor je doet. Het artikel gaat over DreamHost, maar ik kon het script zonder problemen onder Windows gebruiken (alleen de eerste regel, pad naar ruby.exe, even nakijken). Mooi, nu kan ik een .rhtml bestand maken en opvragen in mijn webbrowser! Enkele kanttekeningen:
  • Ik heb nog niet ontdekt hoe ik in een stukje Ruby script in de .rhtml, output naar de webbrowser mee kan sturen. In PHP doe je dat met echo(). Ik vraag me af of het wel kan met deze opzet, aangezien het template eerst ge-evald wordt met ERB, en daarna pas het resultaat wordt teruggestuurd. Niet onoverkomelijk, maar wel jammer.
  • Als je bovenin je .rhtml require 'erb' en include ERB::Util zet, kun je verderop de uit Rails bekende h() method gebruiken om gegevens veilig te printen.
  • Je kunt request parameters opvragen met de CGI module: cgi = CGI.new; naam = cgi['naam'];
  • Het was allemaal begonnen met het versturen van mail. In PHP is dat één regel code. In Ruby… Ik ben er nog niet achter. Er zijn verschillende mail-gerelateerde modules die allemaal niet lijken te doen wat ik wil. Misschien kan ik gewoon ActionMailer gebruiken, maar ook dat zal meer code vergen. Heeft iemand een suggestie?
  • Ik ben geen security-expert, maar ik heb mijn twijfels over hoe veilig het is om dit erb.cgi script in de root van je website te zetten.

Misschien de interessantste kanttekening is: wil je dit wel? Gaan we hiermee niet terug naar wat PHP zo verwerpelijk maakt: ongestructureerde, mvc-loze spaghetticode? Ja, ik wil dit wel kunnen. Voor een simpel mailformulier zoals ik hierboven heb beschreven wil ik echt geen complete Rails applicatie optuigen. En ik wil in zo’n geval ook niet gedwongen zijn om met kromme tenen toch weer PHP te moeten hacken. Uiteraard moet je hiermee geen complete applicatie gaan schrijven—dan kom je inderdaad snel in een PHP-moeras terecht. Maar gelukkig is Rails uiteindelijk te leuk om niet te gebruiken als het ook maar een klein beetje nodig is!

Geplaatst in ,  | 8 reacties

Reacties

Laat een reactie achter

  1. RemVee zei ongeveer 1 uur later:
    PHP’s echo() functionaliteit kan je nabootsen met de _erbout string; 
    <% _erbout += Time.now %>
    is hetzelfde als: 
    <%= Time.now %>
    Komt je niet bekend voor uit syntax fouten in RHTML’s? ;)
  2. Matthijs Langenberg zei ongeveer 2 uur later:

    Danny ik denk dat de welbekende zin “Use the right tool for the right job” wel op deze post van toepassing is. Op het moment dat je een pagina met een klein script nodig bent, wat makkelijk in PHP te doen is, moet je het ook gewoon in PHP doen. Zo gauw dat script uitgebreider gaat worden, met data modellen (en MVC om de hoek komt kijken) kun je veel beter een Rails applicatie optuigen. PHP is een HTML embedded scripttaal, het is vanuit dat oogpunt gemaakt, en daar dient het dan ook goed voor, Ruby is met een totaal andere doelstelling gemaakt (een vervanger voor Perl/Python). Zou je een dergelijke pagina snel in Perl of Python willen doen in plaats van PHP? Ik denk het niet.

    Wil je Ruby op een zelfde manier als PHP gebruiken? Dan moet er een ‘wrapper’ omheen zodat je Ruby als PHP kunt benaderen vanuit een template. Maar waarom zou je Ruby als PHP willen gebruiken? Daar is PHP toch al voor?

  3. Juice10 zei ongeveer 5 uur later:

    maar ik kon het script zonder problemen onder Windows gebruiken

    “zonder problemen”, “windows” hihi dat zijn een paar woorden die ik niet in dezelfde zin had verwacht ;)

  4. Danny zei 1 dag later:

    @RemVee: nee, vreemd, ik zie nooit syntaxfouten ;)

    @Matthijs: je maakt mij niet wijs dat PHP “the best tool for any job” is. En ik heb inderdaad zulke pagina’s met Perl gemaakt, zonder enig probleem. Ik zie ook niet in waarom het niet met Ruby/ERB kan. Wat kan PHP dat Ruby niet kan? (omgekeerd is het een andere vraag!) De redenen om eerder PHP te gebruiken hebben niets te maken met de taal PHP en de taal Ruby, maar meer met omstandigheden zoals ik die in het begin heb beschreven; voor het grootste deel zijn dat tijdelijke probleempjes.

  5. Matthijs Langenberg zei 1 dag later:

    Dat php de beste tool is voor elke taak heb je mij niet horen zeggen, ik zeg alleen dat je de juiste tool voor een taak moet gebruiken in plaats van een tool overal voor te gebruiken, die daar misschien niet eens zo geschikt voor is. De vraag “Wat kan PHP dat Ruby niet kan?” moet je inderdaad omgekeerd stellen, Ruby kan meer dan PHP maar vergeet niet er nog een hele ‘omgeving’ om PHP heen hangt, de php.ini is er immers niet voor niets.

  6. Jonas Wouters zei 28 dagen later:

    Ik heb er al eens aan gedacht een belgische ruby on rails hosting server op te starten. Maar ik heb geen eigen bedrijf …

    De rest is er wel, 1e server, rackspace, ...

  7. Josja zei 37 dagen later:

    Hmm, mijn nek haren gaan staan door Danny’s “Ruby or die!”-houding. De leesfout in de kernzin van Matthijs’ opmerking spreekt boekdelen. Brrrr, Matthijs houding is veel gezonder en die deel ik dan ook.

    Dat je met PHP spaghetti code kan schrijven is natuurlijk helemaal niet erg tenzij je een kleuter ermee je website laat bouwen. Geef mij Ruby en ik kan daarin waarschijnlijk ook onleesbare ellende produceren. PHP heeft schoonheid foutjes maar de userbase, snelheid en functionaliteiten maken die meer dan goed.

    Nu wil ik (op kosten van de baas) mijn talen kennis uitbreiden met Ruby echter uitspraken zoals die van Danny doen mij huiveren. Maar toch; weet iemand een fatsoenlijke tent met een cursus Ruby?

    @Jonas: een nieuwe server van mij host Ruby. Echter vogel ik eerst liever zelf uit wat voor implicaties dat heeft op performance en stabiliteit voordat ik het ga sharen. Mail mij: josja@hotmail.com voor meer info.

  8. Danny zei 37 dagen later:

    Maar wie maakt hier de leesfout? Mijn antwoord op Matthijs luidde, vertaald: ik geloof niet dat PHP het beste hulpmiddel voor welke klus dan ook is. En hoewel dat uiteraard chargerend en tongue-in-cheek bedoeld is, heeft het in ieder geval niets met (mijn voorkeur voor) Ruby te maken.

    Je brengt me overigens zeer in verleiding tot inkoppen met je opmerking over het nog moeten leren van Ruby, nota bene op kosten van de baas. Maar ik zal niet op de man spelen. Misschien kun je (desnoods op eigen kosten) eens een boek over Ruby en/of Rails kopen en doorlezen.

    In elk geval bedankt voor je reactie. Dat geeft weer inspiratie voor een nieuw artikel.

    P.S.: Nou oke, één keer inkoppen dan. PHP heeft schoonheidsfoutjes? PHP is een schoonheidsfoutje!!

 (Laat url/e-mail achter »)

   Voorvertoning