Perché Rails esegue la configurazione nel codice?

Otteniamo un'immagine diversa quando leggiamo la pagina intera a cui sei collegato, e non solo il titolo.

program for the general case, and put the specifics somewhere else - outside the compiled code base.

Non abbiamo una base di codice compilata , il mio Ruby è interpretato . Non c'è alcun passo di ricompilazione, cambiare la configurazione è facile come cambiare il file sorgente e riavviare il programma.

There are several benefits to this approach:

• It forces you to decouple your design, which results in a more flexible and adaptable program.

Il framework RoR è già sufficientemente disaccoppiato.

• It forces you to create a more robust, abstract design by deferring details—deferring them all the way out of the program.

Parti dell'implementazione possono anche essere dettagli che dovrebbero essere rinviati dal programma principale. Nei linguaggi dinamici, semplicemente non c'è questa grande dicotomia tra codice e dati: il codice è solo un altro tipo di dati. Questo è stato dimostrato con grande successo dalle lingue Lisp e Ruby si distingue saldamente in questa tradizione Lispish attraverso il suo patrimonio Smalltalk.

• You can customize the application without recompiling it. You can also use this level of customization to provide easy work-arounds for critical bugs in live production systems.

Ancora una volta, nessuna ricompilazione è necessaria con Ruby (o altri linguaggi dinamici come Python o Perl). In effetti, possiamo eseguire il patch delle scimmie sul nuovo codice nel sistema mentre è ancora in esecuzione.

• Metadata can be expressed in a manner that's much closer to the problem domain than a general-purpose programming language might be (see Domain Languages).

La sintassi di Ruby è abbastanza flessibile da semplificare la metà di un DSL. In effetti, l'implementazione di Ruby ci fornisce un parser e un compilatore gratis, tutto ciò che dobbiamo fare è implementare la semantica.

• You may even be able to implement several different projects using the same application engine, but with different metadata.

Esattamente. Il framework RoR prende il codice specifico dell'applicazione dai tuoi file di configurazione. È facile scambiare questi file con un altro sito web.

In Rails quei confini sono sempre stati un po 'sfocati. Ci sono diversi motivi per questo, il primo forse il semplice fatto che il linguaggio Ruby gli permette di scrivere codice che assomiglia a configurazioni. Ad esempio, puoi usare i metodi senza inserire gli argomenti tra parentesi, il che porta all'uso comune di cose come questa:

has_many :orders

nelle definizioni del modello. Sembra una configurazione, in realtà è una chiamata al metodo con param: orders.

A partire da questo punto è spesso più facile concatenare le richieste di metodo per opzioni di configurazione complesse. Questo specialmente in file come routes.rb . Anche questo consente configurazioni molto dinamiche (diciamo che vuoi usare espressioni regolari nel tuo routing). Inoltre, il routing può essere in generale una cosa molto più dinamica, quindi avere codice che viene eseguito è spesso più praticabile.

In realtà in molti posti quei file .rb non generano configurazioni "statiche", ma spostano le funzioni anonime sul posto che vengono successivamente chiamate, ad esempio quando un percorso deve essere valutato.

Nel caso dei file di base come environment.rb e application.rb è un po 'fuorviante chiamarli file di configurazione. Sono più una sorta di punti di ancoraggio in cui è possibile aggiungere require chiamate da eseguire mentre il sistema Rails sta eseguendo il bootstrap della sua gerarchia di classi.

Quindi c'è un mix di ragioni attive qui, alcune semplicemente basate sulla 'cultura Ruby', altre per scopi pratici. (Non tutti sono necessariamente la decisione migliore, ma il più delle volte hanno senso una volta che vedi le possibilità avanzate che ottieni da loro).

Le configurazioni eseguibili sono un compromesso tra espressibilità e sicurezza / prevedibilità.

L'uso di un linguaggio di programmazione completo per la configurazione offre molte funzionalità utili "gratuite": le variabili consentono di evitare di scrivere sempre lo stesso valore, i cicli evitano di ripetersi, se le istruzioni eseguono condizionali, ecc.

Lo svantaggio di usare una configurazione eseguibile o un generatore di configurazione è che non si può sapere cosa farà la configurazione senza eseguirla. Eseguirà rapidamente o rimarrà bloccato in un ciclo infinito? Quali proprietà imposterà alla fine? Ci sono anche problemi di sicurezza se si dispone di configurazioni create dall'utente: come si esegue la sandbox in ambiente executino? Possono DDOS consumando troppi resoutrces e così via ...