Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. PHP

Menggabungkan Laravel 4 dan Backbone

by
Difficulty:IntermediateLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by fodal fadel (you can also view the original English article)

Untuk tutorial ini, kita akan membangun satu halaman aplikasi menggunakan Laravel 4 dan Backbone.js. Kerangka kedua membuatnya sangat mudah untuk menggunakan mesin template yang berbeda selain default mereka masing-masing, jadi kita akan menggunakan kumis, yang merupakan mesin yang umum untuk kedua. Dengan menggunakan bahasa template yang sama pada kedua sisi dari aplikasi kami, kami akan dapat berbagi kami betweem pemandangan mereka, menyelamatkan kita dari keharusan untuk mengulangi pekerjaan kami beberapa kali.

Aplikasi tulang punggung kami akan didukung oleh Laravel 4 JSON API yang kita akan mengembangkan bersama-sama. Laravel 4 dilengkapi dengan beberapa fitur baru yang membuat pengembangan API ini sangat mudah. Saya akan menunjukkan Anda beberapa trik sepanjang jalan untuk memungkinkan Anda untuk tetap sedikit lebih terorganisir.

Semua dependensi kita akan dikelola oleh manajer paket, tidak akan ada manual men-download atau memperbarui perpustakaan untuk aplikasi ini! Selain itu, aku akan menunjukkan kepada Anda bagaimana memanfaatkan kekuatan tambahan kecil dari beberapa dependensi kita.

Untuk proyek ini kita akan menggunakan:

  • Laravel 4: Besar PHP framework.
  • Mustache.php: PHP mesin render untuk kumis.
  • Mustache.js: JavaScript mesin render untuk kumis.
  • Jeffrey cara Generator untuk Laravel 4: kita dapat meningkatkan alur kerja kami dengan menghasilkan beberapa kode boilerplate bagi kita menggunakan generator ini.
  • Twitter Bootstrap: Sebuah front-end perpustakaan untuk membantu dalam styling kami.
  • PHPUnit: PHP pengujian suite.
  • Ejekan: Digunakan untuk mengejek obyek PHP saat pengujian.
  • Backbone.js: MVC Javascript untuk aplikasi satu halaman kami.
  • Underscore.js: Ketergantungan tulang punggung, dan sebuah toolkit kecil besar fungsi.

Untuk menyelesaikan tutorial ini, Anda akan memerlukan item berikut diinstal:

  • Komposer: Anda dapat men-download ini dari situs, saya merekomendasikan petunjuk instalasi global terletak di sini.
  • Node + NPM: installer pada homepage akan menginstal kedua item.
  • Compiler kurang: Jika Anda pada Mac, saya merekomendasikan CodeKit. Namun, terlepas dari sistem operasi Anda, atau jika Anda tidak merasa seperti membayar untuk CodeKit, Anda dapat menginstal kompilator kurang untuk Node.js dengan mengetik npm menginstal -g kurang pada prompt perintah.

Bagian 1: Arsitektur dasar

Hal pertama yang pertama, kita perlu untuk mendapatkan setup aplikasi kita sebelum kita dapat mulai menambahkan logika bisnis kami. Kami akan melakukan setup dasar 4 Laravel dan mendapatkan semua dependensi kita diinstal menggunakan Manajer paket kami.

Git

Mari kita mulai dengan menciptakan sebuah repositori git untuk bekerja di. Untuk referensi, repo seluruh ini akan dibuat tersedia untuk umum di https://github.com/conarwelsh/nettuts-laravel4-and-backbone.

Laravel 4 instalasi

Laravel 4 menggunakan komposer untuk menginstal semua dependensi, tapi pertama kita akan membutuhkan struktur aplikasi untuk menginstal ke dalam. Cabang "mengembangkan" Laravel's Github repositori adalah rumah bagi struktur aplikasi ini. Namun, pada saat menulis artikel ini, Laravel 4 adalah masih dalam versi beta, jadi saya perlu dipersiapkan untuk struktur ini untuk mengubah setiap saat. Dengan menambahkan Laravel sebagai repositori berjarak, kita dapat menarik perubahan ini setiap kali kita perlu. Bahkan, sementara sesuatu dalam modus beta, itu adalah praktik yang baik untuk menjalankan perintah tersebut setelah setiap update komposer. Namun, Laravel 4 sekarang adalah versi terbaru, stabil.

Jadi kita memiliki struktur aplikasi, tetapi semua file perpustakaan yang Laravel tidak belum diinstal. Anda akan melihat akar dari aplikasi kita ada file bernama composer.json. Ini adalah file yang akan terus melacak jumlah semua dependensi yang memerlukan aplikasi Laravel kami. Sebelum kami memberitahu komposer men-download dan menginstal mereka, mari kita pertama kali menambahkan beberapa dependensi yang lebih banyak bahwa kita akan membutuhkan. Kami akan menambahkan:

  • Jeffrey cara Generator: beberapa perintah yang sangat berguna untuk lebih meningkatkan alur kerja kami dengan secara otomatis menghasilkan file tersembunyi: bagi kita.
  • Kumis Laravel 4: Ini akan memungkinkan kita untuk mulus menggunakan Mustache.php di proyek Laravel kami, sama seperti kita Blade.
  • Twitter Bootstrap: Kami akan menggunakan file kurang dari proyek ini untuk mempercepat pembangunan front-end kami.
  • PHPUnit: Kami akan melakukan beberapa TDD untuk API JSON kami, PHPUnit akan mesin pengujian kami.
  • Ejekan: Ejekan akan membantu kita "mengejek" objek selama pengujian kami.

PHPUnit dan olok-olok hanya diperlukan dalam lingkungan pengembangan kami, jadi kita akan menentukan bahwa dalam file composer.json kami.


Composer.JSON

Sekarang kita hanya perlu memberitahu komposer untuk melakukan semua pekerjaan kaki kami! Di bawah ini, melihat--dev beralih, kami memberitahu komposer bahwa kita berada dalam lingkungan pengembangan kami dan bahwa hal itu juga harus menginstal semua dependensi kita terdaftar dalam "memerlukan-dev".

Setelah itu selesai menginstal, kita akan perlu menginformasikan Laravel beberapa dependensi kita. Laravel menggunakan "penyedia jasa" untuk tujuan ini. Penyedia layanan ini pada dasarnya hanya mengatakan kepada Laravel bagaimana kode mereka akan berinteraksi dengan aplikasi dan untuk menjalankan prosedur setup diperlukan. Buka app/config/app.php dan menambahkan dua item berikut ke array "penyedia". Tidak semua paket memerlukan ini, hanya mereka yang akan meningkatkan atau mengubah fungsi Laravel.


App/config/App.php

Terakhir, kita hanya perlu melakukan beberapa tweak aplikasi generik untuk menyelesaikan instalasi Laravel kami. Mari kita membuka bootstrap/start.php dan memberitahu Laravel nama mesin kami sehingga dapat menentukan apa lingkungan yang dalam.


bootstrap/Start.php

Ganti "your-mesin-name" dengan apa pun yang host untuk mesin Anda. Jika Anda tidak yakin tentang apa nama mesin yang tepat, Anda dapat hanya jenis hostname pada prompt perintah (pada Mac atau Linux), mencetak apa pun merupakan nilai yang dimiliki dalam pengaturan ini.

Kami ingin pandangan kami mampu disajikan kepada klien kami dari permintaan web. Saat ini, pandangan kami disimpan di luar kami folder publik, yang berarti bahwa mereka tidak dapat diakses oleh publik. Untungnya, Laravel membuatnya sangat mudah untuk memindahkan atau menambahkan folder Lihat lainnya. Buka app/config/view.php dan mengubah jalan pengaturan untuk menunjuk ke folder publik kami. Pengaturan ini bekerja seperti pribumi PHP termasuk jalan, itu akan memeriksa di setiap folder sampai menemukan file tampilan pencocokan, sehingga merasa bebas untuk menambahkan beberapa di sini:


App/config/View.php

Selanjutnya Anda akan perlu untuk mengkonfigurasi database Anda. Buka app/config/database.php dan menambahkan dalam pengaturan database Anda.

Catatan: Dianjurkan untuk menggunakan 127.0.0.1 bukan localhost. Anda mendapatkan sedikit dorongan kinerja pada kebanyakan sistem, dan dengan beberapa konfigurasi sistem, localhost akan tidak bahkan terhubung dengan benar.

Akhirnya, Anda hanya perlu memastikan bahwa folder penyimpanan dapat ditulisi.

Laravel sekarang terinstal, dengan semua dependensi, serta dependensi kita sendiri. Sekarang mari kita setup instalasi tulang punggung kami!

Seperti composer.json kami dipasang semua dependensi sisi server kami, kami akan membuat package.json di folder publik kami untuk menginstal semua dependensi sisi klien kami.

Untuk dependensi sisi klien kami, kami akan menggunakan:

  • Underscore.js: Ini adalah ketergantungan dari Backbone.js, dan toolbelt berguna fungsi.
  • Backbone.js: Ini adalah MVC sisi klien kami bahwa kami akan menggunakan untuk membangun keluar aplikasi kita.
  • Mustache.js: Versi Javascript Perpustakaan template kami, dengan menggunakan bahasa template yang sama baik pada klien dan server, kita dapat berbagi dilihat, sebagai lawan dari duplikasi logika.

Public/Package.JSON

Sekarang hanya beralih ke dalam folder publik, dan menjalankan instalasi npm. Setelah itu selesai, memungkinkan beralih kembali ke akar aplikasi kami sehingga kita siap untuk sisa dari kami perintah.

Manajer paket menyelamatkan kita dari satu ton kerja, jika Anda ingin memperbarui salah satu perpustakaan ini, Semua harus Anda lakukan adalah menjalankan npm update atau update komposer. Juga, jika Anda ingin mengunci salah satu perpustakaan tersebut dalam versi tertentu, Semua harus Anda lakukan adalah menentukan nomor versi, dan manajer paket akan menangani sisanya.

Untuk menyelesaikan proses setup kami kita hanya akan menambahkan dalam semua proyek dasar file dan folder yang akan kita butuhkan, dan kemudian mengujinya untuk memastikan hal itu semua bekerja seperti yang diharapkan.

Kita harus menambahkan folder berikut:

  • masyarakat views
  • Umum/views/layouts
  • Umum/js
  • Umum/css

Dan file-file berikut:

  • Public/CSS/Styles.Less
  • Public/JS/App.js
  • Public/views/App.mustache

Untuk mencapai hal ini, kita dapat menggunakan satu-kapal:

Twitter Bootstrap juga memiliki dua dependensi JavaScript yang akan kita butuhkan, jadi mari kita hanya menyalin mereka dari folder Penjual ke folder publik kami. Mereka adalah:

  • html5shiv.js: memungkinkan kita untuk menggunakan unsur-unsur HTML5 tanpa takut browser lama yang tidak mendukung mereka
  • bootstrap.min.js: mendukung JavaScript perpustakaan untuk Twitter Bootstrap

Untuk file tata letak kami, Twitter Bootstrap juga menyediakan kami dengan beberapa template bagus starter untuk bekerja dengan, jadi mari kita menyalin satu ke folder layout kami untuk kepala mulai:

Perhatikan bahwa saya menggunakan ekstensi pisau di sini, ini bisa sama seperti mudah template kumis, tapi aku ingin menunjukkan kepada Anda betapa mudahnya untuk mencampur mesin template. Karena letak kami akan diberikan pada beban halaman, dan tidak perlu kembali diberikan oleh klien, kami aman untuk menggunakan PHP di sini secara eksklusif. Jika karena alasan tertentu Anda menemukan diri Anda perlu untuk membuat file ini pada sisi klien, Anda akan ingin untuk beralih file ini menggunakan mesin template kumis sebaliknya.

Sekarang bahwa kita memiliki semua file dasar kami di tempat, mari kita menambahkan beberapa konten starter yang bisa kita gunakan untuk menguji bahwa semuanya bekerja seperti yang kita harapkan. Aku menyediakan Anda dengan beberapa Rintisan bertopik dasar untuk Anda mulai.


Public/CSS/Styles.Less

Kami hanya akan mengimpor kericau Bootstrap file dari direktori vendor dibandingkan dengan menyalin mereka. Hal ini memungkinkan kita untuk update Twitter Bootstrap dengan apa-apa kecuali sebuah update komposer.

Kita mendeklarasikan variabel kami pada akhir file, kompilator kurang akan mengetahui nilai semua variabel yang sebelum melakukan penguraian yang kurang ke dalam CSS. Ini berarti bahwa dengan mendefinisikan ulang variabel Twitter Bootstrap pada akhir file, nilai akan benar-benar berubah untuk semua file yang disertakan, yang mengijinkan kita melakukan menimpa sederhana tanpa memodifikasi file inti Twitter Bootstrap.


Public/JS/App.js

Sekarang kita akan bungkus semua kode kami segera-menerapkan--fungsi anonim yang melewati beberapa objek global. Kami akan kemudian alias objek-objek ini global untuk sesuatu yang lebih berguna bagi kami. Juga, kita akan cache beberapa jQuery objek dalam fungsi siap dokumen.


Public/views/layouts/Application.Blade.php

Berikutnya adalah hanya sebuah sederhana tata letak file HTML. Kami namun menggunakan penolong aset dari Laravel untuk membantu kami dalam membuat jalan untuk aset kami. Ini adalah praktik yang baik untuk menggunakan jenis pembantu, karena jika Anda pernah terjadi untuk memindahkan proyek Anda ke sub-folder, semua link akan masih bekerja.

Kita memastikan bahwa kita termasuk semua dependensi kita dalam file ini, dan juga menambahkan ketergantungan jQuery. Aku memilih untuk meminta jQuery dari Google CDN, karena kemungkinan pengguna mengunjungi situs ini sudah akan memiliki salinan dari CDN yang di-cache dalam browser mereka, menyelamatkan kita dari keharusan untuk menyelesaikan permintaan HTTP untuk itu.

Satu hal penting yang perlu diperhatikan di sini adalah cara di mana kita Apakah bersarang pandangan kami. Kumis tidak memiliki blok bagian seperti pisau melakukannya, sebaliknya, isi dari tampilan bersarang akan dibuat tersedia di bawah sebuah variabel dengan nama bagian. Aku akan menunjuk ini keluar kapan kami memberikan pandangan ini dari rute kami.


Public/views/App.mustache

Berikutnya adalah hanya pandangan sederhana yang kita akan sarang menjadi layout kami.


App/Routes.php

Laravel harus sudah menyediakan Anda dengan rute standar, semua yang kita lakukan di sini adalah mengubah nama tampilan yang rute yang akan membuat.

Ingat dari atas, saya katakan bahwa pandangan bersarang akan menjadi tersedia di bawah variabel bernama apa pun adalah bagian orangtua? Nah, ketika Anda sarang pandangan, parameter pertama ke fungsi adalah nama bagian:

Dalam perintah sarang kita kita dipanggil bagian "konten", yang berarti jika kami echo $content dari tata letak kami, kami akan mendapatkan isi diberikan pandangan itu. Jika kita ingin kembali View::make('layouts.application')-> sarang ('foobar', 'apl'); maka kita lihat bersarang akan tersedia di bawah sebuah variabel yang bernama $foobar.

Dengan semua file kita dasar di tempat, kita dapat menguji untuk memastikan semuanya berjalan OK. Laravel 4 memanfaatkan baru PHP web server untuk menyediakan kami dengan sebuah lingkungan pengembangan kecil yang besar. Begitu lama untuk hari-hari memiliki pengaturan virtual host juta pada mesin pengembangan Anda untuk setiap proyek yang Anda bekerja pada!

Catatan: Pastikan bahwa Anda telah menyusun file Anda kurang pertama!

Jika Anda mengikuti dengan benar, Anda harus tertawa histeris di mengerikan saya rasa humor, dan semua aset kami harus dimasukkan dengan benar ke halaman.


Bagian 2: Laravel 4 JSON API

Sekarang kita akan membangun API yang akan kekuatan aplikasi tulang punggung kami. Laravel 4 membuat ini proses yang mudah.

Pedoman API

Pertama mari kita pergi ke beberapa pedoman umum untuk menjaga dalam pikiran ketika kita membangun API kami:

  • Kode status: Tanggapan harus menjawab dengan kode status yang tepat, melawan godaan untuk hanya menempatkan {kesalahan: "ini adalah pesan galat"} dalam tubuh tanggapan Anda. Menggunakan protokol HTTP penuhnya!

    • 200: sukses
    • 201: sumber daya yang dibuat
    • 204: sukses, tapi tidak ada konten untuk kembali
    • 400: permintaan tidak terpenuhi kesalahan //validation
    • 401: tidak dikonfirmasi
    • 403: penolakan untuk menanggapi //wrong identitasnya, tidak memiliki izin (UN dimiliki sumber daya)
    • 404: tidak ditemukan
    • 500: kesalahan lainnya
  • Metode sumber daya: meskipun controller akan melayani berbagai sumber daya, mereka masih harus memiliki perilaku yang sangat mirip. Lebih diprediksi API Anda adalah, semakin mudah untuk menerapkan dan mengadopsi.

    • Indeks: kembali koleksi sumber.
    • Tampilkan: kembali sumber daya tunggal.
    • membuat: kembalikan formulir. Formulir ini harus detail kolom yang harus diisi, validasi, dan label sebaik mungkin. Serta hal lainnya yang dibutuhkan untuk benar menciptakan sumber daya. Meskipun ini adalah JSON API, hal ini sangat berguna untuk mengembalikan sebuah formulir di sini. Komputer dan seseorang dapat mengurai melalui formulir ini, dan sangat mudah memecahkan item yang diperlukan untuk mengisi successsfully formulir ini. Ini adalah cara yang sangat mudah untuk "dokumen" kebutuhan Anda API.
    • Toko: toko baru sumber daya dan kembali dengan kode status tepat: 201.
    • mengedit: kembalikan formulir diisi dengan keadaan saat ini sumber daya. Formulir ini harus detail kolom yang harus diisi, validasi, dan label sebaik mungkin. Serta hal lainnya yang dibutuhkan untuk benar mengedit sumber daya.
    • Update: Update sumber daya yang ada dan kembali dengan kode status yang tepat.
    • Hapus: menghapus sumber daya yang ada dan kembali dengan kode status tepat: 204.

Routing & versi

API dirancang untuk menjadi sekitar untuk sementara. Hal ini tidak seperti situs web di mana Anda hanya dapat mengubah fungsionalitas di drop dari sepeser pun. Jika Anda memiliki program yang menggunakan API Anda, mereka tidak akan bahagia dengan Anda jika Anda mengubah hal-hal di sekitar dan istirahat program mereka. Untuk alasan ini, sangat penting bahwa Anda menggunakan versi.

Kami selalu dapat membuat "versi dua" dengan tambahan, atau berubah fungsi, dan memungkinkan program kami subscribing untuk opt-in untuk perubahan ini, daripada dipaksakan.

Laravel menyediakan kami dengan kelompok-kelompok rute yang sempurna untuk tempat ini, kode berikut di atas rute pertama kami:

Menghasilkan sumber daya

Kita akan menggunakan generator Jeffrey cara untuk menghasilkan sumber daya kami. Ketika kita menghasilkan sumber daya, itu akan membuat item berikut untuk kami:

  • Controller
  • Model
  • Pemandangan (index.blade.php, show.blade.php, create.blade.php, edit.blade.php)
  • Migrasi
  • Benih

Kami hanya akan membutuhkan dua sumber daya untuk aplikasi ini: sumber daya pos dan sumber daya komentar.

Catatan: di update terbaru Generator, saya telah menerima izin kesalahan karena server web saya cara setup. Untuk memperbaiki masalah ini, Anda harus membiarkan hak akses menulis ke folder yang Generator menulis temp file.

Jalankan perintah menghasilkan: sumber daya

Anda sekarang harus berhenti sejenak untuk menyelidiki semua file yang generator menciptakan bagi kita.

Menyesuaikan sumber daya yang dihasilkan

Perintah menghasilkan: sumber daya menyelamatkan kita banyak pekerjaan, tetapi karena kami konfigurasi yang unik, kita masih akan perlu membuat beberapa modifikasi.

Pertama-tama generator ditempatkan pandangan itu diciptakan di folder app dilihat, jadi kita perlu memindahkan mereka ke folder umum dilihat


App/Routes.php

Kami memutuskan bahwa kami ingin API kami menjadi berversi, jadi kita perlu memindahkan rute yang generator menciptakan kita ke dalam kelompok versi. Kita akan juga ingin namespace controller kami dengan versi yang sesuai, sehingga kita dapat memiliki set yang berbeda untuk setiap versi yang kita membangun. Juga sumber komentar perlu bersarang di bawah sumber posting.

Karena kita ber-namespace controller kami, kami harus memindahkan mereka ke dalam folder mereka sendiri untuk organisasi, mari kita membuat folder bernama V1 dan memindahkan controller kami dihasilkan ke dalamnya. Juga, karena kami bersarang kami controller komentar di bawah posting controller, mari kita mengubah nama dari controller yang mencerminkan hubungan.

Kita akan perlu untuk memperbarui file controller untuk mencerminkan perubahan kami juga. Pertama-tama kita perlu namespace mereka, dan karena mereka ber-namespace, setiap kelas di luar namespace yang akan perlu untuk diimpor secara manual dengan menggunakan pernyataan.

app/controllers/PostsController.php

app/controllers/PostsCommentsController.php

Kita juga perlu untuk memperbarui CommentsController kami dengan nama baru kami: PostsCommentsController

Menambahkan dalam repositori

Secara default, repositori bukan merupakan bagian dari Laravel. Laravel ini sangat fleksibel meskipun, dan membuatnya sangat mudah untuk menambahkan mereka. Kita akan menggunakan repositori untuk membantu kita memisahkan logika kami untuk kembali kode kegunaan, serta untuk pengujian. Untuk sekarang kita akan hanya mendapatkan setup untuk menggunakan repositori, kami akan menambahkan pada logika tepat kemudian.

Mari kita membuat folder untuk menyimpan repositori kami di:

Untuk membiarkan kami auto-loader tahu tentang folder baru ini, kita perlu untuk menambahkannya ke file composer.json kami. Lihatlah bagian diperbarui "autoload" file kami, dan Anda akan melihat bahwa kita ditambahkan dalam folder repositori.

Composer.JSON

Penyemaian Database kami

Benih database adalah alat yang berguna, mereka memberikan kami dengan cara yang mudah untuk mengisi database kami dengan beberapa konten. Generator memberikan kita dengan dasar file untuk pembibitan, kita hanya perlu menambahkan beberapa biji yang sebenarnya.

app/database/seeds/PostsTableSeeder.php

app/database/seeds/CommentsTableSeeder.php

Jangan lupa untuk menjalankan komposer dump-autoload untuk membiarkan komposer auto loader tahu tentang file migrasi baru!

Sekarang kita dapat menjalankan migrasi dan benih kami database. Laravel menyediakan kami dengan satu perintah untuk melakukan keduanya:

Tes

Pengujian adalah salah satu topik tersebut dalam pengembangan yang tidak ada yang bisa berdebat pentingnya, namun kebanyakan orang cenderung untuk mengabaikan hal itu karena kurva belajar. Pengujian benar-benar tidak sulit dan dapat secara dramatis meningkatkan aplikasi Anda. Untuk tutorial ini, kita akan setup beberapa tes dasar untuk membantu kami memastikan bahwa API kami berfungsi dengan baik. Kita akan membangun gaya API TDD ini. Aturan TDD menyatakan bahwa kita tidak diperbolehkan untuk menulis kode produksi sampai kita telah gagal tes yang menjamin itu. Namun, jika saya untuk memandu Anda melalui setiap tes secara individual, ini akan membuktikan untuk menjadi sebuah tutorial yang sangat panjang, sehingga kepentingan keringkasannya, aku hanya akan menyediakan Anda dengan beberapa tes untuk bekerja dari, dan kemudian kode yang benar untuk membuat mereka tes lulus sesudahnya.

Sebelum kita menulis tes apapun meskipun, kita harus terlebih dahulu memeriksa status pengujian saat ini aplikasi kita. Karena kita diinstal PHPUnit melalui komposer, kami memiliki binari tersedia bagi kita untuk menggunakan. Semua yang perlu Anda lakukan adalah menjalankan:

Whoops! Kita sudah memiliki kegagalan! Ujian yang gagal adalah benar-benar sebuah contoh tes yang datang pra-instal di struktur aplikasi Laravel kami, tes ini terhadap route default yang juga diinstal dengan struktur aplikasi Laravel. Karena kami diubah rute ini, kita tidak bisa terkejut bahwa tes gagal. Kita bisa Namun, hanya menghapus tes ini sama sekali karena tidak berlaku untuk aplikasi kita.

Jika Anda menjalankan perintah PHPUnit lagi, Anda akan melihat bahwa tidak ada tes dieksekusi, dan kami memiliki yang bersih untuk pengujian.

Catatan: mungkin bahwa jika Anda memiliki versi dari Jeffrey cara generator yang Anda benar-benar akan memiliki beberapa tes di sana yang diciptakan oleh orang Generator, dan tes tersebut mungkin gagal. Hanya menghapus atau menimpa tes itu dengan yang ditemukan di bawah ini untuk melanjutkan.

Untuk tutorial ini kita akan menguji controller kami dan kami repositori. Mari kita membuat beberapa folder untuk menyimpan tes ini di:

Sekarang untuk test file. Kita akan menggunakan ejekan untuk mengejek kami repositori untuk pengujian controller kami. Objek olok-olok lakukan seperti namanya mereka, mereka "mengejek" objek dan melaporkan kembali kepada kami pada bagaimana objek-objek yang berinteraksi dengan.

Dalam kasus tes controller, kita tidak benar-benar ingin repositori untuk dipanggil, setelah semua, ini adalah tes controller, tidak tes repositori. Jadi ejekan akan mengatur kita objek untuk menggunakan bukan repositori kami, dan biarkan kami tahu apakah objek tersebut dipanggil sebagai kami mengharapkan mereka.

Untuk tarik ini, kita akan memiliki untuk memberitahu controller menggunakan benda kami "diejek" bukan hal yang nyata. Kami hanya akan memberitahu aplikasi kita untuk menggunakan contoh yang diejek waktu berikutnya kelas tertentu yang diminta. Perintah seperti ini:

Proses mengejek secara keseluruhan akan pergi sesuatu seperti ini:

  • Membuat objek olok-olok baru, memberikan nama kelas yang untuk mengejek.
  • Memberitahu ejekan objek metode yang itu harus mengharapkan untuk menerima, berapa kali ini harus menerima metode, dan apa metode yang harus kembali.
  • Gunakan perintah yang ditunjukkan di atas untuk memberitahu aplikasi kita untuk menggunakan objek olok-olok baru ini bukan default.
  • Menjalankan controller metode seperti biasa.
  • Menyatakan respon.

app/tests/controllers/CommentsControllerTest.php

app/tests/controllers/PostsControllerTest.php

Selanjutnya, kita akan mengikuti prosedur yang tepat sama untuk tes PostsController


app/tests/repositories/EloquentCommentRepositoryTest.php

Sekarang untuk tes repositori. Dalam menulis tes controller kami, kami cukup banyak sudah memutuskan apa yang sebagian besar antarmuka akan terlihat seperti untuk repositori. Controller kami diperlukan metode berikut:

  • findById($id)
  • findAll()
  • instance($data)
  • Store($data)
  • Update ($id, $data)
  • Destroy($id)

Hanya metode lainnya yang kita akan ingin menambahkan di sini adalah metode validasi. Ini terutama akan menjadi metode pribadi untuk repositori untuk memastikan bahwa data aman untuk menyimpan atau update.

Tes ini, kita juga akan ditambahkan metode setUp, yang akan memungkinkan kita untuk menjalankan beberapa kode di kelas kami, sebelum pelaksanaan setiap tes. Metode setUp kami akan sangat sederhana, kami hanya memastikan bahwa setiap metode setUp yang didefinisikan di kelas induk juga disebut menggunakan parent:: setUp() dan kemudian menambahkan variabel kelas yang menyimpan instance dari repositori kami.

Kita akan menggunakan kekuatan Laravel's IoC wadah lagi untuk mendapatkan instance dari repositori kami. Perintah App::make() akan mengembalikan instance kelas diminta, sekarang tampaknya aneh bahwa kami tidak hanya melakukan $this-> repo = EloquentCommentRepository() baru, namun terus pikiran itu, kita akan kembali ke sana sejenak. Anda mungkin menyadari bahwa kami meminta untuk kelas yang disebut EloquentCommentRepository, tetapi dalam tes controller kami di atas, kita memanggil kami repositori CommentRepositoryInterface... menempatkan ini berpikir di belakang-kompor serta... explainations untuk keduanya datang, aku berjanji!

app/tests/repositories/EloquentPostRepositoryTest.php

Sekarang bahwa kita memiliki semua pengujian kami di tempat, mari kita jalankan PHPUnit lagi untuk menonton mereka gagal!

Anda harus memiliki seluruh ton kegagalan, dan pada kenyataannya, suite tes mungkin tidak bahkan tamat pengujian sebelum jatuh. Ini adalah OK, berarti kita telah mengikuti aturan TDD dan menulis gagal tes sebelum kode produksi. Meskipun, biasanya tes ini akan ditulis satu per satu waktu dan Anda tidak akan melanjutkan untuk tes berikutnya sampai Anda memiliki kode yang diperbolehkan tes sebelumnya untuk lulus. Terminal Anda mungkin harus terlihat seperti tambang saat:

Screenshot

Apa yang benar-benar gagal adalah metode assertViewHas dalam tes controller kami. Memang agak mengintimidasi untuk berurusan dengan jenis kesalahan ketika kita memiliki dikelompok bersama semua pengujian kami tanpa produksi setiap kode sama sekali. Inilah sebabnya mengapa Anda harus selalu menulis tes satu pada satu waktu, karena Anda akan menemukan kesalahan ini dengan tenang, bukan hanya kekacauan besar kesalahan sekaligus. Untuk saat ini, hanya mengikuti memimpin saya ke implementasi kode kita.


Diskusi sidebar

Sebelum kita melanjutkan dengan implementasi, mari kita istirahat untuk cepat sidebar diskusi tentang tanggung jawab dari pola MVC.

Dari geng empat:

Model adalah objek aplikasi, yang adalah presentasi layar, dan Controller mendefinisikan cara bereaksi antarmuka pengguna untuk input pengguna.

Titik menggunakan struktur seperti ini adalah untuk tetap dikemas dan fleksibel, memungkinkan kita untuk pertukaran dan penggunaan kembali komponen. Mari kita pergi melalui setiap bagian dari pola MVC dan berbicara tentang usabilitas dan fleksibilitas:

Pemandangan

Saya pikir sebagian besar orang akan setuju bahwa pandangan ini seharusnya menjadi representasi visual sederhana data dan tidak boleh mengandung banyak logika. Dalam kasus kami, sebagai pengembang untuk web, pandangan kita cenderung menjadi HTML atau XML.

  • Reusable: selalu, hampir apa pun yang dapat membuat tampilan
  • fleksibel: tidak memiliki logika apapun nyata dalam lapisan-lapisan ini membuat ini sangat fleksibel

Controller

Jika Controller "mendefinisikan cara bereaksi antarmuka pengguna untuk input pengguna", maka tanggung jawab harus mendengarkan input pengguna (Dapatkan, posting, header, dll), dan membangun keadaan saat ini aplikasi. Menurut pendapat saya, Controller harus sangat ringan dan tidak boleh mengandung kode lebih daripada yang diperlukan untuk mencapai di atas.

  • Reusable: kita harus ingat bahwa controller kami kembali pandangan dogmatis, sehingga kita tidak pernah memanggil metode Controller dalam cara yang praktis untuk menggunakan salah satu logika di dalamnya. Oleh karena itu logika apapun yang ditempatkan dalam Controller metode, harus spesifik untuk metode Controller, jika logika dapat digunakan kembali, itu harus ditempatkan di tempat lain.
  • fleksibel: dalam kebanyakan PHP MVCs Controller terkait langsung dengan rute, yang tidak meninggalkan kita fleksibilitas sangat banyak. Laravel perbaikan masalah ini dengan memungkinkan kita untuk menyatakan rute yang menggunakan controller, sehingga kita sekarang dapat swap keluar controller kami dengan implementasi yang berbeda jika perlu:

Model

Model adalah "objek aplikasi" dalam definisi kita dari Gang of Four. Ini adalah definisi yang sangat generik. Selain itu, kami hanya memutuskan untuk offload logika apapun yang dapat digunakan kembali dari Controller kami, dan karena Model adalah satu-satunya komponen yang tersisa dalam struktur didefinisikan kita, logis untuk mengasumsikan bahwa ini adalah rumah baru untuk logika. Namun, saya pikir Model tidak boleh mengandung logika apapun seperti ini. Menurut pendapat saya, kita harus berpikir tentang kami "objek aplikasi", dalam hal ini sebagai objek yang mewakili tempatnya dalam lapisan data, apakah itu sebuah tabel, baris, atau koleksi sepenuhnya tergantung pada negara. Model harus berisi tidak lebih dari Getter dan setter untuk data (termasuk hubungan).

  • Reusable: jika kita mengikuti praktek di atas dan membuat model kami menjadi sebuah obyek yang mewakili tempatnya dalam database, objek ini tetap sangat dapat digunakan kembali. Setiap bagian dari sistem kami dapat menggunakan model ini dan dengan melakukan begitu mendapatkan lengkap dan unopinionated akses ke database.
  • fleksibel: mengikuti praktek di atas, Model kami adalah pada dasarnya penerapan ORM, ini memungkinkan kita untuk menjadi fleksibel, karena kita sekarang memiliki kekuatan untuk mengubah ORM's setiap kali kita ingin hanya dengan menambahkan Model baru. Kita mungkin harus memiliki antarmuka yang ditetapkan yang Model kita harus mematuhi, seperti: semua, menemukan, membuat, memperbarui, menghapus. Pelaksanaan ORM baru akan menjadi sederhana seperti memastikan bahwa antarmuka disebutkan sebelumnya adalah lobi.

Repositori

Hanya dengan hati-hati menentukan komponen MVC kami, kami yatim semua jenis logika ke dalam tanah tak bertuan. Ini adalah di mana repositori datang untuk mengisi kekosongan. Repositori menjadi perantara controller dan model. Permintaan khas akan menjadi sesuatu seperti ini:

  • Controller menerima semua input pengguna dan menyalurkannya ke repositori.
  • Repositori melakukan tindakan "pra-mengumpulkan" seperti validasi data, otorisasi, otentikasi, dll. Jika tindakan "pra-berkumpul" ini berhasil, maka permintaan dilewatkan ke Model untuk diproses.
  • Model akan memproses semua data ke dalam lapisan data, dan kembali keadaan saat ini.
  • Repositori akan menangani apapun rutinitas "pasca-gathering" dan kembali keadaan saat ini ke controller.
  • Controller ini kemudian akan menciptakan tampilan yang tepat menggunakan informasi yang disediakan oleh repositori.

Kami repositori berakhir sebagai fleksibel dan terorganisir seperti kita telah membuat kami controller dan model, memungkinkan kita untuk menggunakan kembali ini di sebagian besar sistem kami, serta mampu untuk swap keluar untuk implementasi lain jika diperlukan.

Kita telah melihat contoh menukar repositori untuk implementasi lain dalam tes Controller di atas. Alih-alih menggunakan default kami repositori, kami meminta wadah IoC untuk menyediakan controller dengan instance objek olok-olok. Kami memiliki kekuatan yang sama ini untuk semua komponen kami.

Apa kami telah accomplised di sini dengan menambahkan lapisan lain MVC kami, adalah sistem yang sangat terorganisir, terukur dan diuji. Mari kita mulai menempatkan potongan-potongan di tempat dan mendapatkan kami tes untuk lulus.


Implementasi controller

Jika Anda mengambil membaca melalui tes controller, Anda akan melihat bahwa kita benar-benar peduli tentang adalah bagaimana controller berinteraksi dengan repositori. Jadi mari kita melihat betapa ringan dan sederhana yang membuat controller kami.

Catatan: dalam TDD, tujuannya adalah untuk tidak lagi bekerja dari yang diperlukan untuk membuat tes Anda lulus. Jadi kita ingin melakukan mutlak minimal di sini.

app/controllers/V1/PostsController.php

app/controllers/PostsCommentsController.php

Tidak bisa jauh lebih sederhana daripada itu, Semua kontroler lakukan adalah membagi input data ke repositori, mengambil respon dari itu, dan menyerahkannya ke tampilan, yang dalam kasus kita adalah hanya JSON untuk sebagian besar metode kami. Ketika kami kembali fasih koleksi, atau Model fasih controller dalam Laravel 4, objek parsing ke JSON auto-ajaib, yang membuat pekerjaan kami sangat mudah.

Catatan: Perhatikan bahwa kita menambahkan beberapa lebih "menggunakan" pernyataan ke atas dari file untuk mendukung kelas-kelas lain yang kami menggunakan. Jangan lupa ini ketika Anda bekerja dalam sebuah namespace.

Satu-satunya hal yang agak sedikit rumit dalam controller ini adalah konstruktor. Perhatikan kita melewati dalam variabel diketik sebagai ketergantungan untuk Controller ini, namun ada gunanya bahwa kita memiliki akses ke Instansiasi controller ini untuk benar-benar memasukkan bahwa kelas... Selamat datang di ketergantungan injeksi! Apa yang kita benar-benar lakukan di sini adalah mengisyaratkan kami controller yang kita memiliki ketergantungan yang diperlukan untuk menjalankan kelas ini dan apa nama kelas (atau namanya mengikat IoC). Laravel menggunakan App::make() untuk membuat controller yang sebelum memanggil mereka. App::Make() akan mencoba untuk menyelesaikan item dengan mencari setiap binding yang kita mungkin telah dinyatakan, dan/atau menggunakan auto-loader untuk memberikan contoh. Selain itu, juga akan menyelesaikan semua dependensi yang diperlukan untuk instantiate kelas bagi kita, oleh lebih-atau-kurang secara rekursif panggilan App::make() pada masing-masing dari dependensi.

Jeli, akan melihat bahwa apa yang kita coba untuk lulus dalam ketergantungan adalah antarmuka, dan seperti yang Anda tahu, antarmuka tidak dapat instantiated. Ini adalah tempat hal keren dan kami benar-benar sudah melakukan hal yang sama dalam pengujian kami. Dalam pengujian kami Namun, kami menggunakan App::instance() untuk memberikan contoh sudah dibuat bukan antarmuka. Untuk controller kami, kami benar-benar akan memberitahu Laravel bahwa setiap kali sebuah instance dari PostRepositoryInterface diminta, untuk mengembalikan instance dari EloquentPostRepository.

Buka file app/routes.php Anda dan tambahkan baris berikut ke bagian atas dari file

Setelah menambahkan baris tersebut, Kapan saja meminta App::make() untuk contoh PostRepositoryInterface, itu akan menciptakan sebuah instance dari EloquentPostRepository, yang diduga untuk menerapkan PostRepositoryInterface. Jika Anda pernah berubah repositori Anda sebaliknya menggunakan ORM berbeda daripada fasih, atau mungkin berbasis file driver, Semua harus Anda lakukan adalah mengubah dua baris dan Anda baik untuk pergi, controller Anda akan tetap bekerja seperti biasa. Ketergantungan sebenarnya controller adalah objek yang mengimplementasikan antarmuka tersebut dan kita dapat menentukan pada saat run-time apa bahwa penerapan sebenarnya adalah.

PostRepositoryInterface dan CommentRepositoryInterface yang harus benar-benar ada dan binding harus benar-benar mengimplementasikannya. Jadi mari kita membuat mereka sekarang:

app/repositories/PostRepositoryInterface.php

app/repositories/CommentRepositoryInterface.php

Sekarang bahwa kita memiliki dua antarmuka kami dibangun, kita harus menyediakan implementasi antarmuka ini. Mari kita membangun mereka sekarang.

app/repositories/EloquentPostRepository.php

Sebagai implementasi ini namanya, kami mengandalkan fasih, yang kita dapat memanggil secara langsung. Jika Anda punya dependensi lain, ingat bahwa App::make() yang digunakan untuk menyelesaikan repositori ini, sehingga Anda dapat merasa bebas untuk menggunakan metode konstruktor yang sama kami digunakan dengan controller kami untuk menyuntikkan dependensi.

app/repositories/EloquentCommentRepository.php

Jika Anda melihat di repositori kami, ada beberapa pengecualian yang kita membuang, mana tidak asli, atau apakah mereka milik Laravel. Mereka adalah pengecualian kustom yang kita gunakan untuk menyederhanakan kode kita. Dengan menggunakan pengecualian kustom, kami akan dapat dengan mudah menghentikan perkembangan aplikasi jika kondisi tertentu terpenuhi. Misalnya, jika posting tidak ditemukan, kita hanya dapat melemparkan NotFoundException dan aplikasi akan menangani hal itu sesuai, tetapi, bukan oleh menampilkan 500 error seperti biasa, sebaliknya kita akan penangan kesalahan kustom setup. Atau Anda bisa menggunakan App::abort(404) atau sesuatu di sepanjang baris tersebut, tapi saya menemukan bahwa metode ini menyelamatkan saya banyak pernyataan bersyarat dan ulangi kode, serta memungkinkan saya untuk menyesuaikan pelaksanaan kesalahan pelaporan dalam satu tempat sangat mudah.

Pertama mari kita menetapkan pengecualian kustom. Buat sebuah file dalam folder app disebut errors.php

App/Errors.php

Ini adalah pengecualian yang sangat sederhana, perhatikan untuk ValidationException, kami hanya dapat melewati itu contoh validator gagal dan ini akan menangani pesan kesalahan yang sesuai!

Sekarang kita perlu menentukan penangan kesalahan kami yang akan dipanggil ketika salah satu pengecualian ini dilemparkan. Pada dasarnya ini adalah pendengar acara, setiap kali salah satu pengecualian ini dibuang, itu dianggap sebagai suatu peristiwa dan memanggil fungsi sesuai. Hal ini sangat sederhana untuk menambahkan penebangan atau penanganan prosedur berikut kesalahan lain.

App/Filters.php

Kita sekarang perlu untuk membiarkan kami auto-loader tahu tentang file baru ini. Jadi kita harus memberitahu komposer mana untuk memeriksa mereka:

Composer.JSON

Perhatikan bahwa kita menambahkan baris "app/errors.php".

Kita sekarang harus memberitahu komposer untuk benar-benar memeriksa file ini dan memasukkan mereka dalam registri auto-beban.

Besar, begitu kami telah menyelesaikan controller kami dan kami repositori, dua item dalam MVRC kita bahwa kita harus mengurus adalah model dan pemandangan, yang keduanya cukup lurus ke depan.

app/models/Post.php

app/models/Comment.php

Sejauh menyangkut dilihat, aku hanya akan untuk menandai beberapa halaman bootstrap ramah sederhana. Ingatlah untuk mengubah setiap file ekstensi untuk .mustache meskipun, karena generator kami berpikir bahwa kami akan menggunakan. blade.php. Kami juga akan membuat beberapa pemandangan "sebagian" menggunakan konvensi Rails awalan mereka dengan _ menandakan parsial.

Catatan: saya melewatkan beberapa pemandangan, kami tidak akan menggunakan mereka dalam tutorial ini.

Public/views/Posts/index.mustache

Tampilan halaman indeks kami akan hanya loop melalui semua posting kami, menampilkan posting parsial untuk masing-masing.

Public/views/Posts/Show.mustache

Tampilkan tampilan kami akan menunjukkan seluruh posting dan komentar:

Public/views/Posts/_POST.mustache

Berikut ini adalah sebagian yang kita akan gunakan untuk menampilkan posting dalam daftar. Ini digunakan pada tampilan indeks kami.

Public/views/Posts/_form.mustache

Inilah bentuk parsial diperlukan untuk membuat posting, kita akan menggunakan ini dari API kami, tetapi ini juga bisa menjadi pandangan yang berguna dalam admin panel dan tempat lain, itulah sebabnya mengapa kita memilih untuk membuatnya parsial.

Public/views/Comments/_comment.mustache

Berikut adalah komentar parsial yang digunakan untuk mewakili satu komentar dalam daftar komentar:

Public/views/Comments/_form.mustache

Formulir yang diperlukan untuk membuat komentar - keduanya digunakan dalam API dan pemandangan Tampilkan Post:

Public/views/layouts/_notification.mustache

Dan di sini adalah pandangan penolong parsial untuk memungkinkan kita untuk menunjukkan pemberitahuan:

Besar, kita memiliki semua komponen API kami di tempat. Mari kita jalankan unit kami tes untuk melihat mana kita berada di!

Pertama menjalankan tes ini harus lulus dengan terbang warna (hijau). Namun, jika Anda adalah untuk menjalankan tes ini lagi, Anda akan melihat bahwa gagal sekarang dengan beberapa kesalahan, dan itu adalah karena kami tes repositori benar-benar diuji database, dan dengan demikian dihapus beberapa catatan pengujian kami sebelumnya digunakan untuk menegaskan nilai-nilai. Ini adalah memperbaiki yang mudah, Semua harus kita lakukan adalah memberitahu kami tes bahwa mereka perlu kembali benih database setelah setiap tes. Selain itu, kami tidak menerima kesalahan yang terlihat untuk ini, tapi kami pun tidak menutup ejekan setelah setiap tes yang baik, ini merupakan syarat ejekan yang dapat Anda temukan di Documents mereka. Jadi mari kita menambahkan kedua metode yang hilang.

Buka app/tests/TestCase.php dan menambahkan dua metode berikut:

Ini sangat bagus, kita sekarang mengatakan bahwa di setiap "setUp", yang dijalankan sebelum setiap tes, untuk kembali benih database. Namun kita masih memiliki satu masalah, setiap kali Anda kembali benih, itu hanya akan untuk menambahkan baris baru ke dalam tabel. Pengujian kami mencari item dengan ID baris satu, jadi kita masih memiliki beberapa perubahan untuk membuat. Kita hanya perlu memberitahu database untuk memotong meja kami ketika penyemaian:

app/database/seeds/CommentsTableSeeder.php

Sebelum kita menyisipkan baris baru, kita akan memotong Meja, menghapus semua baris dan reset auto-increment counter.

app/database/seeds/PostsTableSeeder.php

Sekarang Anda harus mampu menjalankan tes beberapa kali dan mendapatkan melewati tes setiap kali! Itu berarti kita telah memenuhi siklus TDD kami dan kami tidak diizinkan untuk menulis lagi kode produksi untuk API kami!! Mari kita hanya melakukan perubahan kami repo kami dan pindah ke aplikasi Backbone!


Tulang punggung App

Sekarang bahwa kita telah menyelesaikan semua pekerjaan pendukungnya, kita dapat bergerak maju untuk menciptakan bagus user interface untuk mengakses semua data itu. Kami akan membuat ini bagian dari proyek sedikit di sisi yang lebih sederhana, dan saya memperingatkan Anda bahwa pendekatan saya dapat dianggap satu dogmatis. Saya telah melihat banyak orang dengan begitu banyak metode yang berbeda untuk penataan aplikasi tulang punggung. Cobaan dan kesalahan saya telah membawa saya untuk metode saya saat ini, jika Anda tidak setuju dengan hal itu, harapan saya adalah bahwa itu dapat menginspirasi Anda untuk menemukan Anda sendiri!

Kita akan menggunakan mesin template kumis bukan Underscore, ini akan memungkinkan kita untuk berbagi pandangan kami antara klien dan server! Kuncinya adalah dalam bagaimana Anda memuat pandangan, kita akan menggunakan AJAX dalam tutorial ini, tetapi hanya sebagai mudah untuk memuat mereka semua ke dalam template utama, atau precompile mereka.

Router

Pertama kita akan mendapatkan kami akan router. Ada dua bagian ini, Laravel router, dan router tulang punggung.

Laravel Router

Ada dua pendekatan utama yang dapat kita ambil di sini:

Pendekatan #1: Catch-semua

Ingat saya katakan ketika Anda telah menambahkan jalur sumber daya itu penting bahwa Anda menempatkan mereka di atas jalur app?? Metode menangkap-semua adalah alasan untuk pernyataan itu. Tujuan keseluruhan dari metode ini adalah memiliki setiap rute yang memiliki tidak menemukan kecocokan di Laravel, tertangkap dan dikirim ke tulang punggung. Menerapkan metode ini mudah:

App/Routes.php

Sekarang, setiap rute selain rute API kami akan membuat pandangan app kami.

Selain itu, jika Anda memiliki multi-halaman app (beberapa satu halaman aplikasi), Anda dapat menetapkan beberapa ini menangkap-alls:

Catatan: Perlu diingat '/' sebelum {jalan?}. Jika garis miring yang ada, itu akan diminta dalam URL (dengan pengecualian rute indeks), kadang-kadang ini diinginkan dan kadang-kadang tidak.

Pendekatan #2:

Karena kami depan dan belakang berbagi pandangan... Bukankah akan sangat mudah untuk hanya menentukan rute di kedua tempat? Anda bahkan dapat melakukannya selain pendekatan menangkap-semua jika Anda ingin.

Rute yang kita akan berakhir dengan mendefinisikan untuk app adalah hanya:

App/Routes.php

Cukup keren ya?! Terlepas dari metode yang kita gunakan, atau kombinasi keduanya, router tulang punggung Anda akan berakhir umumnya sama.

Perhatikan bahwa kita menggunakan repositori kami lagi, ini adalah alasan lain mengapa repositori adalah tambahan yang berguna untuk kerangka kami. Kita sekarang dapat menjalankan hampir semua logika yang controller, tetapi tanpa mengulangi hampir tidak ada kode!

Perlu diingat beberapa hal saat memilih metode yang digunakan, jika Anda menggunakan menangkap-semua, akan melakukan seperti namanya... catch-semua. Ini berarti tidak ada hal seperti 404 situs Anda lagi. Tidak peduli atas permintaan, yang mendarat di halaman app (kecuali jika Anda secara manual melemparkan pengecualian di suatu tempat seperti repositori Anda). Invers adalah, dengan mendefinisikan setiap rute, sekarang Anda memiliki dua set rute untuk mengelola. Kedua metode memiliki mereka pasang dan surut, tetapi keduanya sama mudah untuk menangani.

Pandangan dasar

Satu pandangan untuk memerintah mereka semua! BaseView ini adalah pandangan bahwa semua pandangan-pandangan kami akan mewarisi dari. Untuk tujuan kita, pandangan ini memiliki tetapi satu pekerjaan... template! Dalam aplikasi yang lebih besar pandangan ini adalah tempat yang baik untuk menempatkan logika lain bersama.

Kami hanya akan memperpanjang Backbone.View dan tambahkan fungsi template yang akan kembali pandangan kita dari cache jika ada, atau mendapatkannya melalui AJAX dan menempatkannya dalam cache. Kita harus menggunakan AJAX sinkron karena cara bahwa Mustache.js mengambil parsial, tetapi karena kita hanya mengambil pandangan ini jika mereka tidak di-cache, kita tidak boleh menerima banyak pertunjukan hit sini.

PostView

PostView menuliskan satu blog posting:

Sebagian pemandangan

Kita akan membutuhkan beberapa pandangan untuk membuat parsial. Kita terutama hanya perlu memberitahu tampilan template yang menggunakan dan bahwa hal ini harus memperluas pandangan kami yang menyediakan metode untuk mengambil template kami.

Lihat blog

Ini adalah pandangan keseluruhan aplikasi kami. Ini berisi logika konfigurasi kita, serta penanganan mengambil PostCollection kami. Kami juga setup fitur terbatas gulir kecil yang keren. Perhatikan bagaimana kami menggunakan jQuery janji untuk memastikan bahwa mengambil koleksi kami telah selesai sebelum memberikan pandangan.

PostCollection

Setup PostCollection kami - kami hanya perlu memberitahu koleksi URL yang digunakan untuk mengambil isinya.

Blog Router

Perhatikan bahwa kita tidak sedang instantiating contoh baru dari pandangan kami, kami hanya memberitahu mereka untuk membuat. Fungsi menginisialisasi kami dirancang untuk hanya berlari sekali, karena kita tidak ingin mereka untuk menjalankan tetapi sekali, pada halaman load.

Pemberitahuan koleksi

Kami hanya akan men-setup sebuah koleksi yang sederhana untuk menyimpan pengguna pemberitahuan:

NotificationsView

Pandangan ini akan menangani menampilkan dan menyembunyikan pengguna pemberitahuan:

Penanganan kesalahan

Karena kita menggunakan pengendali kustom pengecualian untuk API kami, itu membuat sangat mudah untuk menangani kesalahan mungkin melemparkan API kami. Sangat mirip dengan cara kita mendefinisikan pendengar acara kami untuk API kami dalam app/filters.php file, kita akan mendefinisikan pendengar acara untuk aplikasi kami di sini. Setiap kode yang bisa dibuang hanya bisa menunjukkan pemberitahuan sangat mudah!


Pendengar acara

Kita akan membutuhkan beberapa pendengar acara global untuk membantu kami menavigasi melalui aplikasi kami tanpa menyegarkan halaman. Kami terutama hanya membajak perilaku default dan memanggil Backbone.history.navigate(). Perhatikan bagaimana pada pendengar pertama kami, kami Anda menentukan pemilih untuk hanya cocok dengan orang-orang yang tidak memiliki atribut data bypass. Ini akan memungkinkan kami untuk menciptakan link seperti <a href="/some/non-ajax/page" data-bypass="true">link</a> yang akan memaksa halaman untuk me-refresh. Kita juga bisa pergi satu langkah lebih lanjut di sini dan memeriksa apakah link yang lokal, dibandingkan dengan link ke situs lain.

Mulai App

Sekarang kita hanya perlu untuk mem-boot aplikasi, melewati dalam setiap nilai konfigurasi yang kita butuhkan. Perhatikan garis yang memeriksa variabel global silentRouter, ini adalah jenis hacky cara untuk dapat menggunakan kedua metode routing pendukungnya pada waktu yang sama. Hal ini memungkinkan kita untuk mendefinisikan variabel dalam pandangan yang disebut silentRouter dan set ke true, berarti bahwa router tidak harus benar-benar terlibat tulang punggung rute, memungkinkan kami back-end untuk menangani awal render halaman, dan hanya menunggu untuk pembaruan diperlukan atau AJAX.


Kesimpulan

Perhatikan bahwa untuk bagian tulang punggung aplikasi kami, Semua harus kita lakukan adalah menulis beberapa Javascript yang tahu bagaimana berinteraksi dengan bagian-bagian yang sudah ada sebelumnya aplikasi kami? Itu adalah apa yang saya sukai tentang metode ini! Ini mungkin tampak seperti kami memiliki banyak langkah-langkah untuk mengambil untuk mendapatkan bahwa sebagian dari hal-hal, tapi benar-benar, sebagian besar yang bekerja adalah hanya dasar timbunan. Setelah kami mendapat Yayasan awal di tempat, logika aplikasi sebenarnya jatuh bersama-sama sangat sederhana.

Mencoba menambahkan fitur lain untuk blog ini, seperti daftar User dan info. Langkah-langkah dasar yang Anda akan mengambil akan menjadi sesuatu seperti ini:

  • Menggunakan alat generator untuk menciptakan sumber daya "Pengguna" yang baru.
  • Membuat modifikasi yang diperlukan untuk memastikan bahwa UserController dalam kelompok V1 API.
  • Membuat repositori Anda dan setup binding IoC tepat di app/routes.php.
  • Menulis tes Controller Anda satu per satu waktu menggunakan ejekan untuk repositori, menindaklanjuti setiap tes dengan implementasi yang tepat untuk memastikan tes itu berlalu.
  • Menulis tes repositori Anda satu pada satu waktu, sekali lagi, menindaklanjuti setiap tes dengan implementasi.
  • Menambahkan dalam fungsi baru untuk aplikasi tulang punggung Anda. Saya sarankan mencoba dua pendekatan yang berbeda ke lokasi dilihat pengguna. Memutuskan untuk diri sendiri yang merupakan implementasi lebih baik.
    • Pertama-tama menempatkan mereka dalam rute mereka sendiri dan pemandangan utama.
    • Kemudian cobalah memasukkan mereka ke BlogView secara keseluruhan.

Saya harap ini memberikan Anda beberapa wawasan ke dalam menciptakan sebuah aplikasi scalable satu halaman dan API yang menggunakan Laravel 4 dan Backbone.js. Jika Anda memiliki pertanyaan, silakan minta mereka di bagian komentar di bawah ini!

Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.