Development

Documentation/id_ID/book/1.0/05-Configuring-Symfony

You must first sign up to be able to contribute.

Bab 5 - Mengkonfigurasi Symfony

Agar simpel dan mudah digunakan, symfony menentukan beberapa konvensi-konvensi, yang sudah memenuhi kebanyakan pesryaratan-pesyaratan umum dari standar aplikasi tanpa perlu modifikasi. Bagaimana pun, penggunaan kumpulan file-file konfigurasi yang simpel dan bertenaga, yang memungkinkan mengkustomisasi hampir keseluruhan cara framework dan aplikasi anda berinteraksi satu dengan lainnya. Dengan file-file ini, anda juga dapat menambahkan parameter-parameter khusus aplikasi-aplikasi anda.

Bab ini menjelaskan bagaimana sistem konfigurasi bekerja:

  • Konfigurasi symfony tersimpan dalam file yang ditulis dengan YAML, meskipun anda selalu bisa memilih format lain.
  • File-file konfigurasi berada pada tingkat proyek, aplikasi, dan modul dalam sebuah struktur direktori proyek.
  • Anda dapat menentukan beberapa kumpulan setting konfigurasi; dalam symfony, sekumpulan konfigurasi disebut lingkungan (environment).
  • Nilai-nilai yang didefinisikan dalam file-file konfigurasi tersedia bagi kode PHP dalam aplikasi anda.
  • Sebagai tambahan, symfony membuat kode PHP dari file-file YAML dan menyediakan trik-trik lain untuk membuat sistem konfigurasi bahkan lebih fleksibel.

Sistem Konfigurasi

Tidak bergantung tujuan, kebanyakan aplikasi-aplikasi web berbagi pakai sekumpulan karakteristik umum. Sebagai contoh, beberapa bagian-bagian dapat dilarang untuk segolongan pengguna, atau halaman-halaman dapat didekorasi dengan layout, atau sebuah form dapat diisi dengan masukkan pengguna setelah kegagalan validasi. Sebuah framework menentukan sebuah struktur untuk mengemulsikan karakteristik-karakteristik ini, dan pengembang dapat lebih men-tweak-nya dengan pengubahan setting konfigurasi. Strategi ini menghemat banyak waktu untuk pengembangan, semenjak banyak perubahan-perubahan tidak membutuhkan satu baris kode pun, bahkan jika terdapat banyak kode dibelakangnya. Hal ini juga lebih efisien, karena dipastikan informasi dapat dikelola dalam satu file tunggal dan lokasinya mudah diidentifikasi.

Akan tetapi, pendekatan ini memiliki dua kekurangan serius:

  • Pengembang berakhir dengan menulis file-file XML kompleks yang tak berakhir.
  • Dalam arsitektur PHP, setiap request membutuhkan waktu lebih lama untuk diproses.

Untuk menanggulangi kerugian-kerugian ini, symfony menggunakan file-file konfigurasi hanya untuk keperluan terbaik. Sebagai fakta, ambisi dari sistem konfigurasi symfony adalah:

  • Bertenaga: Hampir setiap aspek yang diapat dikelola menggunakan file-file konfigurasi menggunakan file-file konfigurasi.
  • Sederhana: Banyak aspek dari konfigurasi yang tidak ditunjukkan dalam aplikasi normal, semenjak mereka jarang sekali diubah.
  • Mudah: File-file konfigurasi mudah dibaca, dimodifikasi, dan dibuat oleh pengembang.
  • Dapat dikustomisasi: Bahasa konfigurasi default konfigurasi adalah YAML, tatapi bisa INI, XML, atau format apapun yang lebih disukai pengembang.
  • Cepat: File-file konfigurasi tidak pernah diproses oleh aplikasi tetapi oleh sistem konfigurasi, yang meng-kompilasi mereka dalam potongan kode yang cepat diproses oleh server PHP.

Sintaks YAML dan Konvensi-Konvensi Symfony

Sebagai konfigurasinya, symfony menggunakan YAML sebagai format default, daripada INI yang lebih tradisional atau format XML. YAML menunjukkan struktur melalui identasi dan cukup cepat ditulis. Keuntungannya dan aturan-aturan dasar sudah dijabarkan pada Bab 1. Akan tetapi, anda perlu mengingat beberapa konvensi-konvensi dalam menulis file-file YAML. Bagian ini memperkenalkan beberapa dari konvensi-konvensi tersebut yang populer. Untuk desertasi lengkap tentang topik ini, kunjungi website YAML (http://www.yaml.org/).

Pertama, jangan pernah menggunakan tab dalam file-file YAML; melainkan gunakan spasi. Pengolah YAML tidak mengenali file-file dengan tab, jadi identasi baris menggunakan spasi (spasi ganda adalah konvensi symfony untuk identasi), seperti ditunjukkan pada Listing 5-1.

Listing 5-1 - File-file YAML Melarang Menggunakan Tab

# Jangan pernah menggunakan tab
all:
-> mail:
-> -> webmaster:  webmaster@example.com

# Melainkan gunakan spasi
all:
  mail:
    webmaster: webmaster@example.com

Jika parameter-paramter anda diawali atau diakhiri dengan spasi, kutip nilai tersebut menggunakan kutip tunggal. Jika parameter string berisi karakter-karakter spesial, juga kutip nilai tersebut dengan kutip tunggal, seperti ditunjukkan pada Listing 5-2.

Listing 5-2 - String-String Nonstandar harus Dikutip dengan Kutip Tunggal

error1: This field is compulsory
error2: '  This field is compulsory  '
error3: 'Don''t leave this field blank'   # Kutip tunggal harus didobel

Anda dapat menentukan string panjang dalam beberapa baris, dan juga string-string banyak baris, dengan header string khusus (> and |) plus penambahan sebuah identasi. Listing 5-3 mendemonstrasikan konvensi ini.

Listing 5-3 - Menentukan String-String Panjang dan Banyak Baris

# Gaya Folded, dikenali dengan >
# Setiap pindah baris digabung dengan sebuah spasi
# Membuat YAML lebih mudah dibaca
accomplishment: >
  Mark set a major league
  home run record in 1998.

# Gaya Literal, dikenali dengan |
# Semua pindah baris disertakan apa adanya
# Indentasi tidak tampak pada string yang dihasilkan
stats: |
  65 Home Runs
  0.278 Batting Average

Untuk membuat nilai sebagai sebuah array, masukkan elemen-elemen dalam kurung siku atau gunakan sintaks terkembang dengan tanda strip, seperti ditunjukkan pada Listing 5-4.

Listing 5-4 - Sintaks Array YAML

# Sintaks pendek untuk array-array
players: [ Mark McGwire, Sammy Sosa, Ken Griffey ]

# Sintaks terkembang untuk array-array
players:
  - Mark McGwire
  - Sammy Sosa
  - Ken Griffey

Untuk membuat nilai sebagai array asosiatif, atau hash, masukkan elemen-elemen dalam kurung kurawal dan selalu sisipkan spasi di antara kunci dan nilai dalam pasangan key: value. Anda juga dapat menggunakan sintaks terkembang dengan menambahkan identasi dan sebuah carriage return untuk setiap kunci baru, seperti ditunjukkan pada Listing 5-5.

Listing 5-5 - Sintaks Array Asositaif YAML

# Sintaks salah, tidak ada spasi setelah tanda titik dua
mail: {webmaster:webmaster@example.com,contact:contact@example.com}

# Sintaks pendek yang benar untuk array asosiatif
mail: { webmaster: webmaster@example.com, contact: contact@example.com }

# Sintaks terkembang untuk array asosiatif
mail:
  webmaster: webmaster@example.com
  contact:   contact@example.com

Untuk memberikan nilai Boolean, gunakan baik on, 1, atau true untuk nilai positif dan off, 0, atau false untuk nilai negatif. Listing 5-6 menunjukkan nilia-nilai Boolean yang mungkin.

Listing 5-6 - Sintaks Nilai-Nilai Boolean YAML

true_values:   [ on, 1, true ]
false_values:  [ off, 0, false ]

Jangan ragu untuk menambahkan komentar (dimulai dengan tanda hash, #) dan tambahan spasi pada nilai-nilai untuk membuat file-file YAML lebih mudah dibaca, seperti ditunjukkan pada Listing 5-7.

Listing 5-7 - Sintaks Komentar YAML dan Penataan Nilai

# Ini adalah baris komentar
mail:
  webmaster: webmaster@example.com
  contact:   contact@example.com
  admin:     admin@example.com   # spasi extra membuat penataan nilai lebih manis

Dalam beberapa file-file konfigurasi symfony, anda terkadang-kadang akan melihat baris yang diawali dengan tanda hash (dan, sehingga, diabaikan oleh pengolah YAML) namun kelihatan seperti baris setting umumnya. Ini adallah konvensi symfony: konfigurasi default, yang diwariskan dari file-file YAML lain yang terletak pada inti symfony, diulang sebagai baris-baris komentar dalam konfigurasi aplikasi, sebagi informasi bagi anda. Jika anda ingin mnegubah nilai dari parameter-parameter tertentu, anda perlu menghilangkan komentar baris sebelumnya, seperti ditunjukkan pada Listing 5-8.

Listing 5-8 - Konfigurasi Default Ditunjukkan Dengan Komentar

# The cache is off by default
settings:
# cache: off

# Jika anda ingin mengubah setting ini, sebelumnya hilangkan tanda komentar
settings:
  cache: on

Symfony kadang-kadang mengelompokkan definisi-definisi parameter ke dalam kategori-kategori. Semua setting dalam kategori tersebut nampak teridentasi di bawah header kategori. Strukturisasi daftar panjang dari pasangan key: value dengan mengelompokkan mereka ke dalam kategori-kategori membuat konfigurasi menjadi mudah dibaca. Header kategori dimulai dengan tanda titik (.). Listing 5-9 menunjukkan sebuah contoh dari kategori-kategori.

Listing 5-9 - Header Kategori Nampak Sebagai Kunci-Kunci, Tetapi Diawali dengan Titik

all:
  .general:
    tax:        19.6

  mail:
    webmaster:  webmaster@example.com

Pada contoh ini, mail adalah kunci dan general hanyalah sebuah header kategori saja. Semuanya bekerja layaknya jika header kategori tidak ada, seperti ditunjukkan pada Listing 5-10. Parameter tax sebenarnya adalah anak langsung dari kunci all. Tetapi penggunaan kategori-kategori membantu symfony berhubungan dengan array-array yang berada di bawah kunci all.

Listing 5-10 - Header Kategori Disediakan untuk Kemudahan Pembacaan dan Sebenarnya Diabaikan

all:
  tax:          19.6

  mail:
    webmaster:  webmaster@example.com

SIDEBAR Dan jika anda tidak menyukai YAML

YAML hanyalah antarmuka untuk menentukan setting yang digunakan oleh kode PHP, jadi konfigurasi yang ditentukan dalam file-file YAML akhirnya ditranformasikan menjadi PHP. Setelah menelusuri aplikasi, periksa cache konfigurasi (pada cache/myapp/dev/config/, sebagai contoh). Anda akan melihat file-file PHP terkait dengan konfigurasi YAML anda. Anda akan belajar banyak mengenai cache konfigurasi selanjutnya pada bab ini.

Berita baiknya adalah jika anda tidak ingin menggunakan file-file YAML, anda masih dapat melakukan apa yang bisa dikerjakan oleh file-file konfigurasi oleh diri anda sendiri, dalam PHP atau via format lain (XML, INI, dll). Melalui buku ini, anda akan menemui cara alternatif untuk menentukan konfigurasi tanpa YAML, dan anda bahkan akan belajar mengganti handler konfigurasi symfony (pada Bab 19). Jika anda menggunakannya secara bijak, trik-trik ini akan memungkinkan anda untuk melewati file-file konfigurasi atau menentukan format konfigurasi anda sendiri.

Tolong, File YAML Membunuh Aplikasi Saya!

File-file YAML diolah menjadi hash PHP dan array-array, dan kemudian nilai-nilai tersebut digunakan dalam bermacam-macam bagian aplikasi untuk memodifikasi tingkah laku view, controller, atau model. Berulang kali, ketika ada permasalahan pada file YAML, yang tidak terdeteksi hingga nilai yang sebenarnya dibutuhkan. Lebih-lebih, kesalahan atau eksepsi yang dikeluarkan kemudian tidak jelas terkait dengan file konfigurasi YAML.

Jika aplikasi anda tiba-tiba berhenti bekerja setelah mengubah konfigurasi, coba periksa anda tidak melakukan kesalahan-kesalahan umum bagi coder YAML yang kurang teliti:

  • Anda tidak menempatkan spasi antara kunci dan nilainya:

    key1:value1      # Spasi hilang setelah :
    
  • Kunci-kunci dalam urutannya tidak teridentasi dengan cara yang sama:

    all:
      key1:  value1
       key2: value2  # Identasi tidak sama dengan anggota urutan lainnya
      key3:  value3
    
  • Ada karakter YAML yang direservasi untuk kunci atau nilai, tanpa adanya pemisah string:

    message: tell him: go way    # :, [, ], { dan } direservasi dalam YAML
    message: 'tell him: go way'  # Sintaks yang betul
    
  • Anda memodifikasi baris yang dikomentar:

    # key: value     # Tidak akan pernah diproses karena adanya # diawal
    
  • Anda memberikan nilai dua kali untuk kunci yang sama pada tingkat yang sama:

    key1: value1
    key2: value2
    key1: value3     # key1 didefinisikan dua kali, nilai yang terakhir yang dipakai
    
  • Anda mengira nilai memiliki tipe spesial, sementara nilai tersebut selalu berupa string, hingga anda mengkonversinya:

    income: 12,345   # Hingga anda mengkonversinya, ini masih sebuah string
    

Selayang Pandang File-File Konfigurasi

Konfigurasi didistribusikan dalam file-file, oleh subyek. File-file berisi definisi-definisi parameter, atau setting-setting. Beberapa dari parameter-parameter ini dapat diambil-alih pada beberapa tingkatan (proyek, aplikasi, dan modul); beberapa khusus untuk tingkatan tertentu. Bab selanjutnya akan berhubungan dengan file-file konfigurasi yang berkaitan dengan topik utamanya, dan Bab 19 akan berhubungan dengan konfigurasi lanjutan.

Konfigurasi Proyek

Ada beberapa file-file konfigurasi proyek default. Berikut adalah file-file yang dapat ditemukan pada direktori myproject/config/:

  • config.php: Ini adalah file yang pertama kali dieksekusi oleh sembarang request atau perintah. Berisi path ke lokasi file-file framework, dan anda dapat mengubahnya untuk menggunakan instalasi yang berbeda. Jika anda menambahkan beberapa statement define pada akhir file ini, konstanta-konstanta tersebut akan dapat diakses oleh semua aplikasi dalam proyek. Lihat Bab 19 untuk penggunaan lanjut file ini.
  • databases.yml: File ini dimana anda menentukan akses dan setting koneksi ke database (host, login, password, nama database, dll). Bab 8 akan menjelaskan lebih tentang ini. File ini juga dapat diambil-alih pada tingkatan aplikasi.
  • properties.ini: File ini menyimpan beberapa parameter-parameter yang digunakan oleh tool baris perintah, termasuk nama proyek dan setting koneksi untuk server-server jauh. Lihat Bab 16 untuk selayang pandang fitur-fitur penggunaan file ini.
  • rsync_exclude.txt: File ini menentukan direktori-direktori mana saja yang tidak disertakan sewaktu sinkronisasi antara server-server. Pembahsannya ada pada Bab 16.
  • schema.yml dan propel.ini: File-file konfigurasi tersebut digunakan oleh Propel (lapisan ORM symfony). Mereka digunakan oleh librari Propel untuk bekerja sama dengan kelas-kelas symfony dan data proyek anda. schema.yml berisi representasi model data relasional proyek. propel.ini otomatis diciptakan, jadi anda mungkin tidak perlu memodifikasinya. Jika anda tidak menggunakan Propel, file-file ini tidak diperlukan. Baba 8 akan membicarakannya lebih jauth tentang penggunaannya.

File-file ini kebanyakan digunakan oleh komponen-komponen eksternal atau oleh baris perintah, atau mereka perlu diproses bahkan sebelum ada program pengolah YAML yang dimuat oleh framework. Itulah mengapa beberapa dari mereka tidak menggunakan format YAML.

Konfigurasi Aplikasi

Bagian utama dari konfigurasi adalah konfigurasi aplikasi. Konfigurasi tersebut didefiniskan dalam front controller (dalam direktori web/) untuk konstanta-konstanta utama, dalam file-file YAML yang terletak pada direktori config/ aplikasi, dalam direktori i18n/ untuk file-file internasionalisasi, dan dalam file-file framework yang tak nampak--meskipun berguna--konfigurasi aplikasi tambahan.

Konfigurasi Front Controller

Konfigurasi aplikasi yang pertama kali sebenarnya ditemukan pada front controller; yaitu skrip yang pertama kali dieksekusi sewaktu request. Lihat web/index.php default pada Listing 5-11.

Listing 5-11 - Front Controller Produksi Default

[php]
<?php

define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
define('SF_APP',         'myapp');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG',       false);

require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

sfContext::getInstance()->getController()->dispatch();

Setelah mendefinisikan nama aplikasi (myapp) dan lingkungan (prod), file konfigurasi umum dipanggil sebelum pengiriman request. Jadi beberapa konstanta-konstanta yang berguna didefinisikan di sini:

  • SF_ROOT_DIR: Direktori root proyek (normalnya, seharusnya tetap seperti nilai default, terkecuali anda mengubah struktur file).
  • SF_APP: Nama aplikasi dalam proyek. Dibutuhkan untuk kompilasi path-path file.
  • SF_ENVIRONMENT: Nama lingkungan (prod, dev, atau lingkungan khusus-proyek lainnya yang dapat anda tentukan). Akan menentukan setting konfigurasi mana yang akan digunakan. Lingkungan-lingkungan akan diterangkan selanjutnya pada bab ini.
  • SF_DEBUG: Aktivasi modus debug (lihat Bab 16 untuk detailnya).

Jika anda ingin mengubah nilai-nilai ini, anda mungkin membutuhkkan front controller tambahan. Bab berikutnya akan membicarakan lebih jauh tentang front controller dan bagaimana untuk membuat satu yang baru.

SIDEBAR Direktori root dapat di manapun

Hanya file-file dan skrip-skrip yang terlatak di bawah direktori root web (direktori web/ pada proyek symfony) tersedia dari luar. Skrip front controller, gambar-gambar, stylesheet, dan file-file JavaScript adalah umum. Semua file lainnya harus diluar root web server--yang berarti mereka dapat berada di manapun.

File-file non publik diakses oleh front controller dari path SF_ROOT_DIR. Klasiknya, direktori root satu tingkat di atas direktori web/. Tetapi anda dapat memilih struktur yang sama sekali berbeda. Bayangkan jika struktur direktori utama terbuat dari dua direktori, satu public dan satu privat:

symfony/    # Area privat
  apps/
  batch/
  cache/
  ...
www/        # Area publik
  images/
  css/
  js/
  index.php

Dalam kasus ini, direktori root adalah direktori symfony/. Jadi front controller index.php hanya butuh mendefiniskan SF_ROOT_DIR seperti berikut agar aplikasi bekerja:

define('SF_ROOT_DIR', dirname(__FILE__).'/../symfony');

Bab 19 akan memberikan informasi lebih mengenai bagaimana men-tweak symfony untuk membuatnya bekerja dengan struktur direktori khusus.

Konfigurasi Utama Aplikasi

Konfigurasi utama aplikasi disimpan pada file-file yang terletak pada direktori myproject/apps/myapp/config/:

  • app.yml: File ini hanya berisi konfigurasi khusus-aplikasi; yaitu, variabel-variabel global yang menentukan logika bisnis atau aplikasi khusu untuk aplikasi, yang tidak perlu disimpan dalam database. Rate pajak, biaya pengapalan, dan alamat-alamat e-mail sering disimpan pada file ini. File ini defaultnya kosong.
  • config.php: File ini mem-bootstrap aplikasi, yang berarti file ini mengerjakan semua inisialiasasi dasar untuk membuat aplikasi berjalan. Di sini anda dapat mengkustomisasi struktur direktori anda atau menambahkan konstanta-konstanta khusus-aplikasi (Bab 19 menyediakan detailnya). File ini memuali dengan menyertakan config.php proyek.
  • factories.yml: Symfony mendefinisikan kelas-kelasnya sendiri untuk menangani view, request, respon, sesi, dll. Jika anda ingin menggunakan kelas anda sendiri, di sini anda dapat menentukannya. Bab 17 menyediakan informasi lebih.
  • filters.yml: Filter-filter adalah porsi-porsi kode yang dieksekusi untuk setiap request. File ini di mana anda dapat menentukan filter-filter mana saja yang diproses, dan file ini dapat diambil-alih oleh tiap-tiap modul. Bab 6 mendiskusikan filter-filter dengan lebih detail.
  • logging.yml: File ini menentukan tingkatan detail yang harus direkam dalam file-file log, untuk membantu anda mengelola dan men-debug aplikasi anda. Penggunaan konfigurasi ini dijelaskan pada Bab 16.
  • routing.yml: Aturan-aturan routing, yang memperbolehkan transformasi URL yang sulit dibaca dan tidak dapat di-bookmark menjadi URL "pintar" dan eksplisit, tersimpan dalam file ini. Pada aplikasi-aplikasi baru, beberapa aturan-atruan default sudah tersedia. Bab 9 berisi tentang link dan routing.
  • settings.yml: Setting-setting utama aplikasi symfony ditentukan dalam file ini. Di sini anda menentukan jika aplikasi anda menggunakan internasionalisasi, bahasa default, waktu timeout request dan apakah cache diaktifkan. Dengan pengubahan satu baris dalam file ini, anda dapat mematikan aplikasi jadi anda dapat melaksanakan maintenan atau meng-upgrade salah satu komponen-komponennya. Setting-setting umum dan penggunaannya dijelaskan pada Bab 19.
  • view.yml: Struktur view default (nama layout, title, dan tag-tag meta; stylesheet default dan file-file JavaScript yang harus disertakan; tipe isi default, dll) ditentukan dalam file ini. File ini juga mendefinisikan nilai default tag-tag meta dan title. Bab 7 akan membicarakan file ini lebih banyak. Setting-setting ini dapat diambil-alih untuk masing-masing modul.

Konfigurasi Internasionaliasasi

Aplikasi dengan internasionalisasi dapat menampilkan halaman dalam beberapa bahasa. Hal ini membutuhkan konfigurasi khusus. Ada dua tempat konfigurasi untuk internasionaliasasi:

  • i18n.yml dalam direktori config/ aplikasi: File ini menentukan setting-setting umum translasi, semisal kultur default untuk translasi, apakah translasi menggunakan file-file atau database, dan formatnya.
  • File-file translasi pada direktori i18n/ aplikasi: Pada dasarnya berupa kamus-kamus, berisi translasi untuk masing-masing frase yang digunakan oleh template aplikasi sehingga halaman-halaman tersebut menampilkan translasi teks ketika pengguna berpindah bahasa.

Perlu dicatat pengatkifan fitur i18n ditentukan dalam file settings.yml. Anda akan menemukan informasi lebih banyak mengenai fitur-fitur ini pada Bab 13.

Konfigurasi Tambahan Aplikasi

Kumpulan file-file konfigurasi yang kedua berada pada dirketori instalasi symfony (dalam $sf_symfony_ data_dir/config/) dan tidak nampak dalam direktori konfigurasi aplikasi-aplikasi anda. Setting-setting didefinisikan di sana adalah nilai default dan jarang perlu dimodifikasi, atau global untuk seluruh proyek. Akan tetapi, jika anda perlu memodifikasinya, buat file kosong dengan nama yang sama pada direktori myproject/apps/myapp/config/, dan ambil-alih setting-setting yang ingin anda ubah. Setting-setting yang ditentukan dalam aplikasi selalu memiliki hak yang lebih tinggi daripada setting-setting yang ditentukan pada framework. Berikut adalah file-file konfigurasi pada direktori config/ pada instalasi symfony:

  • autoload.yml: File ini berisi setting-setting untuk fitur autoloading. Fitur ini membebaskan anda dari menyertakan kelas-kelas kustom dalam kode jika mereka diletakkan pada direktori-direktori khusus. Hal ini dijelaskan lebih detail pada Bab 19.
  • constants.php: File ini berisi struktur file aplikasi default. Untuk mengambil-alih setting-setting dalam file ini, gunakan config.php aplikasi, seperti dijelaskan pada Bab 19.
  • core_compile.yml dan bootstrap_compile.yml: File-file ini mendaftar kelas-kelas yang harus disertakan untuk menjalankan sebuah aplikasi (pada bootstrap_compile.yml) dan memroses request (pada core_compile.yml). Kelas-kelas ini sebenarnya adalah gabungan-gabungan file PHP yang dioptimasi tanpa komentar-komentar, yang akan mempercepat eksekusi dan operasi akses file (satu file dimuat daripada lebih dari empat puluh untuk setiap request). Ini khususnya berguna jika anda tidak menggunakan accelerator PHP. Teknik-teknik optimasi dijelaskan pada Bab 18.
  • config_handlers.yml: Di sini anda dapat menambahkan atau memodifikasi handler-handler yang digunakan untuk memroses masing-masing file konfigurasi. Bab 19 menyediakan lebih banyak detailnya.
  • php.yml: File ini memeriksa jika variabel-variabel dalam file php.ini sudah didefinisikan secara tepat dan memperbolehkan anda mengambil-alihnya, jika dibutuhkan. Periksa Bab 19 untuk detailnya.

Konfigurasi Modul

Secara default, sebuah modul tidak memiliki konfigurasi khusus. Tetapi, jika dibutuhkan, anda dapat mengambil-alih setting-setting tingkat aplikasi untuk modul yang diberikan. Sebagai contoh, anda mungkin melakukannya untuk mengubah deskripsi HTML dari semua action-action dalam modul, atau untuk menyertakan file JavaScript khusus. Anda juga dapat memilih untuk menambahkan parameter-parameter baru yang dikhususkan untuk modul tertentu untuk menjamin enkasulapsi.

Seperti yang anda perkirakan, file-file konfigurasi modul harus diletakkan pada direktori myproject/apps/myapp/modules/mymodule/config/. File-file tersebut sebagaimana berikut:

  • generator.yml: Untuk modul-modul yang diciptakan sesuai tabel database (scaffolding dan administration), file ini menentukan bagaimana antarmuka menampilkan baris dan field-field, dan interaksi-interaksi yang mana saja yang diberikan kepada pengguna (filter-filter, pengurutan, tombol-tombol, dll). Bab 14 akan membicarakan masalah ini lebih lanjut.
  • module.yml: File ini berisi parameter-parameter kustom yang khusus untuk sebuah modul (ekuivalen dengan app.yml, tetapi pada tingkatan modul) dan konfigurasi action. Bab 6 menyediakan lebih banyak detailnya.
  • security.yml: File ini menentukan pembatasan akses pada action-action. Di sini anda menentukan apakah halaman dapat dilihat hanya oleh pengguna terdaftar atau oleh segolongan pengguna terdaftar dengan permisi khusus. Bab 6 akan membicarakan lebih banyak tentang ini.
  • view.yml: File ini berisi konfigurasi untuk view pada satu atau seluruh action dalam modul. Konfigurasi ini mengambil-alih view.yml aplikasi dan dijelaskan pada Bab 7.
  • File-file data validasi: Meskipun terletak pada direktori validate/ bukan pada config/, file-file data validasi YAML, digunakan untuk mengatur data ayng dimasukkan dalam form-form, juga merupakan file-file konfigurasi modul. Anda akan belajar bagaimana menggunakannya pada Bab 10.

Kebanyakan file-file konfigurasi modul menawarkan kemampuan untuk menentukan parameter-parameter untuk semua view-view atau semua action-action dalam modul, atau sebagian dari mereka.

SIDEBAR Terlalu banyak file-file?

Anda boleh jadi diliputi oleh banyaknya file-file konfigurasi yang ada pada aplikasi. Tetapi, cam-kan berikut ini dalam pikiran anda:

Dari kebanyakan waktu, anda tidak perlu mengubah konfigurasi, semenjak konvensi-konvensi default cocok dengan kebanyakan pesyaratan-persyaratan umum. Setiap file konfigurasi berkaitan dengan fitur tertentu, dan bab selanjutnya akan merinci penggunaanya satu demi satu. Ketika anda fokus pada satu file, anda dapat melihat jelas apa yang dikerjakannya dan bagaimana dia diatur. Untuk pengembangan web profesional, konfigurasi default sering tidak diadaptasi seluruhnya. File-file konfigurasi membuat kemudahan modifikasi mekanisme symfony tanpa kode. Bayangkan jumlah kode PHP yang dibutuhkan untuk memperoleh hasil kontrol yang sama. Jika semua konfigurasi diletakkan pada satu file, bukan hanya membuat file sulit dibaca, tetapi anda tidak dapat menentukan ulang konfigurasi pada beberapa tingkatan (lihat bagian "Susuan Konfigurasi" selanjutnya pada bab ini).

Sistem konfigurasi adalah salah satu kekuatan terbesar symfony, karena sistem tersebut membuat symfony dapat digunakan hampir pada semua jenis aplikasi web, dan bukan hanya pada aplikasi dimana aslinya framework ini dirancang.

Lingkungan-Lingkungan

Selama waktu pengembangan aplikasi, anda akan mungkin perlu menetapkan beberapa kumpulan konfigurasi secara paralel. Sebagai contoh, anda akan perlu memiliki setting-setting koneksi untuk database pengujian tersedia selama pengembangan, dan satu lagi untuk data sesungguhnya yang tersedia untuk produksi. Untuk memenuhi kebutuhan konfigurasi-konfigurasi yang bersamaan, symfony menawarkan lingkungan-lingkungan yang berbeda.

Apakah Lingkungan Itu?

Sebuah aplikasi dapat dijalankan dalam lingkungan-lingkungan yang bervariasi. Lingkungan-lingkungan yang berbeda berbagi pakai kode PHP yang sama (berbeda dari front controller), tetapi dapat memliki konfigurasi-konfigurasi yang sama sekali berbeda. Untuk setiap aplikasi, symfony menyediakan tiga lingkungan-lingkungan default: produksi (prod), pengujian (test), dan pengembangan (dev). Anda juga bebas menambahkan sebanyak mungkin lingkungan-lingkungan kustom yang anda inginkan.

Jadi pada dasarnya, lingkungan-lingkungan dan konfigurasi adalah sinonim. Sebagai contoh, lingkungan pengujian akan membukukan kesalahan-kesalahandan peringatan-peringatan, sementara lingkungan prod hanya akan membukukan kesalahan-kesalahan. Akselerasi cache juga sering dinonaktifkan pada lingkungan dev, tetapi diaktifkan pada lingkungan-lingkungan test dan prod. Lingkungan-lingkungan dev dan test mungkin membutuhkan data pengujian, tersimpan dalam database yang berbeda dengan yang digunakan pada lingkungan produksi. Jadi konfigurasi database akan berbeda dari dua lingkungan tersebut. Semua lingkungan-lingkungan dapat hidup bersama dalam satu mesin, meskipun server produksi umumnya hanya berisi lingkungan prod.

Dalam lingkungan dev, setting-setting logging dan debugging diaktifkan, semenjak maintenan lebih penting daripada peforma. Konstrasnya, lingkungan prod memiliki setting-setting optimal secara default, sehingga konfigurasi produksi mematikan banyak fitur-fitur. Sebuah aturan yang bagus yaitu untuk menavigasi dalam lingkungan pengembangan hingga anda puas dengan fitur-fitur yang anda kerjakan, dan kemudian berpindah ke lingkungan produksi unntuk memeriksa kecepatannya.

Lingkungan pengujian berbeda dari lingkungan dev dan prod dalam beberapa cara. Anda berinteraksi dengan lingkungan ini satu-satunya melalui baris perintah dengan tujuan untuk pengujian fungsional dan skrip batch. Konsekuensinya, lingkungan pengujian ini cukup dekat dengan lingkungan produksi, tetapi tidak diakses melalui sebuah browser web. Lingkungan ini men-simulasikan penggunaan cokie-cookie dan komponen-komponen HTTP khusus lainnya.

Untuk mengubah lingkungan dimana anda menelusuri aplikasi anda, cukup ubah front controller. Hingga sekarang, anda hanya melihat hanya lingkungan pengembangan, semenjak URL-URL yang digunakan pada contoh dipanggil dengan front controller pengembangan:

http://localhost/myapp_dev.php/mymodule/index

Akan tetapi, jika anda ingin melihat bagaimana aplikasi bereaksi pada produksi, panggil front controller produksi:

http://localhost/index.php/mymodule/index

Jika server web memiliki mod_rewrite diaktifkan, anda bahkan dapat menggunakan aturan-aturan rewriting symfony kustom, ditulis pada web/.htaccess. Mereka menentukan front controller produksi sebagai skrip default yang dieksekusi dan memperbolehkan URL-URL seperti ini:

http://localhost/mymodule/index

SIDEBAR Lingkungan-lingkungan dan server-server

Jangan campurkan antara lingkungan dan server. Dalam symfony, lingkungan-lingkungan yang berbeda menggunakan konfigurasi berbeda, dan berhubungan dengan front controller (skrip yang mengeksekusi request). Server-server yang berbeda berhubungan dengan nama-nama domain yang berbeda pada URL.

http://localhost/myapp_dev.php/mymodule/index
       _________ _____________
        server    lingkungan

Biasanya, pengembang-pengembang bekerja dengan aplikasi-aplikasi pada server pengembangan, terputus dari Internet dan dimana semua konfigurasi server dan PHP dapat diubah sesuai keinginan. Ketika datang waktu untuk merilis aplikasi produksi, file-file aplikasi ditransfer ke server produksi dan dibuat dapat diakses oleh pengguna.

Ini berarti banyak lingkungan-lingkungan tersedia bagi masing-masing server. Sebagai contoh, anda dapat menjalankan lingkungan produksi bahkan pada server pengembangan. Akan tetapi, dari kebanyakan waktu, hanya lingkungan produksi saja seharusnya yang bisa diakses pada server produksi, untuk menghindari konfigurasi server terlihat oleh publik dan resiko-resiko keamanan.

Unutk menambah lingkungan baru, anda tidak perlu membuat direktori atau menggunakan CLI symfony. Cukup buat front controller baru dan ubah definisi nama lingkungan di dalamnya. Lingkungan ini mewarisi semua konfigurasi default plus setting-setting yang berlaku umum untuk semua lingkungan-lingkungan. Bab selanjutnya akan menunjukkan bagaimana untuk melakukannya.

Susunan Konfigurasi

Setting yang sama dapat ditentukan lebih dari sekali, pada tempat yang berbeda. Sebagai contoh, anda mungkin menginginkan untuk mengatur mime-type sekumpulan halaman-halaman menjadi text/html untuk semua aplikasi, kecuali halam-halam dari modul rss, yang membutuhkan mime-type text/xml. Symfony memberikan kemampuan untuk setting pertama pada myapp/config/view.yml dan yang kedua pada myapp/modules/rss/config/view.yml. Sistem konfigurasi mengetahui bahwa setting yang ditentukan pada tingkat modul harus mengambil-alih setting yang didefinisikan pada tingkat aplikasi.

Sebagai fakta, ada beberapa tingkatan-tingkatan konfigurasi pada symfony:

  • Tingkatan granular:
    • Konfigurasi default yanf terletak dalam framework
    • Konfigurasi global untuk keseluruhan proyek (pada myproject/config/)
    • Konfigurasi lokal untuk sebuah aplikasi dari proyek (pada myproject/apps/myapp/config/)
    • Konfigurasi lokal dikhususkan untuk modul (pada myproject/apps/myapp/modules/mymodule/config/)
  • Tingkatan-tingkatan lingkungan:
    • Spesifik untuk satu lingkungan
    • Untuk semua lingkungan-lingkungan

Dari semua properti-propeti yang dapat dikustomisasi, kebanyakan tidak tergantung lingkungan. Konsekuensinya, banyak file-file konfigurasi YAML dipisahkan menurut lingkungan, plus sebuah seksi buntut untuk semua lingkungan-lingkungan. Hasilnya adalah konfigurasi tipikal terlihat seperti 5-12.

Listing 5-12 - Struktur File-File Konfigurasi Symfony

# Setting-setting lingkungan produksi
prod:
  ...

# Setting-setting lingkungan pengembangan
dev:
  ...

# Setting-setting lingkungan pengujian
test:
  ...

# Setting-setting lingkungan kustom
myenv:
  ...

# Setting-setting untuk semua lingkungan-lingkungan
all:
  ...

Sebagai tambahan, framework sendiri mendefinisikan nilai-nilai default pada file-file yang tidak diletakkan pada struktur tree proyek, tetapi pada direktori $sf_symfony_data_dir/config/ dari instalasi symfony. Konfigurasi default adalah sekumpulan file-file tersebut seperti ditunjukkan pada Listing 5-13. Setting-setting ini diwarisi oleh semua aplikasi-aplikasi.

Listing 5-13 - Konfigurasi Default, pada $sf_symfony_data_dir/config/settings.yml

 # Default settings:
 default:
   default_module:         default
   default_action:         index
   ...

Definisi default ini diulang pada proyek, aplikasi, dan file-file konfigurasi modul sebagai komentar, seperti ditunjukkan pada Listing 5-14, jadi anda mengetahui beberapa parameter-parameter yang didefinisikan secara default dan mereka dapat dimodifikasi.

Listing 5-14 - Konfigurasi Default, Diulang sebagai Informasi, pada myapp/config/settings.yml

#all:
 #  default_module:         default
 #  default_action:         index
 ...

Ini berarti bahwa sebuah properti dapat didefinisikan beberapa kali, dan nilai aktual yang dihasilkan berasal dari sebuah definisi susunan. Sebuah definisi parameter dalam sebuah yang dinamakan sesuai lingkungan mendahului definisi parameter yang sama untuk semua lingkungan-lingkungan, yang mendahului sebuah definisi pada konfigurasi default. Sebuah definisi parameter pada tingkat modul mendahului definisi parameter yang sama pada tingkat aplikasi, yang mendahului sebuah definisi pada tingkat proyek. Ini dapat digambarkan dengan daftar prioritas berikut:

  1. Modul
  2. Aplikasi
  3. Proyek
  4. Lingkungan spesifik
  5. Semua lingkungan-lingkungan
  6. Default

Cache Konfigurasi

Pengolahan YAML dan bekerja dengan susunan konfigurasi pada runtime memerlukan cukup beban lebih yang signifikan untuk setiap request. Symfony memiliki mekanisme cache konfigurasi built-in yang didesain untuk mempercepat request-request.

File-file konfigurasi, apapun formatnya, diproses oleh beberapa kelas-kelas spesial, dinamakan handler, yang merubahnya ke dalam kode PHP yang cepat-diproses. Dalam lingkungan pengembangan, handler memeriksa konfigurasi untuk perubahan-perubahan pada tiap-tiap request, untuk menjamin interaktivitas. Mereka mengolah file-file yang barusan dimodifikasi sehingga anda dapat melihat perubahan pada sebuah file YAML seketika. Tetapi pada lingkungan produksi, pemrosesan terjadi sekali sewaktu request yang pertama, dan kemudian kode PHP yang diproses disimpan pada cache untuk request-request berikutnya. Peforma dijamin, semenjak setiap request pada produksi hanya akan mengeksekusi kode PHP yang dioptimasi dengan baik.

Sebagai contoh, jika file app.yml berisi seperti ini:

all:                   # Setting untuk semua lingkungan
  mail:
    webmaster:         webmaster@example.com

maka file config_app.yml.php, terletak pada folder cache/ dalam proyek anda, akan berisi ini:

[php]
<?php

sfConfig::add(array(
  'app_mail_webmaster' => 'webmaster@example.com',
));

Sebagai konsekuensi, kebanyakan waktu, file-file YAML bahkan tidak diolah oleh framework, melainkan tergantung pada cache konfigurasi. Akan tetapi, pada lingkungan pengembangan, symfony akan membandingkan secara sistematika tanggal modifikasi dari file-file YAML dan file-file cache, dan diproses ulang hanya jika salah satunya berubah semenjak request sebelumnya.

Hal ini menghadirkan keuntungan besar diatas banyak framework-framework PHP, dimana file-file konfigurasi dikompilasi pada setiap request, bahkan pada produksi. Tidak seperti Java, PHP tidak berbagi pakai sebuah konteks eksekusi di antara request-request. Pada framework-framework PHP lainnya, penggunaan fleksibilitas dari file-file konfigurasi XML membutuhkan penurunan peforma yang besar untuk memroses semua konfigurasi pada setiap request. Hal ini tidak berlaku pada symfony. Terima kasih pada sistem cache, beban lebih dikarenakan konfigurasi sangat rendah.

Ada konsekuensi penting dari mekanisme ini. Jika anda mengubah konfigurasi pada lingkungan produksi, anda perlu untuk memaksa pengolahan ulang dari semua file-file konfigurasi agar modifikasi anda dapat diterapkan. Untuk itu, anda hanya perlu untuk membersihkan cache, baik dengan menghapus isi direktori cache/ atau, lebih mudahnya, dengan memanggil tugas clear-cache symfony:

> symfony clear-cache

Mengakses Konfigurasi dalam Kode

Semua file-file konfigurasi secepatnya ditransformasi menjadi PHP, dan banyak dari setting-setting di dalamnya otomatis digunakan oleh framework, tanpa intervensi lebih lanjut. Akan tetapi, anda kadang-kadang perlu mengakses beberapa setting-setting yang ditentukan pada file-file konfigurasi tersebut dari kode anda (pada action-action, template-template, kelas-kelas kustom, dll). Setting-setting yang didefinisikan pada settings.yml, app.yml, module.yml, logging.yml, dan i18n.yml tersedia melalui kelas khusus yang disebut sfConfig.

Kelas sfConfig

Anda dapat mengakses setting-setting dari dalam kode aplikasi melalui kelas sfConfig. Kelas ini adalah registri bagi parameter-parameter konfigurasi, dengan metode getter kelas yang simpel, dapat diakses dari setiap bagian kode:

[php]
// Menggambil sebuah setting
parameter = sfConfig::get('param_name', $default_value);

Perlu dicatat bahwa anda juga dapat menentukan, atau mengambil-alih, sebuah setting dari dalam kode PHP:

[php]
// Menentukan sebuah setting
sfConfig::set('param_name', $value);

Nama parameter adalah gabungan beberapa elemen-elemen, dipisahkan oleh garis bawah, dengan aturan:

  • Sebuah awalan berkaitan dengan nama file konfigurasi (sf_ untuk settings.yml, app_ untuk app.yml, mod_ untuk module.yml, sf_i18n_ untuk i18n.yml, dan sf_logging_ untuk logging.yml)
  • Kunci-kunci orang tua (jika ditentukan), dengan huruf kecil
  • Nama kunci, dengan huruf kecil

Lingkungan tidak disertakan, semenjak kode PHP hanya akan mengakses nilai-nilaiyang ditentukan untuk lingkungan di mana dia dieksekusi.

Sebagai contoh, jika nda perlu untuk mengakses nilai-nilai yang ditentukan pada file app.yml ditunjukkan pada Listing 5-15, anda akan perlu kode yang ditunjukkan pada Listing 5-16.

Listing 5-15 - Contoh Konfigurasi app.yml

all:
  .general:
    tax:          19.6
  default_user:
    name:         John Doe
  mail:
    webmaster:    webmaster@example.com
    contact:      contact@example.com
dev:
  mail:
    webmaster:    dummy@example.com
    contact:      dummy@example.com

Listing 5-16 - Mengakses Setting-Setting Konfigurasi dari PHP pada Lingkungan dev

[php]
echo sfConfig::get('app_tax');   // Ingat header kategori diabaikan
 => '19.6'
echo sfConfig::get('app_default_user_name');
 => 'John Doe'
echo sfConfig::get('app_mail_webmaster');
 => 'dummy@example.com'
echo sfConfig::get('app_mail_contact');
 => 'dummy@example.com'

Jadi setting-setting konfigurasi symfony mendapatkan semua keuntungan-keuntungan konstanta PHP, tetapi tanpa kekurangan-kekurangannya, semenjak nilainya dapat diubah.

Pada akun, file settings.yml, dimana anda dapat menentukan setting-setting framework untuk aplikasi, ekuivalen dengan daftar sekumpulan panggilan sfConfig::set(). Listing 5-17 diinterpretasikan sebagaimana ditunjukkan pada Listing 5-18.

Listing 5-17 - Potongan settings.yml

all:
  .settings:
    available:              on
    path_info_array:        SERVER
    path_info_key:          PATH_INFO
    url_format:             PATH

Listing 5-18 - Apa yang Dilakukan Simfony Ketika Mengolah settings.yml

[php]
sfConfig::add(array(
  'sf_available' => true,
  'sf_path_info_array' => 'SERVER',
  'sf_path_info_key' => 'PATH_INFO',
  'sf_url_format' => 'PATH',
));

Rujuk ke Bab 19 untuk pengartian setting-setting yang ditemukan pada file settings.yml.

Setting-Setting Aplikasi Kustom dan app.yml

Kebanyakan setting-setting berkaitan dengan fitur-fitur sebuah aplikasi yang seharusnya disimpan pada file app.yml, terletak pada direktori myproject/apps/myapp/config/. File ini tak tergantung lingkungan dan defaultnya kosong. Letakkan setiap setting yang anda inginkan untuk mudah diubah, dan gunakan kelas sfConfig untuk mengakses setting-setting ini dari kode anda. Listing 5-19 menunjukkan sebuah contoh.

Listing 5-19 - Contoh app.yml untuk Menetukan Operator Kartu Kredit yang Diterima pada Site Yang Diberikan

all:
  creditcards:
    fake:             off
    visa:             on
    americanexpress:  on

dev:
  creditcards:
    fake:             on

Untuk mengetahui jika kartu kredit fake diterima pada lingkungan sekarang, dapatkan nilainya dengan:

[php]
sfConfig::get('app_creditcards_fake');

CATATAN Ketika anda membutuhkan array PHP langsung di bawah kunci all anda perlu menggunakan sebuah header kategori, jika tidak symfony akan membuat nilai-nilai tersedia berbeda-beda seperti ditunjukkan di atas.

all:
  .array:
    creditcards:
      fake:             off
      visa:             on
      americanexpress:  on

[php]
print_r(sfConfig::get('app_creditcards'));

Array(
  [fake] => false
  [visa] => true
  [americanexpress] => true
)

TIP Setiap waktu anda dihadapkan untuk menentukan sebua konstanta atau sebuah setting dalam salah satu skrip-skrip anda, coba berpikir agar lebih baik diletakkan pada file app.yml. Ini adalah tempat yang meyakinkan untuk menyimpan semua setting-setting aplikasi.

Ketika kebutuhan anda akan parameter-parameter kustom menjadi sulit ditangani dengan sintaks app.yml, anda mungkin perlu mendefinisikan sintaks anda sendiri. Dalam kasus ini, anda dapat menyimpan konfigurasi pada file baru, diinterpretasikan oleh handler konfgiurasi baru. Tujuk ke Bab 19 untuk informasi lebih mengenai handler-handler konfigurasi.

Tip untuk Mendapatkan Manfaat Lebih dari File-File Konfigurasi

Ada beberapa trik-trik terakhir untuk dipelajari sebelum menulis file-file YAML anda sendiri. Mereka memperbolehkan anda untuk menghindari duplikasi konfigurasi dan untuk bekerja dengan format YAML anda sendiri.

Menggunakan Konstanta pada File-File Konfigurasi YAML

Beberapa setting-setting konfgiurasi bergantung pada nilai dari setting-setting lain. Untuk memghindari setting nilai yang sama dua kali, symfony mendukung konstanta-konstanta pada file-file YAML. Pada penentuan nama setting (yang dapat diakses dengan sfConfig::get()) dengan huruf-huruf besar dikelilingi dengan tanda %, handler konfigurasi menggantinya dengan nilainya sekarang. Lihat Listing 5-20 untuk contohnya.

Listing 5-20 - Menggunakan Konstanta-Konstanta pada File-File YAML, Contoh dari autoload.yml

autoload:
  symfony:
    name:           symfony
    path:           %SF_SYMFONY_LIB_DIR%
    recursive:      on
    exclude:        [vendor]

Parameter path akan mendapatkan nilai yang dikembalikan oleh sfConfig::get('sf_symfony_lib_dir'). Jika anda ingin satu file konfigurasi bergantung pada yang lainnya, anda perlu memastikan file yang dibutuhkan tersebut sudah diolah (lihat pada source symfony untuk mencari tahu urutan pengolahan file-file konfigurasi). app.yml adalah salah satu dari file-file yang diolah terakhir, jadi anda boleh bergantung pada konfigurasi lain pada file tersebut.

Menggunakan Skrip pada Konfigurasi

Boleh jadi konfigurasi anda tergantung pada parameter-parameter eksternal (semisal sebuah database atau file konfigurasi lain). Untuk bekerja dengan kasus tertentu ini, file-file konfigurasi symfony diolah sebelum dilewatkan ke pengolah YAML. Itu berarti bahwa anda dapat meletakkan kode PHP dalam file-file YAML, seperti pada Listing 5-21.

Listing 5-21 - File-File YAML Dapat Berisi PHP

all:
  translation:
    format:  <?php echo (sfConfig::get('sf_i18n') == true ? 'xliff' : 'none')."\n" ?>

Tetapi perlu diingat konfigurasi diolah sangat awal sekali pada alur sebuah request, jadi anda tidak akan memiliki metode-metode built-in symfony atau fungsi-fungsi untuk membantu anda.

Juga, sebagaimana konstruktor bahasa echo tidak menambahkan carriage return secara default, anda perlu menambahkan sebuah "n" atau menggunakan helper echoln untuk menjaga format YAML tetap sah.

all:
  translation:
    format:  <?php echoln sfConfig::get('sf_i18n') == true ? 'xliff' : 'none' ?>

PERHATIAN Pada lingkungan produksi, konfigurasi dicache, jadi file-file konfigurasi diolah (dan dieksekusi) sekali hanya setelah cache dibersihkan.

Menelusuri File YAML Anda Sendiri

Ketika anda ingin membaca file YAML langsung, anda dapat menggunakan kelas sfYaml. Kelas tersebut adalah pengolah YAML yang mengubah sebuah file YAML menjadi sebuah array asosiatif PHP. Listing 5-22 menghadirkan contoh sebuah file YAML, dan Listing 5-23 menunjukkan bagaimana anda mengolahnya.

Listing 5-22 - File Contoh Sample test.yml

house:
  family:
    name:     Doe
    parents:  [John, Jane]
    children: [Paul, Mark, Simone]
  address:
    number:   34
    street:   Main Street
    city:     Nowheretown
    zipcode:  12345

Listing 5-23 - Menggunakan Kelas sfYaml untuk Mengubah Sebuah File YAML Menjadi Sebuah Array Asosiatif

[php]
$test = sfYaml::load('/path/to/test.yml');
print_r($test);

Array(
  [house] => Array(
    [family] => Array(
      [name] => Doe
      [parents] => Array(
        [0] => John
        [1] => Jane
      )
      [children] => Array(
        [0] => Paul
        [1] => Mark
        [2] => Simone
      )
    )
    [address] => Array(
      [number] => 34
      [street] => Main Street
      [city] => Nowheretown
      [zipcode] => 12345
    )
  )
)

Kesimpulan

Sistem konfigurasi symfony menggunakan bahasa YAML agar sederhana dan mudah dibaca. Kemampuan bekerja dengan banyak lingkungan-lingkungan dan untuk menetukan parameter-parameter melalui susunan definisi yang menawarkan keunggulan bermacam-macam bagi pengembang. Beberapa konfigurasi dapat diakses dari dalam kode melalui obyek sfConfig, khususnya setting-setting aplikasi disimpan pada file app.yml.

Ya, symfony memiliki banyak file-file konfigurasi, tetapi pendekatan ini membuat lebih mudah diadaptasi. Ingat bahwa anda tidak perlu terganggu dengan mereka kecuali aplikasi anda membutuhkan kustomisasi tingkat tinggi.