Menggunakan CMS atau Framework?
Tags: cakephp, cms, codeigniter, drupal, framework, opensource, rubyonrails, Website
Saya termasuk orang yang mengembangkan website tanpa pernah membuatnya dari nol. Maksudnya, saya tidak membuat komponen dari website itu secara manual satu demi satu. Mulai dari arsitektur website, komponen modul, file uploader, user access, image manager, dll. Biasanya semua dilakukan dengan menggunakan CMS yang OpenSource, seperti Wordpress dan Drupal (jaman dulu juga termasuk PHPNuke). Biasanya memang saya melakukan modifikasi disana - sini agar website ini bisa bekerja sesuai keinginan. Umumnya akhirnya website tersebut akhirnya bisa berjalan sesuai harapan.
Tetapi kemudian datang masalah seperti berikut ini :
1. Website tersebut membutuhkan galery foto dengan fasilitas slideshow.
2. Website tersebut membutuhkan katalog produk.
3. Website tersebut ingin mengimplementasikan fasilitas social network.
4. Website itu ingin menyediakan fasilitas bagi membernya untuk bisa mengupload file MP3. Dan tiap member nantinya bisa mengatur level akses terhadap file MP3 yang dia upload.
5. Website tersebut ingin mempunyai form yang terintegrasi untuk arsip wawancara.
6. dll
Jika saya menggunakan CMS seperti Drupal. Mungkin hal ini masih bisa ditangani dengan ketersediaan modulnya yang sangat banyak. Atau jika memang modulnya belum tersedia, kita bisa membuat sendiri. Selain itu jika kurang puas, kita masih bisa melakukan oprek lebih dalam dengan menggunakan API yang disediakan Drupal. Dengan tujuan agar website ini sesuai dengan apa yang kita inginkan.
Tetapi, hal ini bisa jadi merupakan masalah baru. Tentunya kadangkala hal ini bisa menjadi solusi untuk satu masalah tetapi bukan tidak jarang malah menimbulkan masalah baru. Beberapa skenario yang sering terjadi :
1. Modul untuk CMS tersedia. Tetapi ada bagian yang tidak sesuai, bahkan mungkin ada bagian yang akhirnya malah terasa mengganggu. Misal modul e-commerce dari Drupal menyediakan begitu banyak fasilitas yang pada kenyataannya tidak saya butuhkan. Sedangkan untuk beberapa bagian justru masih belum sesuai harapan. Dan untuk bisa merubah modul ini, kita harus memahami hampir kesuluruhan struktur modul ini. Ditambah pengetahuan tentang API dari Drupal.
2. Terlalu banyak pilihan modul. Misal modul untuk upload gambar di Drupal. Secara default tidak ada. Kita masih bisa menginstal modul tambahan, sehingga nantinya upload gambar di Drupal akan semudah di Wordpress. Tetapi ketika sampai di tahap theming, saya menyadari bahwa field untuk gambar hasil upload modul tersebut tidak bisa diakse langsung. Berbeda dengan image yang diupload menggunakan bantuan module Image Field (CCK).
3. Dengan API yang disediakan, kadangkala kita masih membutuhkan pengetahuan tentang API lain. Dan pada akhirnya mau tidak mau saya harus mempelajari banyak API, hanya untuk mengetahui bagian mana dari API ini yang tepat untuk solusi masalah saya.
4. Salah satu hal yang paling sulit adalah merubah alur kerja dari website ini. Misal jika user ingin register, tidaklah langsung ditampilkan ke halaman register, tetapi harus melalui satu halaman polling terlebih dahulu. Untuk bisa mengimplementasikan ini, secara tidak langsung kita harus tahu alur kerja (workflow) dari CMS yang kita gunakan.
5. Butuh field yang custom untuk tiap post (tidak hanya field TITLE dan POST saja). Secara default Wordpress menyediakan fasilitas Custom Fields, tetapi penggunaannya masih belum senyaman CCK di Drupal. Untuk itu harus dibuat modul sendiri.
6. dll
Jika memang akhirnya saya ingin menjadi ahli dari CMS tersebut, saya rasa tidak masalah untuk mengikuti solusi yang saya berikan di atas. Tetapi jika saya hanya ingin menggunakan CMS ini sebagai bantuan, sepertinya effort nya terlalu besar.
Bahkan tidak jarang saya merasa, ketika mempelajari semua API, hook, templating, konvensi, dll dari suatu CMS, effortnya mungkin sama besarnya dengan jika saya membangun website tersebut dari nol.
Jadi apakah akhirnya membuat CMS dari nol?
Tidak. Bagi saya tetap tidak. Karena ada beberapa kemudahan di CMS yang tidak saya dapatkan jika saya harus membangun dari nol. Saya harus membangun kerangka / arsitektur dari website tersebut. Dan cukup banyak pula waktu yang tersita untuk membangunnya.
Jadi apa solusinya?
Framework. Bagi saya solusi di tengah - tengahnya adalah framework. Framework menjadi solusi yang tepat jika saya ingin mengembangkan website yang berbasis konten, tetapi dengan beberapa fasilitas yang tidak umum (seperti kasus di atas tadi). Dengan framework yang tepat, saya bisa membuat API saya sendiri, tetap mendapatkan fasilitas templating secara default, fasilitas layering untuk database, dan salah satu yang paling saya sukai adalah fasilitas URL Friendly secara default. Saya tidak tahu apakah semua framework menyediakan fasilitas tersebut, tetapi yang jelas Framework yang saya pakai (CodeIgniter) menggunakannya.
Pilihan framework yang cukup terkenal :
1. Prado - PHP (contoh : website Univertias Indonesia) : Kalau tidak salah ini seperti menjadi ASP.Net pada PHP
2. CodeIgniter - PHP(contoh : OkeZone.com), Jujur saja, saya tahu CodeIgniter dari situs OkeZone ini, dan sampai saat ini paling nyaman menggunakan ini, karena framework ini terdokumentasi dengan baik.
3. Ruby On Rails - Ruby (contoh : SharingFoto.com) : Situs ini diklaim sebagai web aplikasi pertama di Indonesia yang menggunakan Ruby On Rails.
4. CakePHP - PHP (contoh : OwnCafe.com) : Salah seorang yang sangat aktif dalam edukasi CakePHP di Indonesia adalah Sunu Wibirama (alumni Teknik Elektro UGM). Situs lokal cake-php bisa dilihat di idcake.web.id
5. Symfony (PHP), Django (Python), dll
Saya sendiri masih penasaran dan menantikan Mambo CMS versi 5.0 yang akan menggunakan CakePHP sebagai basisnya. Dengan kondisi seperti itu, maka level kustomisasi bisa dilakukan dari tingkat yang paling dasar (langsung menggunakan framework),di lapis tengah (modul), maupun lapis akhir (theming).
Jika ada yang tertarik dengan framework - framework di atas, jangan lupa pahami satu istilah ini : MVC (Model View Controller).
Monday 8 September 2008
Symfoni
Framework PHP yang ideal
http://dody.ws/framework-php-yang-ideal.html
Mengapa kita butuh framework?
Bagi anda yang belum familiar dengan framework, framework adalah sekumpulan fungsi, class, dan aturan-aturan. Berbeda dengan library yang sifatnya untuk tujuan tertentu saja, framework bersifat menyeluruh mengatur bagaimana kita membangun aplikasi.
Framework memungkinkan kita membangun aplikasi dengan lebih cepat karena sebagai developer kita akan lebih memfokuskan pada pokok permasalahan sedangkan hal-hal penunjang lainnya seperti koneksi database, form validation, GUI, dan security; umumnya telah disediakan oleh framework. Disamping itu dengan aturan-aturan yang jelas dan harus dipatuhi, aplikasi kita lebih solid, more readable, dan kolabarasi dalam tim dapat lebih mudah dilaksanakan.
Kita sebagai seorang software developer bisa dianalogikan sebagai seorang tukang bangunan. Apabila anda perhatikan, seorang tukang bangunan bisa membuat sebuah rumah. Tidak akan menjadi masalah bila hanya untuk membangun rumah dengan satu atau dua lantai. Tetapi akan menjadi masalah apabila dia mendapatkan pekerjaan untuk membangun sebuah gedung bertingkat. Permasalahan akan menjadi semakin komplek, makin banyak pekerja dan material yang dilibatkan, belum lagi dengan jadwal yang ketat. Kita pun seperti itu. Membangun aplikasi kecil tentu tidak menjadi masalah. Namun bagaimana bagaimana apabila aplikasi kecil kita tersebut dengan makin lama makin bertambah requirementnya sejalan dengan kebutuhan user. Di sini lah peran penting sebuah framework dalam membangun aplikasi.
Framework yang ideal menurut saya
Sejak fenomena Ruby on Rails, sebuah framework untuk bahasa Ruby, yang mana mampu memberi kemudahan yang luar biasa bagi developer dalam membangun aplikasi web; tumbuh menjamur framework-framework sejenis yang mengadopsi kemampuan Ruby on Rails untuk bahasa lainnya. Untuk PHP sendiri, terdapat PHP on Track, Symfony, PHPCake, CodeIgniter, dan masih banyak lainnya.
Saya telah mencoba Symfony, PHPCake, dan CodeIgniter. Symfony memiliki fasilitas paling lengkap, terdapat command line interface untuk membangun Object Relational Model (ORM), yang menterjemahkan relational database menjadi kode program; dukungan AJAX; scaffolding, yaitu membuat mekanisme CRUD (create, retrieve, update, and delete). Namun sayangnya Symfony hanya berjalan di PHP5. Sebenarnya tidak menjadi masalah, karena saat ini telah banyak web hosting yang menyediakan PHP5. Apa yang saya rasakan adalah, bahwa Symfony adalah framework yang sangat solid. Saya sangat menyukai fasilitas ORMnya, scaffolding yang kompleks, dan tutorial dan dokumentasi yang sangat bagus dan komplit. Bagaimana tidak bagus, selain disediakan User Guide yang berisi referensi API, juga disediakan sebuah buku berisi study case pembuatan aplikasi ASKEET mulai dari desain awal sampai selesai pengkodean. Di samping itu terdapat juga tutorial yang berupa file movie, namun karena berukuran yang cukup besar, saya enggan mendownloadnya, saya merasa sudah cukup dengan manual berbentuk pdf. Secara kontras, saya juga merasakan bahwa Symfony adalah seperti senjata kelas berat. Untuk mengoperasikannya butuh learning curve yang cukup lama. Saya juga merasakan kekuatan yang out of control, dimana ketika terjadi saya menginginkan sebuah perubahan yang agak berbeda dari tutorial yang diberikan, saya seperti tidak tahu harus kemana dan bagaimana. Saya mencoba bertahan selama 3 hari dengan berusaha membuat aplikasi sederhana, namun pada akhirnya saya putuskan untuk berhenti.
Berikutnya adalah CakePHP, framework ini juga memiliki ORM dan scaffolding seperti halnya Symfony. Terdapat juga command line interface, yang disebut sebagai baker, namun sifatnya tidak mutlak digunakan. Secara keseluruhan CakePHP memiliki kemampuan tidak jauh dari Symfony, namun sekilas lebih sederhana dan ukurannya lebih kecil, dan yang tidak kalah menarik adalah kompatibilitasnya dengan PHP4. Namun sayang, dokumentasi kurang lengkap, sehingga saya kesulitan mencari informasi lebih dalam. Untung lah CakePHP membuka channel IRC sehingga kita bisa berkonsultasi langsung dengan para pakarnya. Saya sudah mencoba menanyakan permasalahan di channel IRC yang disediakan. Saya mendapatkan respon yang memuaskan dari pakarnya (developer CakePHP) sehingga permasalahn saya saat itu dapat diatasi. Namun di kesempatan lain, saya tidak mendapat respon sama sekali, saya mencari orang yang telah membantu saya sebelumnya, tetapi sepertinya dia tidak online. Saya merasa CakePHP tidak bisa memberikan apa yang saya inginkan, meski pun saya telah mencoba tutorial dan membaca panduan lainnya, saya tetap tidak besa melakukan apa-apa yang saya inginkan, atau bisa dibilang saya kebingungan, seperti halnya pada saat mencoba Symfony.
CodeIgniter, framework ini sebelumnya tidak masuk daftar yang akan saya coba. Hal ini dikarenakan oleh fiturnya yang jauh lebih sedikit dibandingkan Symfony dan CakePHP. Tidak ada ORM, scaffolding sangat sederhana, tidak ada AJAX, tidak ada user authentication. Lalu apa yang saya bisa harapkan darinya? Bermula dari membaca berbagai review php framework di blog lain, mereka mengatakan bahwa CodeIgniter memiliki kinerja yang lebih bagus daripada Symfony maupun CakePHP, dikarenakan oleh library yang di-load oleh framework lebih sedikit. Setelah saya mencobanya, memang framework ini terasa beda. Terasa lebih ringan dan lebih bebas. Meskipun CodeIgniter juga menggunakan design pattern MVC, namun tidak lah mutlak untuk menggunakan M (model). Jadi saya bisa dengan bebas menggunakan style yang saya sukai. Sajian dokumentasinya cukup lengkap, meskipun tidak selengkap Symfony, namun sangat memadai. Saya bisa melakukan ini itu setelah saya membaca panduan di online manual. Sangat menyenangkan, dimana Symfony dan CakePHP tidak bisa memberikannya untuk saya. Meskipun memiliki kemampuan yang dibawah framework lainnya, namun CodeIgniter sangat mudah untuk dipelajari. Mungkin ini lah yang dimaksud dengan framework lightweight. Mudah dan sangat ringan, namun tidak memiliki fasilitas sebanyak framework lainnya. Ketika saya amati forum dan halaman wiki, komunitas CodeIgniter memberikan solusi untuk permasalahan seperti User Authentication dan Ajax. Sepertinya memang pembuat CodeIgniter sengaja memberikan kebebasan kepada usernya untuk mengembangkan sendiri sesuai dengan kebutuhan masing-masing yang berbeda, sedangkan CodeIgniter bertanggungjawab terhadap tugas-tugas lain yang lebih utama.
Bagi saya CodeIgniter menarik, mudah dipelajari, dan sangat solid untuk membangun aplikasi yang besar. Peraturan-peraturan dan library yang disediakannya tidak membatasi saya untuk tetap menggunkan style pemrograman yang saya sukai. Ini adalah point penting. Siapa mengatur siapa, programer mengatur program atau program mengatur programer?
source : mamat.amikom.ac.id
http://dody.ws/framework-php-yang-ideal.html
Mengapa kita butuh framework?
Bagi anda yang belum familiar dengan framework, framework adalah sekumpulan fungsi, class, dan aturan-aturan. Berbeda dengan library yang sifatnya untuk tujuan tertentu saja, framework bersifat menyeluruh mengatur bagaimana kita membangun aplikasi.
Framework memungkinkan kita membangun aplikasi dengan lebih cepat karena sebagai developer kita akan lebih memfokuskan pada pokok permasalahan sedangkan hal-hal penunjang lainnya seperti koneksi database, form validation, GUI, dan security; umumnya telah disediakan oleh framework. Disamping itu dengan aturan-aturan yang jelas dan harus dipatuhi, aplikasi kita lebih solid, more readable, dan kolabarasi dalam tim dapat lebih mudah dilaksanakan.
Kita sebagai seorang software developer bisa dianalogikan sebagai seorang tukang bangunan. Apabila anda perhatikan, seorang tukang bangunan bisa membuat sebuah rumah. Tidak akan menjadi masalah bila hanya untuk membangun rumah dengan satu atau dua lantai. Tetapi akan menjadi masalah apabila dia mendapatkan pekerjaan untuk membangun sebuah gedung bertingkat. Permasalahan akan menjadi semakin komplek, makin banyak pekerja dan material yang dilibatkan, belum lagi dengan jadwal yang ketat. Kita pun seperti itu. Membangun aplikasi kecil tentu tidak menjadi masalah. Namun bagaimana bagaimana apabila aplikasi kecil kita tersebut dengan makin lama makin bertambah requirementnya sejalan dengan kebutuhan user. Di sini lah peran penting sebuah framework dalam membangun aplikasi.
Framework yang ideal menurut saya
Sejak fenomena Ruby on Rails, sebuah framework untuk bahasa Ruby, yang mana mampu memberi kemudahan yang luar biasa bagi developer dalam membangun aplikasi web; tumbuh menjamur framework-framework sejenis yang mengadopsi kemampuan Ruby on Rails untuk bahasa lainnya. Untuk PHP sendiri, terdapat PHP on Track, Symfony, PHPCake, CodeIgniter, dan masih banyak lainnya.
Saya telah mencoba Symfony, PHPCake, dan CodeIgniter. Symfony memiliki fasilitas paling lengkap, terdapat command line interface untuk membangun Object Relational Model (ORM), yang menterjemahkan relational database menjadi kode program; dukungan AJAX; scaffolding, yaitu membuat mekanisme CRUD (create, retrieve, update, and delete). Namun sayangnya Symfony hanya berjalan di PHP5. Sebenarnya tidak menjadi masalah, karena saat ini telah banyak web hosting yang menyediakan PHP5. Apa yang saya rasakan adalah, bahwa Symfony adalah framework yang sangat solid. Saya sangat menyukai fasilitas ORMnya, scaffolding yang kompleks, dan tutorial dan dokumentasi yang sangat bagus dan komplit. Bagaimana tidak bagus, selain disediakan User Guide yang berisi referensi API, juga disediakan sebuah buku berisi study case pembuatan aplikasi ASKEET mulai dari desain awal sampai selesai pengkodean. Di samping itu terdapat juga tutorial yang berupa file movie, namun karena berukuran yang cukup besar, saya enggan mendownloadnya, saya merasa sudah cukup dengan manual berbentuk pdf. Secara kontras, saya juga merasakan bahwa Symfony adalah seperti senjata kelas berat. Untuk mengoperasikannya butuh learning curve yang cukup lama. Saya juga merasakan kekuatan yang out of control, dimana ketika terjadi saya menginginkan sebuah perubahan yang agak berbeda dari tutorial yang diberikan, saya seperti tidak tahu harus kemana dan bagaimana. Saya mencoba bertahan selama 3 hari dengan berusaha membuat aplikasi sederhana, namun pada akhirnya saya putuskan untuk berhenti.
Berikutnya adalah CakePHP, framework ini juga memiliki ORM dan scaffolding seperti halnya Symfony. Terdapat juga command line interface, yang disebut sebagai baker, namun sifatnya tidak mutlak digunakan. Secara keseluruhan CakePHP memiliki kemampuan tidak jauh dari Symfony, namun sekilas lebih sederhana dan ukurannya lebih kecil, dan yang tidak kalah menarik adalah kompatibilitasnya dengan PHP4. Namun sayang, dokumentasi kurang lengkap, sehingga saya kesulitan mencari informasi lebih dalam. Untung lah CakePHP membuka channel IRC sehingga kita bisa berkonsultasi langsung dengan para pakarnya. Saya sudah mencoba menanyakan permasalahan di channel IRC yang disediakan. Saya mendapatkan respon yang memuaskan dari pakarnya (developer CakePHP) sehingga permasalahn saya saat itu dapat diatasi. Namun di kesempatan lain, saya tidak mendapat respon sama sekali, saya mencari orang yang telah membantu saya sebelumnya, tetapi sepertinya dia tidak online. Saya merasa CakePHP tidak bisa memberikan apa yang saya inginkan, meski pun saya telah mencoba tutorial dan membaca panduan lainnya, saya tetap tidak besa melakukan apa-apa yang saya inginkan, atau bisa dibilang saya kebingungan, seperti halnya pada saat mencoba Symfony.
CodeIgniter, framework ini sebelumnya tidak masuk daftar yang akan saya coba. Hal ini dikarenakan oleh fiturnya yang jauh lebih sedikit dibandingkan Symfony dan CakePHP. Tidak ada ORM, scaffolding sangat sederhana, tidak ada AJAX, tidak ada user authentication. Lalu apa yang saya bisa harapkan darinya? Bermula dari membaca berbagai review php framework di blog lain, mereka mengatakan bahwa CodeIgniter memiliki kinerja yang lebih bagus daripada Symfony maupun CakePHP, dikarenakan oleh library yang di-load oleh framework lebih sedikit. Setelah saya mencobanya, memang framework ini terasa beda. Terasa lebih ringan dan lebih bebas. Meskipun CodeIgniter juga menggunakan design pattern MVC, namun tidak lah mutlak untuk menggunakan M (model). Jadi saya bisa dengan bebas menggunakan style yang saya sukai. Sajian dokumentasinya cukup lengkap, meskipun tidak selengkap Symfony, namun sangat memadai. Saya bisa melakukan ini itu setelah saya membaca panduan di online manual. Sangat menyenangkan, dimana Symfony dan CakePHP tidak bisa memberikannya untuk saya. Meskipun memiliki kemampuan yang dibawah framework lainnya, namun CodeIgniter sangat mudah untuk dipelajari. Mungkin ini lah yang dimaksud dengan framework lightweight. Mudah dan sangat ringan, namun tidak memiliki fasilitas sebanyak framework lainnya. Ketika saya amati forum dan halaman wiki, komunitas CodeIgniter memberikan solusi untuk permasalahan seperti User Authentication dan Ajax. Sepertinya memang pembuat CodeIgniter sengaja memberikan kebebasan kepada usernya untuk mengembangkan sendiri sesuai dengan kebutuhan masing-masing yang berbeda, sedangkan CodeIgniter bertanggungjawab terhadap tugas-tugas lain yang lebih utama.
Bagi saya CodeIgniter menarik, mudah dipelajari, dan sangat solid untuk membangun aplikasi yang besar. Peraturan-peraturan dan library yang disediakannya tidak membatasi saya untuk tetap menggunkan style pemrograman yang saya sukai. Ini adalah point penting. Siapa mengatur siapa, programer mengatur program atau program mengatur programer?
source : mamat.amikom.ac.id
Source TA
Notes on Choosing a PHP Framework: A Quick Comparison of CodeIgniter and Kohana
February 23rd, 2008
When I was reading through my subscribed feeds I came across this post: Notes on Choosing a PHP Framework: A Comparison of CakePHP and the Zend Framework by Chad Kieffer.
Chad has done a great job comparing the two frameworks that he’s interested in. That inspired me to write something up for the frameworks that I prefer and use. :)
I began hunting for PHP frameworks ever since Ruby on Rails hit the street. Coincidentally one of the first PHP frameworks I played with was CakePHP. At that time CakePHP’s documentation was nearly non-existent so I had to seek for an alternative. I did a lot of searches, and researches, and finally I was happy to see CodeIgniter. Its user guide was what impressed me the most, I am sure many of the fellow CI users would agree with me on this one. Because of the excellent documentation, I was able to start working on projects right after I spent a few hours on the user guide! Developing apps on CI was such a breeze! Today, I develop web applications in CodeIgniter, Kohana and Zend Framework. If you want to find out how to use Zend Framework components with CI or Kohana, please read my previous blog entry: Using Zend Framework with CodeIgniter.
From version 1.2 when I first started coding on CI, to the newly released version 1.6.1 it sure is a long way. CodeIgniter has progressed well and gained many web developers’ trust, despite a few glitches. One of which was the spawn of the fork: Kohana.
CodeIgniter had some low periods where developers were all focused on pushing out new releases of ExpressionEngine, their commercial blogging/cms product. Some of the users on the CI forum got frustrated because their bug reports and feature requests were ignored. As a result of that, BlueFlame was born, and later renamed to Kohana.
Kohana is relatively unknown to the public. In fact, most of the Kohana users are ex-CI users or users that uses both CI and Kohana (like myself). According to the Kohana homepage and Wikipedia, the differences between Kohana and CodeIgniter are:
1. Strict PHP5 OOP. Offers many benefits: visibility protection, automatic class loading, overloading, interfaces, abstracts, and singletons.
2. Kohana has joined the GoPHP5 initiative. All releases from 2.2 on will conform with this project.
3. Continues CodeIgniter design patterns. Anyone who has used CodeIgniter will quickly understand Kohana’s structure and design patterns.
4. Community, not company, driven. Kohana is driven by community discussion, ideas, and code. Kohana developers are from all around the world, each with their own talents. This allows a rapid and flexible development cycle that can respond to bugs and requests within hours, instead of days or months.
5. GET, POST, COOKIE, and SESSION arrays all work as expected. Kohana does not limit your access to global data, but offers the same filtering and XSS protection that CodeIgniter does.
6. Cascading resources, modules, and inheritance. Controllers, models, libraries, helpers, and views can be loaded from any location within your system, application, or module paths. Configuration options are inherited and can by dynamically overwritten by each application.
7. No namespace conflicts. Class suffixes, like _Controller, are used to prevent namespace conflicts. This allows a User’s controller and Users model to both be loaded at the same time.
8. True auto-loading of classes. This includes libraries, controllers, models, and helpers. This is not pre-loading, but true dynamic loading of classes, as they are requested.
9. Helpers are static classes, not functions. For example, instead of using form_open(), you would use form::open().
10. Library drivers and API consistency. Libraries can use different “drivers” to handle different external APIs transparently. For example, multiple session storage options are available (database, cookie, and native), but the same interface is used for all of them. This allows new drivers to be developed for existing libraries, which keeps the API consistent and transparent.
11. Powerful event handler. Kohana events can by dynamically added to, replaced, or even removed completely. This allows many changes to Kohana execution process, without modification to existing system code.
As you can see, whilst maintaining a certain level of similarity to CodeIgniter, Kohana does offer some advantages (at the same time, some disadvantages). Let’s take a look at a few quick comparisons. Grading scale: Limited < Fair < Good < Excellent. Please note: if a feature is not available in the distributed package, but is available via 3rd party libraries, I will state that in the comparison. If a feature is available both in the distributed package and via 3rd party libraries, only the official one will get assessed.
Feature Comparison of CodeIgniter and Kohana Feature CodeIgniter 1.6.1 Kohana 2.1.1 Notes
License Apache/BSD-style new BSD Licenses are similar, although Kohana uses the new BSD license which is slightly more flexible than CI’s modified BSD license.
PHP compatibility 4.3.2+ and 5 5.1.3+ CodeIgniter supports PHP4 whilst Kohana is a stict PHP5 framework. If you are using PHP5 then Kohana offers more OOP and performance advantages. Start from version 2.2 (yet to be released), Kohana will only support PHP 5.2+.
Supported Databases MySQL (4.1+)
MySQLi
MS SQL
PostgreSQL
SQLite
Oracle
ODBC MySQL
PostgreSQL
SQLite CodeIgniter’s longer history ensures us a more widely available database support options than Kohana, although in the future Kohana is likely to support more databases too.
Community Forum
Wiki
Bug Tracker Forum
Trac
IRC CodeIgniter obviously has a much larger community and offers a wiki for community members to share tutorials and code snippets. Kohana on the other hand, has a smaller community, however the developers are actively online on the forum and IRC.
Documentation / User Guide Excellent Limited CodeIgniter is known for its excellent user guide. Kohana is in the process of improving its documentation.
Tutorial / Sample Availability Good Fair Tutorials are available on both of their forums. CodeIgniter has the advantage of having a wiki for easier navigation. Kohana on the other hand, has a dedicated tutorial page for some of the tutorials.
MVC Strict Strict Both frameworks use the same MVC approach.
Modular / HMVC Via 3rd party libraries Built in Kohana is built with HMVC in mind whilst CodeIgniter has some 3rd party libraries such as Matchbox and Modular HMVC to accomplish the same effect.
Conventions Flexible Flexible Unlike CakePHP, both of the frameworks offer flexible convensions. There are some defaults but most of them can be overwritten.
Configuration PHP files PHP files In my opinion Kohana is more configurable than CodeIgniter yet it is simpler (less clustered) to do so! Most of the Kohana configuration files are stored in the system folder, you only copy and paste the ones you actually need to modify, and modify them accordingly. CodeIgniter’s config files are all stored in the application folder.
Database Abstraction Modified ActiveRecord Modified ActiveRecord
ORM (optional) Both frameworks use the modified ActiveRecord pattern. Kohana has an optional ORM module. CodeIgniter has some ORM and Rails-style ActiveRecord implementation avaliable via 3rd party libraries.
ACL Via 3rd party libraries Auth library (optional) Neither of the frameworks forces you to use a specific ACL mechanism. CodeIgniter does not have one built in, and Kohana has one available as an optional module.
Validation Good Good Both frameworks offer a good built in validtion layer. Kohana 2.2 is planned to have some significant improvements for the validation library.
Caching Limited Fair In my opinion both of the caching features are limited. Kohana offers a slightly more useful cache library that supports file, SQLite, APC, eAccelerator, memcache, and Xcache based caching, with tag support.
Session Good Excellent CodeIgniter 1.6 has improved its session library, but it’s still inferior to Kohana’s implementation. Kohana’s session library supports both encryption and storing session data in database.
Logging / Debugging Good Excellent Both frameworks offer very good logging and debugging mechanisms. Kohana is a little bit ahead thanks to PHP5’s native Exception class and its powerful event handlers.
Templating Native PHP Native PHP Templating is *very* easy for both frameworks. If you can skin Wordpress, then you’d have no problems at all skinning CI or Kohana. If you want though, you can still incorporate one of the 3rd party templating solutions such as Smarty.
Helpers Good Good Helpers are usually libraries that used for simple, repetitive tasks. Both frameworks offer a wide range of helpers for handling forms, URLs and dates, etc.
JavaScript / AJAX N/A N/A Both frameworks respect your choice of JavaScript / AJAX frameworks. Unlike CakePHP and Ruby on Rails, they don’t have built-in helpers for any of the JavaScript libraries. This offers more flexibility as well as the use of unobtrusive JavaScript.
Web Services Fair Fair I could be wrong but I don’t think either framework supports (or at least encourages) RESTful design…
Localization Limited Good CodeIgniter has limited i18n support whilst Kohana offers a bit more (timezone / full UTF8 layer, etc).
Unit Testing Limited None * CodeIgniter’s built in unit testing class is very limited. * Kohana as of version 2.1.1 does not have a unit testing class, however it is planned for version 2.2.
The Verdict
February 23rd, 2008
When I was reading through my subscribed feeds I came across this post: Notes on Choosing a PHP Framework: A Comparison of CakePHP and the Zend Framework by Chad Kieffer.
Chad has done a great job comparing the two frameworks that he’s interested in. That inspired me to write something up for the frameworks that I prefer and use. :)
I began hunting for PHP frameworks ever since Ruby on Rails hit the street. Coincidentally one of the first PHP frameworks I played with was CakePHP. At that time CakePHP’s documentation was nearly non-existent so I had to seek for an alternative. I did a lot of searches, and researches, and finally I was happy to see CodeIgniter. Its user guide was what impressed me the most, I am sure many of the fellow CI users would agree with me on this one. Because of the excellent documentation, I was able to start working on projects right after I spent a few hours on the user guide! Developing apps on CI was such a breeze! Today, I develop web applications in CodeIgniter, Kohana and Zend Framework. If you want to find out how to use Zend Framework components with CI or Kohana, please read my previous blog entry: Using Zend Framework with CodeIgniter.
From version 1.2 when I first started coding on CI, to the newly released version 1.6.1 it sure is a long way. CodeIgniter has progressed well and gained many web developers’ trust, despite a few glitches. One of which was the spawn of the fork: Kohana.
CodeIgniter had some low periods where developers were all focused on pushing out new releases of ExpressionEngine, their commercial blogging/cms product. Some of the users on the CI forum got frustrated because their bug reports and feature requests were ignored. As a result of that, BlueFlame was born, and later renamed to Kohana.
Kohana is relatively unknown to the public. In fact, most of the Kohana users are ex-CI users or users that uses both CI and Kohana (like myself). According to the Kohana homepage and Wikipedia, the differences between Kohana and CodeIgniter are:
1. Strict PHP5 OOP. Offers many benefits: visibility protection, automatic class loading, overloading, interfaces, abstracts, and singletons.
2. Kohana has joined the GoPHP5 initiative. All releases from 2.2 on will conform with this project.
3. Continues CodeIgniter design patterns. Anyone who has used CodeIgniter will quickly understand Kohana’s structure and design patterns.
4. Community, not company, driven. Kohana is driven by community discussion, ideas, and code. Kohana developers are from all around the world, each with their own talents. This allows a rapid and flexible development cycle that can respond to bugs and requests within hours, instead of days or months.
5. GET, POST, COOKIE, and SESSION arrays all work as expected. Kohana does not limit your access to global data, but offers the same filtering and XSS protection that CodeIgniter does.
6. Cascading resources, modules, and inheritance. Controllers, models, libraries, helpers, and views can be loaded from any location within your system, application, or module paths. Configuration options are inherited and can by dynamically overwritten by each application.
7. No namespace conflicts. Class suffixes, like _Controller, are used to prevent namespace conflicts. This allows a User’s controller and Users model to both be loaded at the same time.
8. True auto-loading of classes. This includes libraries, controllers, models, and helpers. This is not pre-loading, but true dynamic loading of classes, as they are requested.
9. Helpers are static classes, not functions. For example, instead of using form_open(), you would use form::open().
10. Library drivers and API consistency. Libraries can use different “drivers” to handle different external APIs transparently. For example, multiple session storage options are available (database, cookie, and native), but the same interface is used for all of them. This allows new drivers to be developed for existing libraries, which keeps the API consistent and transparent.
11. Powerful event handler. Kohana events can by dynamically added to, replaced, or even removed completely. This allows many changes to Kohana execution process, without modification to existing system code.
As you can see, whilst maintaining a certain level of similarity to CodeIgniter, Kohana does offer some advantages (at the same time, some disadvantages). Let’s take a look at a few quick comparisons. Grading scale: Limited < Fair < Good < Excellent. Please note: if a feature is not available in the distributed package, but is available via 3rd party libraries, I will state that in the comparison. If a feature is available both in the distributed package and via 3rd party libraries, only the official one will get assessed.
Feature Comparison of CodeIgniter and Kohana Feature CodeIgniter 1.6.1 Kohana 2.1.1 Notes
License Apache/BSD-style new BSD Licenses are similar, although Kohana uses the new BSD license which is slightly more flexible than CI’s modified BSD license.
PHP compatibility 4.3.2+ and 5 5.1.3+ CodeIgniter supports PHP4 whilst Kohana is a stict PHP5 framework. If you are using PHP5 then Kohana offers more OOP and performance advantages. Start from version 2.2 (yet to be released), Kohana will only support PHP 5.2+.
Supported Databases MySQL (4.1+)
MySQLi
MS SQL
PostgreSQL
SQLite
Oracle
ODBC MySQL
PostgreSQL
SQLite CodeIgniter’s longer history ensures us a more widely available database support options than Kohana, although in the future Kohana is likely to support more databases too.
Community Forum
Wiki
Bug Tracker Forum
Trac
IRC CodeIgniter obviously has a much larger community and offers a wiki for community members to share tutorials and code snippets. Kohana on the other hand, has a smaller community, however the developers are actively online on the forum and IRC.
Documentation / User Guide Excellent Limited CodeIgniter is known for its excellent user guide. Kohana is in the process of improving its documentation.
Tutorial / Sample Availability Good Fair Tutorials are available on both of their forums. CodeIgniter has the advantage of having a wiki for easier navigation. Kohana on the other hand, has a dedicated tutorial page for some of the tutorials.
MVC Strict Strict Both frameworks use the same MVC approach.
Modular / HMVC Via 3rd party libraries Built in Kohana is built with HMVC in mind whilst CodeIgniter has some 3rd party libraries such as Matchbox and Modular HMVC to accomplish the same effect.
Conventions Flexible Flexible Unlike CakePHP, both of the frameworks offer flexible convensions. There are some defaults but most of them can be overwritten.
Configuration PHP files PHP files In my opinion Kohana is more configurable than CodeIgniter yet it is simpler (less clustered) to do so! Most of the Kohana configuration files are stored in the system folder, you only copy and paste the ones you actually need to modify, and modify them accordingly. CodeIgniter’s config files are all stored in the application folder.
Database Abstraction Modified ActiveRecord Modified ActiveRecord
ORM (optional) Both frameworks use the modified ActiveRecord pattern. Kohana has an optional ORM module. CodeIgniter has some ORM and Rails-style ActiveRecord implementation avaliable via 3rd party libraries.
ACL Via 3rd party libraries Auth library (optional) Neither of the frameworks forces you to use a specific ACL mechanism. CodeIgniter does not have one built in, and Kohana has one available as an optional module.
Validation Good Good Both frameworks offer a good built in validtion layer. Kohana 2.2 is planned to have some significant improvements for the validation library.
Caching Limited Fair In my opinion both of the caching features are limited. Kohana offers a slightly more useful cache library that supports file, SQLite, APC, eAccelerator, memcache, and Xcache based caching, with tag support.
Session Good Excellent CodeIgniter 1.6 has improved its session library, but it’s still inferior to Kohana’s implementation. Kohana’s session library supports both encryption and storing session data in database.
Logging / Debugging Good Excellent Both frameworks offer very good logging and debugging mechanisms. Kohana is a little bit ahead thanks to PHP5’s native Exception class and its powerful event handlers.
Templating Native PHP Native PHP Templating is *very* easy for both frameworks. If you can skin Wordpress, then you’d have no problems at all skinning CI or Kohana. If you want though, you can still incorporate one of the 3rd party templating solutions such as Smarty.
Helpers Good Good Helpers are usually libraries that used for simple, repetitive tasks. Both frameworks offer a wide range of helpers for handling forms, URLs and dates, etc.
JavaScript / AJAX N/A N/A Both frameworks respect your choice of JavaScript / AJAX frameworks. Unlike CakePHP and Ruby on Rails, they don’t have built-in helpers for any of the JavaScript libraries. This offers more flexibility as well as the use of unobtrusive JavaScript.
Web Services Fair Fair I could be wrong but I don’t think either framework supports (or at least encourages) RESTful design…
Localization Limited Good CodeIgniter has limited i18n support whilst Kohana offers a bit more (timezone / full UTF8 layer, etc).
Unit Testing Limited None * CodeIgniter’s built in unit testing class is very limited. * Kohana as of version 2.1.1 does not have a unit testing class, however it is planned for version 2.2.
The Verdict
Wednesday 3 September 2008
Object Relational Mapping [02]
List Of ORM Software
Java
* Carbonado, open source framework, backed by Berkeley DB or JDBC
* Cayenne, apache, open source for java
* Ebean, open source ORM Framework
* EclipseLink, Eclipse Persistence Platform
* Enterprise Objects Framework, Mac OS X/Java, part of Apple WebObjects
* Hibernate, open source ORM Framework, widely used
* iBATIS, maintained by ASF, and with .NET port.
* Java Data Objects (JDO)
* JPOX, open source JDO 2 reference implementation
* Kodo, commercial implementation of both the JDO and JPA API.
* OpenJPA, apache, open source, supports JPA API.
* TopLink by Oracle
* WebObjects commercial (but for free) from Apple, includes EOF as the object-relational mapping layer
.NET
* ADO.NET Entity Framework, Microsoft's ORM (released with .NET 3.5 SP1)
* Base One Foundation Component Library, free or commercial
* Business Logic Toolkit for .NET, open source
* Castle ActiveRecord, ActiveRecord for .NET, open source
* Developer Express, eXpress Persistent Objects (XPO)
* EntitySpaces, commercial
* Gentle.NET, open source
* Habanero, Free open source
* LightSpeed, Free or commercial
* Linq language integrated query
* LLBLGen, open source
* LLBLGen Pro, commercial
* NConstruct, commercial, application and code generator for NHibernate
* Neo, open source
* NHibernate, open source
* ObjectMapper .NET, GPL and commercial license
* Persistor.NET, free or commercial
* Sooda, open source; BSD license
PHP
* ADOdb Active Record, included in newer versions of the open source ADOdb. (BSD license)
* Doctrine, Open Source ORM for PHP 5.2.3, free software (GNU LGPL)
* Propel, ORM and Query-Toolkit for PHP 5, inspired by Apache Torque, free software (GNU LGPL)
* SilverStripe, free PHP5-based ORM integrated with a MVC framework and content management system. (BSD license).
* Xyster Framework, Open source application framework with ORM package based on the data mapper pattern. Extension of Zend Framework (modified BSD license)
Python
* Django, open source
Java
* Carbonado, open source framework, backed by Berkeley DB or JDBC
* Cayenne, apache, open source for java
* Ebean, open source ORM Framework
* EclipseLink, Eclipse Persistence Platform
* Enterprise Objects Framework, Mac OS X/Java, part of Apple WebObjects
* Hibernate, open source ORM Framework, widely used
* iBATIS, maintained by ASF, and with .NET port.
* Java Data Objects (JDO)
* JPOX, open source JDO 2 reference implementation
* Kodo, commercial implementation of both the JDO and JPA API.
* OpenJPA, apache, open source, supports JPA API.
* TopLink by Oracle
* WebObjects commercial (but for free) from Apple, includes EOF as the object-relational mapping layer
.NET
* ADO.NET Entity Framework, Microsoft's ORM (released with .NET 3.5 SP1)
* Base One Foundation Component Library, free or commercial
* Business Logic Toolkit for .NET, open source
* Castle ActiveRecord, ActiveRecord for .NET, open source
* Developer Express, eXpress Persistent Objects (XPO)
* EntitySpaces, commercial
* Gentle.NET, open source
* Habanero, Free open source
* LightSpeed, Free or commercial
* Linq language integrated query
* LLBLGen, open source
* LLBLGen Pro, commercial
* NConstruct, commercial, application and code generator for NHibernate
* Neo, open source
* NHibernate, open source
* ObjectMapper .NET, GPL and commercial license
* Persistor.NET, free or commercial
* Sooda, open source; BSD license
PHP
* ADOdb Active Record, included in newer versions of the open source ADOdb. (BSD license)
* Doctrine, Open Source ORM for PHP 5.2.3, free software (GNU LGPL)
* Propel, ORM and Query-Toolkit for PHP 5, inspired by Apache Torque, free software (GNU LGPL)
* SilverStripe, free PHP5-based ORM integrated with a MVC framework and content management system. (BSD license).
* Xyster Framework, Open source application framework with ORM package based on the data mapper pattern. Extension of Zend Framework (modified BSD license)
Python
* Django, open source
Object Relational Mapping [01]
Akhirnya setelah ngeloyor sana ngeloyor sini dapet juga materi buat TA..namanya ORM kepanjangan dari Object Relational Mapping..Karena saya masih bereksperimen dalam kasus ini saya akan coba sedikit mengambil kutipan-kutipan dari sumber yang lain..
Seperti yang sudah kita kenal, model pemrograman database yang umum digunakan orang adalah model CRUD (Create-Read-Update-Delete). Untuk dapat mengoperasikan data yang ada pada database, tentunya yang pertama kali harus kita lakukan adalah men-create data (disini diasumsikan skema tabel sudah dibuat sebelumnya). Perintah yang umum kita gunakan adalah
INSERT INTO tabel_name(`kolom_name`) VALUES(’value_property’)
Setelah itu jika kita ingin menampilkan data, yang kita lakukan adalah
SELECT * FROM tabel_name
Dan ketika kita ingin mengedit salah satu data, kita harus mengetahui ID/Primary Key dari data yang akan kita edit, kemudian memasukkan nilai baru dengan peintah
UPDATE table_name SET kolom_name = ‘new_value_property’ WHERE Primary_key = ‘key_to_update’
Jika kita sudah bosan sama data tersebut dan ingin menghapusnya, maka kembali kita ambil primary-key-nya lalu menjalankan perintah
DELETE FROM tabel_name where Primary_key = ‘key_to_delete’
Apa yang salah dari konsep tersebut? Tidak ada yang salah. Tapi disini ada sebuah konsep untuk menggabungkan metode pemrograman database dengan konsep Object Oriented Programming (OOP). Pada konsep OOP, kita memodelkan elemen-elemen dari aplikasi kita menjadi objek-objek. Tidak susah kalau kita sudah mengenal database sebelumnya, karena ketika kita mendesain tabel-tabel yang ternormalisasi dalam aplikasi kita, tabel-tabel itu sudah bisa mewakili objek-objek yang ada dalam aplikasi kita. Perlu diperhatikan objek yang dibahas di sini adalah objek yang berfungsi untuk mewakili sebuah elemen (bukan objek bertipe controller atau lainnya).
Konsep ORM adalah melakukan mapping dari tabel menjadi objek. Kolom-kolom yang ada pada tabel nantinya akan menjadi variabel-variabel dalam objek tersebut. Satu objek mewakili satu row. Karena merupakan objek, untuk mengakses beberapa row sekaligus dapat disamakan dengan mengakses array dari objek.
Langsung saja ke contoh, disini saya gunakan contoh kasus blog. Untuk membuat blog sederhana, anggaplah kita perlu 2 objek: blog dan post dengan relasi one-to-many. Satu blog bisa mempunyai banyak post. Maka tabel saya adalah seperti ini:
Blog:
- name (primary key)
- owner (nama pemilik blog)Post:
- post_id (primary key, auto_number)
- blog_id (blog yang memiliki posting ini)
- tanggal (tanggal posting)
- content (isi posting blog).
Jika menggunakan metode konvensional, menggunakan konsep CRUD, yang harus saya lakukan ketika membuat blog baru adalah: Menjalankan query
INSERT INTO blog(name, owner) VALUES(’sanctuary’, ‘hendrawan’)
Kemudian saya ingin posting, sehingga yang saya lakukan adalah menjalan query
INSERT INTO post(blog_id, tanggal, content) VALUES(’sanctuary’, NOW(), ‘ini postingan pertama saya’)
Jika menggunakan ORM, maka ketika saya ingin membuat blog baru, maka yang harus saya lakukan adalah menjalankan perintah ini (di level aplikasi):
Blog myBlog = new Blog(); // nama class ini diambil dari nama tabel kita sebelumnya
myBlog.name = “sanctuary”;
myBlog.owner = “hendrawan”;
myBlog.save();
Ketika saya menjalankan perintah save(), maka ORM otomatis akan menterjemahkan objek tersebut menjadi syntax-syntax SQL dan menjalankannya di server database.
Kemudian ketika saya ingin menambahkan postingan baru, maka perintah yang saya lakukan kira-kira seperti ini (tergantung bahasa pemrograman yang digunakan, yang saya contohkan disini adalah C#):
Post newPost = new Post();
newPost.blog = myBlog; // myBlog diambil dari code sebelumnya diatas
newPost.tanggal = DateTime.Now();
newPost.content = “ini postingan pertama saya”;
newPost.Save();
Maka kita sudah mempunya objek postingan saya yang pertama yang terhubung ke objek blog bernama ’sanctuary’. Sudah terlihat bedanya? Hehe, jauh lebih mudah dipahami (terutama untuk pemula –yang sudah familiar dengan OOP tentunya) daripada coding yang penuh dengan syntax SQL sebelumnya bukan? Jika sudah pake ORM, memang sebaiknya penamaan-penamaan kolom yang merupakan relasi dirubah, sehingga OOP-nya lebih terlihat. Maksud saya adalah seperti ini:
Post:
- post_id
- blog // cukup blog saja, ndak usah blog_id,
// karena relasi ORM bukan ke primary key dari objek Blog,
// melainkan ke objek Blog secara keseluruhan
- tanggal
- content
Mungkin kalau ndak familiar dengan OOP, ndak terlalu terasa bedanya ya, tapi untuk project dengan tabel yang banyak dan mempunya banyak relasi satu sama lain, maka kita bisa lebih memanfaatkan kelebihan ORM, karena relasi antar tabel sudah di-handle oleh ORM, kita cukup mengakses tabel kita selayaknya kita mengakses sekumpulan objek-objek yang saling berhubungan.
disadur dari : http://bambangeko.wordpress.com/2007/08/27/object-relational-mapping-apa-sih-itu-bagian-pertama/
Subscribe to:
Posts (Atom)
