Share
Etter mer enn et år med utvikling ble Ruby on Rails 3 offisielt utgitt for publikum for noen uker siden. Mer enn bare en iterativ oppdatering, var denne etterlengtede utgivelsen en viktig refactoring av det populære Ruby-rammeverket. Fortsett å lese for å lære fem av de mest fantastiske nye funksjonene i Ruby Rails 3.
En av mine favoritt nye Ruby on Rails 3-funksjoner er introduksjonen av Unobtrusive JavaScript (UJS) til alle sine JavaScript-hjelperfunksjoner. I tidligere versjoner av Rails ble JavaScript generert inline med HTML, noe som forårsaket stygg og litt sprø kode.
Som et eksempel lar Rails deg bruke det link_to metode å generere en slettekobling for noe objekt.
<%= link_to "Delete this Post", @post, :confirm => "Vil du virkelig slette dette innlegget?",: Method =>: delete%>
Ved å bruke denne metoden i visningen din, ville du generere følgende i Rails 2:
Slett dette innlegget
Rails 3 ville generere noe mye enklere:
Slett dette innlegget
Rails 3 erstatter alle inline JavaScript med et par HTML5 attributter. Alle JavaScript-hendelsesbehandlerne som håndterer den faktiske bekreftelsesboks og sletting, lagres i en sentral JavaScript-fil som følger med hvert skinnprosjekt.
En stor fordel for denne nye metoden er at JavaScript-hjelperne er rammebestemt agnostisk. I stedet for å være bundet til Prototype-biblioteket som du var i Rails 2, kan du nå velge hvilket JavaScript-rammeverk du liker (Rails apps leveres med Prototype som standard, men jQuery støttes nå offisielt.
En annen fantastisk ny funksjon av Rails 3 er at XSS-beskyttelse nå er aktivert som standard. Rails 2 støttet XSS beskyttelse gjennom bruk av h metode.
<%= h @comment.text %>
De h Metoden ville unnslippe HTML og JavaScript for å sikre at ingen skadelig klient-side kode ble utført. Denne metoden fungerte bra, men det var ett problem: du måtte faktisk huske å bruke h Metode overalt hvor brukeren skrev inn, ble vist. Hvis du glemte et sted, så var du sårbar for et XSS-angrep.
I Rails 3, er alle innspilt som standard, og tar byrden av utvikleren av å måtte huske å unnslippe overalt at ondsinnet kode kan være til stede. For de tider som du vil tillate at uoppdagede data vises i visningen din, kan du bruke rå metode for å fortelle Rails 3 for ikke å unnslippe dataene.
<%= raw @comment.text %>
Rails 3 inneholder en kul ny søkemotor som gjør det lettere å få tilbake dataene du vil ha, og gir deg mer fleksibilitet i kontrollerkoden. Disse endringene dukker opp på forskjellige steder, men det vanligste tilfellet er å hente data i kontrolleren din. I Rails 2 kan du bruke søkemetoden til å hente dataene du lette etter, passere i argumenter for å angi betingelser, gruppering, grenser og annen forespørselsinformasjon. For eksempel:
@posts = Post.find (: all,: conditions => ["kategori IN (?)", kategorier],: limit => 10,: order => "created_on DESC")
finner de ti første innleggene innenfor noen spesifiserte kategorier bestilt av opprettelsestidspunktet.
I Rails 3 har hver av de bestått i parametre sin egen metode, som kan kjedes sammen for å få de samme resultatene.
Accentsconagua
@posts = Post.where (["kategori IN (?)", kategorier)). ordre ("created_on DESC") .grense (10) Spørringen blir egentlig ikke utført før dataene trengs; så disse metodene kan til og med brukes på flere måter.
@posts = Post.where (["kategori IN (?)", kategorier)) hvis (condition_a) @posts = @ posts.where (['godkjent =?', sant]) annet @posts = @ posts.where ['godkjent =?', falsk]) slutt
Dette er bare et enkelt eksempel, men skal gi deg en ide om noen av måtene denne nye syntaksen kan være mer nyttig.
ActionMailer-modulen er omskrevet for å gjøre det enklere for applikasjonen din å sende epost i Rails 3. Det er ganske mange endringer, men her er noen av mine favoritter.
I Rails er en Mailer en klasse som kan ha mange metoder, som hver for seg konfigurerer og sender en e-post. Tidligere måtte du sette alle parametrene for hver e-post hver for seg i hver metode.
klasse UserMailer < ActionMailer::Base def welcome_email(user) from "[email protected]" # other paramters end def password_reset(user) from "[email protected]" # other parameters end end
I Rails 3 kan du angi standardverdier som eventuelt kan overskrives i hver metode.
klasse UserMailer < ActionMailer::Base default :from => '[email protected]',: return_path => '[email protected]' def welcome_email (bruker) # trenger ikke å spesifisere fra parameterendets ende
Tidligere versjoner av Rails krevde at du sendte e-post ved hjelp av spesielle metoder som ble dynamisk opprettet av ActionMailer. For eksempel, hvis du ønsket å levere velkomstmeldingen i eksemplet ovenfor, må du ringe:
UserMailer.deliver_welcome_email (@user)
I Rails 3 kan du bare ringe
UserMailer.welcome_email (@user) .deliver
Dette gir mer mening semantisk, og i tillegg lar deg hente og manipulere Post objektet før du leverer e-posten.
En av styrken i Ruby on Rails-rammen er den overflod av edelstener som er tilgjengelige for utviklere. Enten det er autentisering, håndtering av finansielle transaksjoner, håndtering av filopplastinger eller nesten alt annet, er det sjansene for at en perle eksisterer for å hjelpe deg med problemet ditt.
Det kan imidlertid oppstå problemer hvis edelstenene krever andre edelstener, eller utviklere er blant annet på forskjellige miljøer. For å hjelpe til med å løse disse situasjonene, legger Rails 3 til Bundler-perlen for å hjelpe deg med å håndtere dine avhengigheter. Bruke Bundler i Rails 3 er ekstremt enkelt; legg til en linje for hver perle du trenger i Gemfile, en fil som er inkludert i roten til hver av dine applikasjoner.
perle 'authlogic'
Når du har tatt med alle edelstenene dine, kjør du:
bunt installasjon
og Bundler vil laste ned og konfigurere alle edelstenene og deres avhengighet som du trenger for prosjektet.
Bundler lar deg også spesifisere visse edelstener som bare kan konfigureres i visse miljøer (utvikling vs produksjon vs testing).
Dette er bare noen få av de mange endringene som er inkludert i Ruby on Rails 3. Mange av de gamle APIene jobber fortsatt i Rails, selv om de har blitt avskrevet for å gjøre det enklere å oppdatere. Så, hvis du er på gjerdet om hvorvidt du skal oppgradere din eksisterende railsapp, eller ikke, så gå for det!
Takk for at du leste!
