Next Previous Contents

11. <3.3>: Anonyme moduler og mod_ruby

Dersom du bare skal kjøre en webapplikasjon på en webserver, trenger du ikke bekymre deg om forsøpling av navnerommene til fortolker-instansene i Apache-prosessene. Du kan bare passe på selv at du ikke roter til og lager to metoder med samme navn som gjør litt forskjellige ting. (Lykke til på sinnssykehuset.)

Skal man derimot ha flere webapplikasjoner, er det ønskelig at man beskyttes litt mot navneforurensing. Alle fortolker-instansene deles jo mellom alle webapplikasjoner som kjøres. Derfor utfører mod_ruby koden som skal kjøres for en dynamisk generert webside innpakket i en anonym modul.

Følgende kode fungerer derfor ikke:

  1| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
  2| <html>
  3|   <head><title> ikke-fungerende rot 13 </title></head>
  4|   <body>
  5| <% 
  6| class String  # Dette lager en ny String-klasse i  
  7|   def rot13   # stedet for å utvide den eksisterende.
  8|     self.tr( "A-Za-z", "N-ZA-Mn-za-m" )
  9|   end
 10| end
 11| require 'cgi'
 12| c = CGI.new
 13| inntekst = c['inntekst']
 14| if inntekst then
 15|   uttekst = inntekst.to_s.rot13  # Fungerer ikke.
 16| end    
 17| %>
 18|   <b><%=inntekst%></b> rot 13 kryptert blir <b><%=uttekst%></b>.
 19|   <form><input type="text" name="inntekst">
 20|         <input type="submit" value="rot13"></form> 
 21|  </body>
 22| </html>

Ruby er selvsagt dynamisk nok til å komme seg rundt slike stengsler...

  1| # Med litt stygg eval- og klassemagi går det derimot greit.
  2| String.class_eval {
  3|   def rot13
  4|     self.tr( "A-Za-z", "N-ZA-Mn-za-m" )
  5|   end        
  6| }

...men dette vil påvirke alle prosesser som noensinne kjører skriptet, og den forrige ikke-fungerende versjonen vil enten feile eller fungere alt etter hvilken tilstand prosessen som blir valgt ut til å håndtere forespørselen er i.

Next Previous Contents