5 Hal CodeIgniter Tidak Bisa Lakukan (tanpa penulisan ulang)

Halo teman-teman dumetschool !

Phil Sturgeon, salah seorang pengembang Codeigniter pernah menuliskan tentang komentarnya terhadap Codeigniter yang jika tidak ditulis ulang akan mempunyai beberapa kekurangan. Berikut pemaparannya.

Sekarang PHP 5.2 hilang dari hidup saya sepenuhnya saya seorang pria bahagia. Karena saya tidak menggunakan PHP 5.2 lagi saya tidak perlu lagi menggunakan Framework berbasis PHP versi 5.2, jadi saya mundur dari tim CodeIgniter dan mulai fokus pada pekerjaan baru saya.

PyroCMS bergerak menjadi PHP 5.3, sehingga saya dapat menggunakan fungsi anonim, operator ternary singkat, namespase, menggunakan fitursepenuhnya PSR-2 dan penggunaan Composer secara keseluruhan. PHP 5.3 adalah perubahan besar-besaran dari PHP 5.2 sebagai tentu saja dimaksudkan untuk menjadi PHP 6, jadi sementara itu mungkin tampak seperti update kecil namun sungguh tidak seperti itu. Ini membuka pintu untuk kemungkinan baru, gaya yang lebih baru pemrograman  yang matang dan tidak semenyebalkandari versi PHP sebelumnya.

Sebagian besar fitur yang ditambahkan ke PHP sebelum ini belum fundamental mengubah cara kerja Framework. Ini disajikan CodeIgniter dengan baik dan telah berhasil mempertahankan API yang sama selama saya bisa ingat. Sejak saya mulai menggunakan V1.4.1 kembali pada tahun 2007 atau apa pun yang saya sebut sebagai perubahan :
 

  1. Validasi yang usang diganti dengan sebuah library Form_validation yang ditingkatkan
  2. Konstruktor berubah menggunakan __construct () dari pada menggunakangaya konstruktorPHP 4
  3. Plugin yang dihapus
  4. Extends Controller menjadi CI_Controllermenjadi extendsCI_Controller
  5. Bukannya memberikan nilai return FALSE untuk data yang tidak diketahui sekarang akan kembali NULL (seperti yang PHP lakukan)


Selain itu, tidak ada yang terjadi untuk memecah aplikasi yang ada meskipun kita berhasil menambah sejumlah fitur. Jadi apa fitur yang hilang dari CodeIgniter yang cukup banyak dimiliki Framework lain saat ini, atau bekerja saat ditambahkan?


1. Autoloading

Saat fitur ini dimunculkan diPHP 5.1, 5.2 ratusan pengguna menyarankan untuk menulis ulang. Orang-orang yang ingin lebih statis dan lebih menyukai autoloading yang banyak. Namun EllisLab tak bergeming, yang menyebabkan para pengguna marah, berhenti dan membangun Kohana, yang otomatis meng-autoload kelas statis seperti mereka yang keluar dari pola umum yang ada.

CodeIgniter bukan memiliki fitur yang disebut "autoload", yang kerangka lainnya sebut sebagai "Selalu di-load" atau "Semangat-load". Pada dasarnya itu sebuah array hal untuk disertakan- itu saja.

Beberapa kali saya melihat ke bagaimana saya bisa bekerja autoloading ke CodeIgniter dengan benar, tetapi tidak pernah datang dengan sesuatu yang layak. Alasan utama di sini adalah bahwa tidak ada indikator untuk apa yang Anda benar-benar mencoba untuk memuat, jadi ketika Anda mencoba "Foo baru," itu bisa menjadi library, model, beberapa kode pihak ketiga acak Anda temukan di sebuah blog, sebuah kelas Zend yang terbungkus, apapun.

CodeIgniter akan perlu melakukan serangkaian file_exists () memeriksa seluruh mencoba dan menebak, kemudian setelah kelas ditemukan kita bisa menghasilkan cache kelas-peta (seperti Kohana). Itu tidak hanya tampak seperti solusi yang sedikit gila, tapi akan hampir pasti membingungkan banyak pemula dalam komunitas CodeIgniter yang tidak akan mengerti mengapa perubahan mereka tidak tercermin secara langsung.

Salah satu solusinya adalah dengan menggunakan akhiran atau awalan pada kelas (seperti FuelPHP) sebagai Model_Foo jelas model, sehingga hal-hal yang memotong turun sedikit, tapi setiap kali saya mengusulkan itu di forum setengah dari orang yang terlibat berteriak bahwa mereka membencinya , dan sisanya berdebat akhiran atau awalan, jadi aku menyerah mencoba.

Solusi ideal akan mencakup autoloader komposer, tapi itu tidak akan terjadi karena masyarakat pada umumnya selalu sangat anti terhadap utilitas baris perintah yang digunakan.


2. Namespace

CodeIgniter tidak menggunakan ruang Namespacesekali. Persyaratan untuk Namespacedapat agak dihindari jika Anda beri awalan atau akhiran padakelas, tapi itu hanya mondar-mandir dan bukan solusi. Namespace benar-benar harus diterapkan untuk semua kode inti, maka setiap paket harus memiliki namespace sendiri.

Hal ini secara drastis meningkatkan autoloading yang Anda berikan kelas autoload ke pointer mana harus mencari kode ini, bukan bagaimana paket saat bekerja: foreach mengecek semuanyasampai menemukan satu yang cocok. Jika dua paket berisi library "Curl" maka itu akan memuat yangpertama ditemukan. Yang kedua akan pernah dimuat berkat pendekatan "tunggal”, yang berarti jika paket B membutuhkan fungsi dalam versi yang berbeda dari "Curl" maka itu akan dipecah.

Masalah lain adalah salah satu yang dapat dilihat pada PyroCMS. Add-on pengembang tidak dapat membuat modul yang disebut "events". Ini akan membutuhkan controller yang disebut "Events", tapi ada kelas yang disebut "Events" yang merupakan library. Hal ini sangat membuat frustasi dan bisa diselesaikan dengandukungan prefix(awalan)atau suffi(akhiran). Sayaakan senang untuk bekerja didalamnya, tapi tentu saja dengan fitur namesspace PHP 5.3.


3. Abstraksi Skema Database

Ini hampirterjadi di versi 2.0 dan benar-benar bekerja dengan baik pada versi 2.1. Ketika saya mengatakan itu bekerja, maksud saya jika Anda menggunakan PDO untuk MySQL Anda bisa SELECT, INSERT, UPDATE, DELETE sempurna, tapi dbForge tidak bekerja sama sekali - dan masih tidak di cabang versi 3.0.

Andrey Andreev melakukan pekerjaan besar di sini dan menciptakan "PDO Sub-driver" yang sebagian besar bekerja. Dia telah mencoba sangat bagus dan agar segalanya bekerja dan sejauh yang saya tahu itu fitur terakhir tim kerjakan  sebelum versi 3.0 dirilis, tapi benar-benar sistem dbForge dimodelkan terlalu erat di sekitar MySQL agar benar-benar bekerja.

Apakah Anda tahu bagaimana Anda membuat teks lengkap yang dapat dicari di SQLite3 menggunakan dbForge? Kamu tidak bisa.

Ini hamper dengan sendirinya mengapa saya telah menghabiskan sedikit waktu lalu saat transisi installer PyroCMS disbanding  komponen databaseLaravel 4, karena ia mampu menginstal PyroCMS pada MySQL, PostgreSQL dan SQLite - yang akan menjadi fitur dalam PyroCMS 2.3.
 

4. Unit-Pengujian

Sampai 3.0-dev CodeIgniter tidak pernah memiliki unit-pengujian pada inti Framework. Mereka ditambahkan dengan beberapa pekerjaan heroik oleh Greg Aker (ex-Reaktor anggota tim), Pascal Kriete (karyawanEllisLab) dan beberapa kontributor. Saya menggunakan kata heroik, karena mendapatkan CodeIgniter unit diuji adalah sebuah lebih dari sekedar misi dan sesuatu yang sangat berat.

Inti semakin di-cover secarabaik (ketika aku meninggalkan beberapa bulan yang lalu itu 40-50%) tapi ada akan menjadi banyak CodeIgniter yang Anda sajatidak bisa tes - terutama aplikasi Anda.

Sebagai perbandingan lain untuk Laravel 4, Anda dapat unit menguji aplikasi Anda dengan sempurna.


5. Migrasi yang Baik

Saya menulis Migrasi untuk CodeIgniter, jadi saya tidak menyinggung siapa pun dengan mengatakan mereka menyebalkan.

Mengapa saya menulis migrasi itu menyebalkan untuk CodeIgniter? Karena itu yang terbaik yang bisa dilakukan tanpa bantuan Command-lineseperti Minyak untuk FuelPHP atau Artisan untuk Laravel. Benar-benar migrasi harus dihasilkan dengan argumen sederhana, menggunakan timestamp bukan nomor generik dan menjalankan dengan beberapa perintah seperti "php ci bermigrasi", tetapi Anda perlu untuk mengimplementasikan $this->migration->current() di pengait atau omong kosong untuk membuatnya berjalan pada loading halaman.

Maafkan saya.


Jadi ubah API!

Setiap proyek harus berjalan garis antara "Jangan Ubah Apapun" .Kami telah melihat perubahan ini membunuh komunitas terpisah di salah satu ujung spektrum, dan membiarkan orang lain membusuk dan memudar. Sementara saya selama bulan yang CodeIgniter belum ditulis ulang sendiri satu juta kali (yang benar-benar akan mengacaukan dengan PyroCMS) tetapi perlu ada semacam jalan tengah yang tidak terjadi.

Ini bukan berarti bahwa pembangunan tidak terjadi, karenaCodeIgniter memiliki lebih banyak perbaikan bug, peningkatan performa(tweaks), perbaikan dan fitur baru dibandingkan versi lain dalam sejarah.



Jumlah perubahan dalam setiap versi CodeIgniter sejauh ini.


Masalah di sini, adalah bahwa jika itu akan pindah ke PHP 5.3 hanya ada tiga hasil logis.

A) Perubahan Mayor

Untuk mengambil keuntungan dari fitur hilang yang saya sebutkan (terutama orang-orang yang menggunakan PHP 5.3) dan menghapus semua fitur berbasis PHP 4 "utang teknologi" lama dasarnya akan membuat Framework baru, dan perlu upaya serius untuk bermigrasi aplikasi.


B) Perubahan Sepele

API akan tetap hampir sama, tetapi beberapa yang baru di sintaks PHP 5.3 akan digunakan dalam inti seperti operator ternary singkat. Jika itu terjadi maka akan ada sedikit titik untuk memperbarui persyaratan versi Frameworkdi tempat pertama, dan orang-orang akan mengeluh bahwa fitur baru tidak cukup untuk menjamin mereka harus mengubah kode mereka sama sekali.

 
C) Tidak Ada Perubahan

CodeIgniter terus telah terang-terangan mengabaikan PHP baru fitur PHP baru, mengabaikan PSR-0, mengabaikan Composer dan mengabaikan semua hal-hal baru di luar sana di PHP.
 

Ini bukan "A"

Saya mengatakan ini karena beberapa alasan. Pertama, yang akan melakukannya? Sekarang Andrey dan Alex Bilbie melakukan pekerjaan yang menakjubkan mengatasimasalah utamatapi mereka tidak dibayar untuk melakukan hal ini, mereka melakukannya karena mereka menggunakan CodeIgniter dan ingin memastikan itu tetap bekerja - alasan yang sama saya diminta untuk berada di tim.

Ada insinyur Reaktor lain, tetapi sebagai teman mereka, saya tahu apa yang mereka sampai hari ini - dan itu bukan CodeIgniter.

Pertanyaan logis untuk bertanya selanjutnya adalah mengapa tidak EllisLab yang melakukannya? Mereka sudah tidak ditulis ulang dalam 6 tahun terakhir, mengapa mereka akan mulai sekarang? Semua pengembang CodeIgniter di EllisLab yang saya tahu dari masa lalu telah berhenti dari perusahaan Ellislab, sehingga adakah yang melakukannya? Derek Jones adalah CEO baru sehingga dia akan sibuk menjalankan seluruh perusahaan, tidak menulis Framework PHP.
 

Membuat turunan CodeIgniter?

Itu terjadi tiga kali sudah. Kohana dan FuelPHP keduanya diciptakan untuk alasan ini, Kohana bertujuan PHP 5.2 dan FuelPHP memanfaatkan PHP 5.3 dan namespaces. Laravel 3 juga berdasarkan berat pada CodeIgniter, Kohana dan FuelPHP - sehingga mereka sudah melakukan kerja keras, membangun komunitas, membangun sebuah situs web, mengatur account Twitter, merek dagang nama, diselenggarakan konferensi - saya tidak melihat bagaimana turunan lain akan membantu apa-apa.
 

Apakah CodeIgniter Mati?

Sama sekali tidak; dan tak seorang pun berada dalam posisi untuk menganjurkan hal tersebut(melihat Anda Shawn McCool). CodeIgniter hanya tidak akan pernah berubah, dan mungkin itu ok.

Ribuan perusahaan dari semua ukuran menggunakan CodeIgniter sehingga apa pun yang terjadi kerangka selalu akan berada di sekitar, tapi akan persis sama seperti sekarang untuk tahun yang akan datang, yang berarti Anda tidak akan harus meng-upgrade warisan apapun apps dalam waktu dekat. Hore!

Saya menulis ini karena orang telah bertanya mengapa saya telah membuang CodeIgniter untuk PyroCMS, dan mulai bergerak ke Laravel 4 gantinya. Saya yakin orang-orang akan berpikir aku hanya secaraliar mengecam CodeIgniter berhenti, tapi saya pikir mungkin untuk hormat menyoroti produk kekurangan tanpa ada kebencian atau dendam.

Alasan utama - dan saya akan mengulangi ini lagi dan lagi sampai semua orang bosan mendengar itu - adalah bahwa PHP akan melalui perubahan besar-besaran. Komposer, PSR, para PHP-gambar, pembuatan Travis-CI unit-testing tiba-tiba menjadi dingin, dll SEMUA berarti bahwa ada sebuah dunia baru yang dibangun di luar sana. Komponen PSR baru melakukan hal-hal luar biasa, dan membuat hal-hal seperti perpustakaan CodeIgniter Curl saya terlihat seperti sepotong mutlak omong kosong. Saatnya panggilan untuk alat-alat baru, jadi gunakan sesuatu yang baru.

Laravel 4 telah menjadi "awal" kerangka bagi saya karena itu dibangun persis bagaimana saya akan ingin melihat FuelPHP 2.0 dibangun. Komponen Laravel dapat digunakan dalam kerangka apapun dan kerangka itu sendiri sangat kurus dan sederhana. Ini semua PHP 5.3, namespace, PSR-1 compliant, dan terasa sangat familiar jika Anda pernah dibangun apa-apa dengan CodeIgniter, Kohana, FuelPHP atau bahkan Sinatra.

Sesuatu yang membuat Laravel berdiri keluar dari keramaian adalah bahwa hal itu menerimakebanggaan untuk memanfaatkan alat yang ada yang melakukan pekerjaan bukan menciptakan kembali roda untuk kepentingan itu. Monolog, Symfony Console, Doktrin umum, dll semua digunakan di mana diperlukan untuk melakukan tugas-tugas yang mereka dibangun.
 

Buat Keputusan Anda Sendiri

Jangan membabi buta dan beralih segalanya untuk kerangka kerja baru hanya karena beberapa orang bilang seperti demikiandi blog, ini terlihat konyol. Jika dukungan PHP 5.2 adalah hal Anda kemudian tinggal di mana Anda berada. Jika Anda suka CodeIgniter dan itu semua yang Anda butuhkan maka mengagumkan, lanjutkan.

Jika seperti saya Anda telah melewatibatas,CodeIgniter benar-benar akan membiarkan Anda melakukan, atau Anda hanya merasa bosan dan ingin mencoba sesuatu yang baru, maka periksalah Laravel 4.

Itu adalah repo GitHub untuk semua komponen komposer, lihatlah / app dan install composer untuk memulai mencoba.

Apa pun yang Anda lakukan, jika kerangka Anda tidak mendukung Composer bukanlah ide yang baik . Gunakan Composer untuk menginstal paket Anda, dan jika Anda mencoba untuk menggunakan sesuatu yang tidak memiliki composer.json kemudian berteriak sampai mereka lakukan - atau mencabut permintaan.

Tulisan ini dipublish https://philsturgeon.uk/blog/2012/12/5-things-codeigniter-cannot-do-without-a-rewrite/  pada 5 Desember 2012. Namun efeknya sekarang baru mulai terasa, Laravel menjadi Framework yang naik daun. Semangat ya teman-teman cool dan semoga bermanfaat.

6 Mei 2015

Webinar Gratis 2024


Selanjutnya Pada Bulan Maret 2024

Sabtu, 09 Maret 2024


10 Bahasa Rekomendasi Untuk Dipelajari di 2024

Python Developer, Data Science, Web Application

Kursus Python Django Web Application 2024 di DUMET School Seminar Java April 2024 di DUMET School
chat