BAB 1
Pengenalan Arsitektur MVC
1.1 Pengenalan Arsitektur Model-View-Controller
Arsitektur Model-View-Controller adalah sebuah pola yang terbukti membangun proyek secara lebih efektif. Hal itu dilakukan dengan memilah komponen antara Model, View dan Controller pada bagian – bagian dalam proyek.
1.1.1 Motivasi
Aplikasi apapun, bagian dalam kode yang sering mengalami perubahan adalah bagian user interface.User interface adalah bagian yang paling terlihat oleh user dan bagaimana ia berinteraksi dengan aplikasi, membuatnya menjadi titik fokus pengubahan berdasar kemudahan penggunaan.
Business-logic yang rumit pada user-interface membuat pengubahan pada user interface menjadi lebih kompleks dan mudah terjadi kesalahan. Perubahan pada satu bagian memiliki potensi keterkaitan dengan keseluruhan aplikasi.
1.1.2 Solusi
Pola MVC menyediakan sebuah solosi terhadap permasalahan tersebut dengan membagi aplikasi menjadi bagian – bagian tersendiri, Model, View dan Controller, memisahkan antar bagian tersebut dan membuat tata interaksi diantaranya.
Diagram di atas menunjukkan 3 komponen yang terdapat dalam pola MVC dan interaksi yang terjadi.
1.2 MODEL
Pola MVC memiliki layer yang disebut dengan Model yang merepresentasikan data yang digunakan oleh aplikasi sebagaimana proses bisnis yang diasosiasikan terhadapnya. Dengan memilahnya sebagai bagian terpisah, seperti penampungan data, persistence, serta proses manipulasi, terpisah dari bagian lain aplikasi.
Terdapat beberapa kelebihan dalam pendekatan ini. Pertama, membuat detail dari data dan operasinya dapat ditempatkan pada area yang ditentukan (Model) dibanding tersebar dalam keseluruhan lingkup aplikasi. Hal ini memberikan keuntungan dalam proses maintenance aplikasi.
Kedua, dengan pemisahan total antara data dengan implementasi interface, komponen model dapat digunakan kembali oleh aplikasi lain yang memiliki kegunaan yang hampir sama.
1.3 VIEW
Layer ini mengandung keseluruhan detail dari implementasi user interface. Disini, komponen grafis menyediakan representasi proses internal aplikasi dan menuntun alur interaksi user terhadap aplikasi. Tidak ada layer lain yang berinteraksi dengan user, hanya View.
Penggunaan layer View memiliki beberapa kelebihan : Pertama, memudahkan pengabungan divisi desain dalam development team. Divisi desain dapat berkonsentrasi pada style, look & feel, dan sebagainya, dalam aplikasi tanpa harus memperhatikan lebih pada detail yang lain.
Dan juga, memiliki layer View yang terpisah memungkinkan ketersediaan multiple interface dalam aplikasi. Jika inti dari aplikasi terletak pada bagian lain (dalam Model), multiple interfaces dapat dibuat (Swing, Web, Console), secara keseluruhan memiliki tampilan yang berbeda namun mengeksekusi komponen Model sesuai fungsionalitas yang diharapkan.
1.4 CONTROLLER
Terakhir, arsitektur MVC memiliki layer Controller. Layer ini menyediakan detail alur program dan transisi layer, dan juga bertanggungjawab akan penampungan events yang dibuat oleh user dari View dan melakukan update terhadap komponen Model menggunakan data yang dimasukkan oleh user.
Kelebihan dalam penggunaan layer Controller secara terpisah : Pertama, dengan menggunakan komponen terpisah untuk menampung detail dari transisi layer, komponen view dapat didesain tanpa harus memperhatikan bagian lain secara berlebih. Hal ini memudahkan team pengembang multiple interface bekerja secara terpisah dari yang lain secara simultan. Interaksi antar komponen View terabstraksi dalam Controller.
Kedua, dengan menggunakan layer terpisah yang melakukan update terhadap komponen Model, detail tersebut dihapus dari layer presentasi. Layer presentasi kembali pada fungsi utamanya untuk menampilkan data kepada user. Detail tentang bagaimana data dari user mengubah ketetapan aplikasi disembunyikan oleh Controller. Hal ini memisahkan dengan jelas antara presentation logic dengan business logic.
Tidak dapat disimpulkan bahwa pola MVC hadir dengan kelebihan – kelebihan tanpa ada efek samping. Pembagian aplikasi dalam 3 bagian terpisah meningkatkan kompleksivitas. Pada aplikasi kecil yang tidak membutuhkan loose coupling pada Model, hal ini dapat menjadi blok penghalang dalam penggunaan pola ini. Bagaimanapun, yang terbaik adalah untuk meyakini bahwa sebuah aplikasi umumnya dimulai dari aplikasi sederhana, dan berkembang menjadi sistem yang kompleks., sehingga factor loose coupling harus selalu diutamakan dan diperhatikan.
1.5 Arsitektur MVC Untuk Web : Arsitektur Model 2
Arstitektur MVC secara sederhana dirancang dan diadaptasi dalam penggunaan dalam Web-Application. Arsitektur yang dihasilkan kemudian disebut dengan Model 2 Architecture.
Aplikasi Model 2 umumnya memiliki :
o Servlet Controller yang menyediakan akses tunggal terhadap keseluruhan aplikasi. Controller ini bertanggungjawab menyediakan manajemen terpusat terhadap alur aplikasi dan juga service lain seperti penganganan security dan user management.
o Controller Servlet umumnya menggunakan konfigurasi XML untuk
menentukan alur aplikasi dan pemrosesan perintah. Hal itu juga membuat helper components yang berfungsi sebagai Command objects. Hal ini berarti helper components terasosiasikan dengan user actions dan dibuat/dipanggil untuk menangani actions yang terjadi, memanggil komponen Model sebagaimana diperlukan. Hal ini berfungsi untuk memisahkan untuk memisahkan antara controller servlet dari Model.
1.5.1 Model 2 Diagram
Implementasi sebuah pola dapat dipermudah dengan menggunakan third-party framework. Frameworks tersebut menyediakan detail terkait (request, konfigurasi, dan sebagainya) sehingga kita dapat berkonsentras pada hal lain yang lebih penting. Frameworks tersebut juga menyediakan fungsi - fungsi tambahan.
Pada pembelajaran ini, akan dibatasi pada dua framework yang popular, Struts dab JavaServerFaces (JSF). Struts akan dibahas pada bagian ini, sedangkan JSF pada bagian selanjutnya.
1.5.2 STRUTS
Struts adalah open-source framework yang dibuat oleh Apache Software Foundation. Dibawah ini menunjukkan bagaimana penanganan Model 2 Architecture oleh Struts.
Perhatikan object yang disediakan oleh framework pada komponen Model, View dan Controller.
1.5.3
CONTROLLER
1.5.3.1 ActionServlet
Pusat dari implementasi controller pada Struts adalaha ActionServlet. Berfungsi sebagai Front Controller servlet dan menyediakan jalur tunggal untuk mengakses aplikasi. ActionServlet juga mengandung logic dalam penanganan request dari client – terlihat pada HTTP request dari client, kemudian diteruskan menuju sebuah halaman Web atau mengirimkan request tersebut object penerima yang disebut dengan Actions yang kemudian bertanggungjawab untuk menentukan respon yang akan dihasilkan.
ActionServlet memiliki detail – detail sebagai berikut, Action apa yang akan dipanggil untuk menangani request, komponen view mana yang akan dipanggil selanjutnya – dengan membaca konfigurasi XML, yang umunya bernama struts-config.xml.
Servlet ini menyediakan struts framework yang siap digunakan. Secara keseluruhan penting untuk menyertakannya pada aplikasi sebagai konfigurasi pada deployment aplikasi.
Berikut ini adalah potongan dari web.xml yang menunjukkan konfigurasi ActionServlet.
1.5.3.2 Action
Seperti yang telah disebutkan sebelumnya, beberapa request dari client diteruskan menuju Action yang sesuai oleh front controller servlet. Seluruh action objects mendefinisikan sebuah method yang disebut execute(), dan method inilah yang dipanggil oleh ActionServlet untuk menangani request yang terjadi.
Aktifitas umum dalam aplikasi web adalah user log-in. Ditunjukkan di bawah ini adalah implementasi dari LoginAction class yang berfungsi untuk menangani request tersebut.
Perhatikan bahwa implementasi di atas menggunakan sebuah business object yang disebut dengan UserService, untuk menentukan otentifikasi user dan tidak menyediakan implementasi secara langsung pada method eksekusinya. Action
instances harus dibuat dengan alur sebagai berikut – fungsi utama harus di teruskan kembali pada business object (yang dapat ditemukan pada bagian Model), tidak diimplementasikan dalam Action itu sendiri. Proses yang akan dijalankan pada Action adalah sebagai berikut :
o Menampung informasi user dari ActionForm bean terkait
o Menerjemahkan data dari form menjadi parameter yang diperlukan oleh business object yang mengimplementasikan fungsionalitasnya
o Menampung hasil operasi dari business object dan menentukan View selanjutnya yang akan ditampilkan pada user
Pengenalan MVC 7
import org.apache.struts.action.*
public class LoginAction extends Action {
public ActionForward execute(ActionMapping mapping,
// Membuat business object yang akan menangani request UserService service = new UserService();
user = service.login(loginName, password);
// Jika user tidak ada, diteruskan pada error page if (user == null) {
return mapping.findForward("failure"); }
// Simpan pada session untuk digunakan pada proses aplikasi selanjutnya HttpSession session = request.getSession();
session.setAttribute(ApplicationConstants.USER_OBJECT, user);
// User telah log-in dengan sukses. return mapping.findForward("success"); }
o Secara opsional, menyimpan data hasil dari operasi bisnis ke dalam session atau request objects untuk digunakan dalam proses aplikasi selanjutnya
Hal lain yang perlu diperhatikan pada saat membuat kode instances dari Action objects adalah bahwa framework hanya akan menginstansiasi satu salinan object dan menggunakannya untuk memfasilitasi seluruh request. Hal ini berarti kita harus selalu membuat kode Action dalam thread-safe, dan memastikan bahwa hanya local variabel yang digunakan, bukan instance variabel.
Action instances berkemampuan untuk menginstruksikan ActionServlet dalam memilih komponen View mana yang akan digunakan dalam merespon dengan mengembalikan instances dari objek ActionForward. Actions memiliki akses
terhadap ActionForward melalui penggunaan ActionMapping yang
mengenkapsulasi data dari pemetaan logical path pada setiap Action. Pemetaan tersebut dibaca dari file konfigurasi oleh ActionServlet, yang kemudian bertanggungjawab untuk meneruskan ActionMapping pada Action yang sesuai. Sehingga menginstruksikan ActionServlet untuk meneruskan pada logical map dengan hasil “Success”, Action bekerja sesuai pernyataan berikut :
return mapping.findForward("success");
1.5.3.3 ActionForm
Struts framework menyediakan sebuah class yang disebut dengan ActionForm. Instances dari class ini digunakan untuk memfasilitasi penampungan data yang berasal dari form yang dikumpulkan dari user pada Action instances yang menangani events pada form tersebut.
Tiap instances dari ActionForm merepresentasikan sebuah form atau rangkaian forms. Instances tersebut mendefinisikan properties dari elemen – elemen form, dan mempublikasikannya dengan menggunakan getters dan setters yang dapat diakses secara public. Action yang memerlukan data dari form kemudian memanggil method getter dari instance ActionForm.
Struts menyertakan definisi class dasar; developer bertanggungjawab penuh atas implementasi buatan mereka sendiri.
Kode dibawah menunjukkan ActionForm yang digunakan pada contoh sebelumnya :
Beberapa hal yang perlu diingat pada saat pengkodean ActionForm :
o Mendefinisikan properties (dengan asosiasi terhadap method get dan set) untuk tiap elemen yang akan direpresentasikan pada form
o Hindari penempatan business logic pada ActionForm. ActionForm ditujukan untuk mentransfer data antara komponen View dan Controller, dan bukan ditujukan untuk business logic.
o Opsi lain, sertakan sebuah method untuk memvalidasi data sebelum diteruskan pada Action. Validasi akan dibahas lebih mendalam selanjutnya.
1.5.3.4 struts-config.xml
File ini berfungsi sebagai file konfigurasi komponen – komponen yang terdapat pada Struts. Disini, kita dapat mendefinisikan Action mana yang akan dipanggil untuk tiap request, form mana yang akan digunakan pada tiap Action, dan memetakan logical names pada actual path, diantara hal – hal lain. Berikut ini adalah potongan dari struts-config.xml yang digunakan pada contoh di atas :
Pengenalan MVC 9
import org.apache.struts.action.*;
public class LoginForm extends ActionForm { private String loginName;
“http://jakarta.apache.org/struts/dtds/struts-Mari kita bahas tiap elemen tersebut.
<!DOCTYPE ...>
Elemen ini mendefinisikan file XML sebagai file konfigurasi dalam penggunaan Struts framework. Terlewat dan kesalahan dalam penulisan kode, akan menghasilkan error pada saat aplikasi dijalankan.
<struts-config>
Elemen dasar dalam file konfigurasi. Seluruh elemen lain adalah elemen turunan dari elemen ini.
<form-beans>
Elemen ini menandai awal dan akhir definisi dari ActionForm instances. Elemen <form-bean> harus diposisikan sebagai turunan dari elemen ini.
<form-bean>
Menjelaskan instance dari ActionForm yang dapat digunakan oleh aplikasi. Elemen ini memiliki dua atribut :
o
name – nama logik yang akan diasosiasikan dengan ActionForm classo
type – desripsi kualifikasi lengkap nama class dari ActionForm class<action-mappings>
Elemen ini menandai awal dan akhir definisi Action dan pemetaannya. Seluruh elemen <action> harus diposisikan sebagai titik turunan dari elemen ini.
<action>
Menjelaskan instance dari Action object yang akan digunakan oleh aplikasi. Secara umum, elemen action akan mengimplementasikan atribut - atribut sebagai berikut :
o
path – context relative path yang digunakan oleh Action. Request apapun pada path ini menghasilkan Action dipanggilo
type – deskripsi lengkap nama class dari Action classo
name – nama elemen <form-bean> yang akan digunakan oleh Actiono
scope – lingkup dimana ActionForm yang dapat diakses. Hal ini mengatur dimana ActionServlet akan menyimpan instance dari ActionForm<forward>
Elemen ini mendefinisikan pemetaan logik antara sebuah name dan path pada aplikasi.
Elemen ini memiliki atribut sebagai berikut :
o
name – nama dari elemen forward yang akan digunakan oleh Action instanceo
path – path dari komponen View yang akan diasosiasikan pada forwardHal – hal yang perlu dilakukan pada Controller layer : Untuk sekali pengaturan :
o
Mengkonfigurasi ActionServlet pada deployment aplikasiUntuk tiap form handler yang akan ditambahkan pada aplikasi :
o
Membuat object ActionForm yang akan menrepresentasikan seluruh data yang dikumpulkan dari formo
Membuat object Action dimana pada method eksekusinya menjelaskan bagaimana form akan ditanganio
Mengkonfigurasi object ActionForm dalam struts-config.xml, pada bagian <form-beans>o
Mengkonfigurasi object Action dalam struts-config.xml, pada bagian <action-mappings>o
Mengkonfigurasi seluruh elemen forward yang akan digunakan oleh Action, dengan menempatkan <forward> pada badan definisi <action>1.5.4 MODEL
Struts framework secara eksplisit tidak menyediakan komponen apapun dalam elemen Model. Object mana yang akan digunakan sebagai komponen Model ditentukan sepenuhnya oleh developer, umumnya adalah JavaBeans, atau terkadang EJB.
1.5.5 VIEW
Struts dapat menggunakan teknologi presentation layer apapun, walaupun pada sebagian kasus yang presentation layer yang digunakan adalah JSP dan HTML. Apa saja yang disediakan oleh Struts, adalah serangkaian dari tag libraries yang mengijinkan penggunaan fitur – fitur dari Struts dalam pengumpulan dan validasi form secara otomatis.
1.5.5.1 struts-html
Struts menyertakan sebuah tag-library, disebut dengan struts-html, yang hampir menyerupai keseluruhan fungsionalitas standar HTML, namun ditambahkan dengan beberapa fitur tambahan.
Tag-library ini sering digunakan pada saat membuat form yang akan dipakai oleh aplikasi. Perhatikan contoh dibawah ini :
Ini adalah form yang digunakan pada contoh sebelumnya. Perhatikan bagaimana elemen standar HTML seperti <form>, <input type=“text“>, <input type=“password“>, serta <input type=”submit”> digantikan oleh tag dari library struts-html. Mari kita bahas tags tersebut satu-persatu :
<html:form>
Tag <html:form> menerjemahkan sebuah HTML form. Tiap form tag terasosiasi dengan sebuah action mapping yang didefinisikan oleh atribut action. Value dalam atribut action menspesifikasikan path dari action mapping yang sesuai.
Perhatikan kembali file konfigurasi pada contoh sebelumnya :
Pengenalan MVC 12
Dapat kita lihat bahwa value dari atribut path terdefinisi pada file konfigurasi sesuai dengan value atribut action pada tag <html:form>. Hal ini mengindikasikan bahwa dalam form ini, saat diserahkan, akan diteruskan pada LoginAction untuk ditangani.
Salah satu dari persyaratan dari tag html:form yang valid adalah tiap field yang
Tag ini menerjemahkan standar HTML text input field. Property attribute menentukan batasan property dalam ActionForm terkait. Sebagai contoh, value dari property attribute dari contoh di atas adalah “loginName”, text field ini terhubung dengan property loginName pada LoginForm.
Atribut lain yang tersedia pada tag ini :
o
size – mendefinisikan ukuran dari text field yang akan ditampilkano
maxlength – menentukan panjang maksimum value yang dapat dimasukkan oleh user<html:password>
Tag ini menerjemahkan standard HTML password field. Property attribute dari tag ini menjelaskan batasan property dalam ActionForm yang berkaitan. Dalam contoh diatas, field ini dibatasi oleh password property pada LoginForm.
Pada pembahasan sebelumnya tentang html:text dan html:password field, dijelaskan bahwa tag – tag tersebut dibatasi oleh properties pada ActionForm yang terhubung dengan form. Hal ini menjelaskan bahwa pada prakteknya value yang dimasukkan oleh user dalam field ini secara otomatis akan diatur sesuai batasan properties dalam object ActionForm. Terlebih lagi, jika terdapat value sebelumnya dalam ActionForm object (form tersebut telah diakses sebelumnya), field pada form secara otomatis pula akan terisi dengan values dari ActionForm object.
Tag-tag lain yang terdapat pada struts-html tag library :
<html:hidden>
Menerjemahkan HTML hidden pada form field.
Contoh penggunaan :
Pengenalan MVC 13
<html:radio>
Menerjemahkan HTML radio check box.
Contoh penggunaan :
<html:select>, <html:option>
html:select digunakan untuk menerjemahkan sebuah drop-down list box. Pilihan – pilihan yang terdapat pada list box didefinisikan menggunakan tag html:option.
Contoh penggunaan :
Contoh di atas akan membuat sebuah list box dengan 5 item berukuran 5. Perhatikan bahwa body dari html:option tag berperan sebagai label dari item pada list, sedangkan value dari value attribute menentukan value yang akan diberikan pada Action.
<html:checkbox>, <html:area>
Digunakan untuk menerjemahkan check box field dan textarea.
Seperti yang terlihat pada pembahasan sebelumnya (Advanced JSP), terdapat beberapa hal yang perlu dilakukan sebelum memakai bermacam tag libraries dalam aplikasi.
Pertama, letakkan file JAR implementasi dari fungsionalitas tag dalam direktori WEB -INF/lib dalam aplikasi.
Beberapa hal yang harus dilakukan terhadap layer View : Untuk satu kali pengaturan :
o
Konfigurasi tag library yang akan digunakan dalam pengembangan aplikasio
Tempatkan file JAR yang memiliki implementasi tag libraries pada direktoriWEB-INF/lib dalam aplikasi
Untuk setiap form yang akan dibuat :
-o
Pada peletakan standar <form> tag, gunakan <html:form>, tentukan dalam action attribute dari path Action yang akan menangani formo
Pada posisi peletakan HTML field tags (<input type=”text”>, dan sebagainya), gunakan tags yang terdapat pada struts-html tag library yang memiliki fungsi yang sama (<html:text>, dan sebagainya).
Pastikan bahwa seluruh input fields yang terdapat pada form terdefinisi sebagai properties pada ActionForm object yang terhubung dengan request. Tidaklah perlu bahwa seluruh properties pada object ditampilkan sebagai field, namun dipersyaratkan bahwa seluruh fields juga terdefinisi sebagai properties.
Menutup tag <html:form>1.6 MEMANDANG HAL-HAL YANG ADA SECARA KESELURUHAN
Untuk memahami bagaimana Struts framework berfungsi secara menyeluruh, perhatikan scenario yang terdapat pada contoh diatas : user logging.
Sebelum seorang user memasuki situs, ActionServlet mengambil konfigurasi file dan menelusuri detail yang ada. Sehingga, pada saat user mengakses form login, framework telah mengetahui ActionForm terkait yang akan menyimpan detail dan Action yang akan menanganinya.
Saat halaman login dijalankan, struts html tags yang telah digunakan berupaya untuk menerjemahkan HTML fields. Jika ActionForm untuk form ini tidak ada, halaman tersebut tidak akan ditampilkan. Jika terdapat fields dalam form yang melebihi properties pada ActionForm untuk menopangnya, halaman tersebut juga tidak akan ditampilkan. Jika ActionForm tersebut memang telah terdefinisi sebelumnya, tags – tags yang ada akan ditampilkan jika terdapat values sebelumnya yang tersimpan dalam ActionForm, dan juga form fields akan ditampilkan beserta data yang ada. Sebaliknya, form fields akan dibiarkan kosong dan user akan memperoleh tampilan form tanpa isian.
Pada saat form diserahkan, values pada form fields secara otomatis diatur ke dalam object ActionForm oleh Struts Framework. Object ini kemudian diteruskan menuju Action handler yang sesuai, selama ActionMapping object yang merefleksikan detail pemetaan tercantum pada file konfigurasi.
Action object memerankan penanganannya, kemudian memberi tahu ActionServlet kemana langkah selanjutnya dengan menentukan salah satu elemen forward yang terkonfigurasi pada pemetaan/mapping. ActionServlet kemudian meneruskan user menuju halaman yang ditentukan.
BAB 2
Advanced MVC
2.1 Pendahuluan
Pada pembahasan sebelumnya, kita telah memahami garis besar dasar dari Struts. Kita telah mempelajari bagaimana cara mengimplementasikan framework Struts pada aplikasi dengan mengkonfigurasi ActionServlet yang disediakan untuk menangani request. Kita juga telah mempelajari cara untuk membuat instance dari Action classes yang berfungsi sebagai action handlers pada penyerahan form dan user request yang lain. Telah diketahui cara pembuatan ActionForm classes yang menyediakan cara mudah transfer data dari form menuju ActionHandlers yang dibuat. Terakhir, telah diketahui pula mengenai penggunaan tag library untuk menggabungkan form HTML dalam halaman JSP pada framework.
Pada bab ini, kita akan membahas beberapa teknik dan fitur terapan dari Struts framework. Pertama, akan kita pelajari mengenai penggunaan DynaActionForms untuk mengurangi jumlah class yang kita gunakan dalam framework. Kemudian, akan kita telusuri bagaimana framework validator berfungsi dalam hal validasi baik pada server-side maupun client-side. Terakhir, akan dikenalkan Tiles framework, yang memiliki fitur presentationlayer yang lebih kompleks, sehingga dapat membuat templating machine terhadap halaman – halaman yang ada pada aplikasi.
2.2 DynaActionForms
Pada aplikasi skala besar utamanya, jumlah class yang perlu untuk dibuat dan dipergunakan dapat begitu tinggi. Struts mendukung classes yang cukup membantu hal ini, terutama dalam hubungannya dengan ActionForms, yang mempersyaratkan solidnya implementasi form keseluruhan pada aplikasi. Banyak dari developer yang terjebak pada batasan ini, utamanya pada saat ActionForms adalah berupa JavaBeans sederhana yang memiliki method get dan set pada tiap form fields pada representasinya.
Strus memiliki penyelesaian atas permasalahan tersebut pada versi 1.1, disebut dengan DynaActionForms. DynaActionForms sangat mirip dengan ActionForms, sehingga sebuah instance darinya dapat diambil dan method dipanggil pada saat ActionHandlers memerlukan data yang ada. Perbedaan utamanya adalah, tiap DynaActionForm tidak terdeklarasi sebagai class terpisah, melainkan terkonfigurasi dalam struts-config.xml.
Dibawah ini adalah contoh konfigurasi dan deklarasi DynaActionForms. Kita gunakan sesuai contoh pada bab sebelumnya, disini dibuat sebuah ActionForm yang akan menangani data yang dibutuhkan pada saat log in.
Seperti yang terlihat, pembuatan DynaActionForm berlangsung dengan amat sederhana, dan pada beberapa kasus, deklarasi DynaActionForm dalam file konfigurasi lebih sederhana dan cepat dibandingkan dengan menuliskan instance ActionForm secara langsung. Kita tidak perlu memperhatikan form properties serta membuat method get dan set pada setiap ActionForm, dengan menggunakan DynaActionForm hanya memerlukan deklarasi property name dan type.
Berikut ini adalah Java types yang didukung oleh DynaActionForm : o java.lang.bigDecimal
“http://jakarta.apache.org/struts/dtds/struts-Validasi input sangat dibutuhkan dalam aplikasi berbasis web. Dengan menggunakan validasi input, didapatkan koreksi atas format dan isi dari input yang diberikan user. Dalam banyak kasus, seorang user tidak selalu memasukkan input yang benar, huruf dapat dimasukkan dalam field numerik dan sebaliknya; sebuah field yang mempersyaratkan minimal 3 digit hanya diisikan dengan2 digit, dan sebagainya. Adalah tanggung jawab dari aplikasi untuk waspada dan menangani kesalahan input disamping kesalahan hasil dari proses business logic (password tidak cocok dan sebagainya).
Struts meringankan kesulitan yang dihadapi developer dalam menjalankan validasi dengan menyediakan validasi framework yang disebut dengan Validator Framework. Penggunaan framework ini memiliki beberapa kelebihan :
o Framework menyediakan beberapa aturan validasi. Terdapat beberapa rangkaian pemeriksaan umum pada aplikasi seperti pemeriksaan format, panjang karakter dan sebagainya. Framework ini menyediakan komponen – komponen yang dibutuhkan sehingga developer tidak lagi membuat kode yang akan melakukan proses validasi. Komponen yang disediakan umumnya cukup mewakili proses validasi global, namun proses validasi lain juga dapat dibuat.
o Mengurangi redudansi kode. Framewok memisahkan komponen yang melakukan validasi dengan komponen yang memerlukan validasi. Hal ini juga membuat developer dalam penggunaan ulang kode dengan lebih mudah : komponen yang memerlukan validasi cukup mendeklarasikan jenis validasi yang diinginkan disamping menambahkan kode validasi pada komponen tersebut.
o Satu titik maintenance. Developer tidak lagi menelusuri aplikasi secara menyeluruh untuk memeriksa aturan validasi yang terdapat pada bermacam komponen. Seluruh aturan dideklarasikan pada file konfigurasi yang diberikan oleh framework.
Terdapat beberapa langkah yang dibutuhkan dalam menambahkan fungsi – fungsi validator dalam aplikasi Struts :
o Konfigurasi Validator Plug-in
o Deklarasi form yang memerlukan validasi, dan tipe validasi yang dibutuhkan o Membuat pesan yang akan ditampilkan jika proses validasi mengalami
kegagalan
o Merubah base class dari ActionForms menjadi ValidatorForm pada aplikasi. Dan juga merubah tipe dari DynaActionForms menjadi DynaValidatorForm
2.3.1 Konfigurasi Validator Plug-in
Langkah ini diperlukan untuk membuat Struts framework mengetahui penggunaan Validator framework. Hal yang perlu dilakukan adalah menambahkan beberapa baris kode dalam struts-config.xml. Berikut ini contohnya :
Path names property menginformasikan pada framework dimana letak untuk menemukan file konfigurasi yang diperlukan. Terdapat beberapa file konfigurasi : validator-rules.xml dan validator.xml.
2.3.2 validator-rules.xml lebih dari min variable yang diberikan
o maxlength – property tersebut harus memiliki panjang yang sama atau kurang dari max variable yang diberikan
o range – property memiliki panjang dalam area antara max dan min value yang diberikan
o byte, short, integer, long, float, double – property harus sesuai dengan tipe primitive yang diberikan
File konfigurasi ini menginformasikan pada framework form apa saja yang membutuhkan validasi dan aturan validasi apa yang akan diimplementasikan. Framework ini hanya menyediakan struktur dari file. Developer harus mengkonfigurasi sendiri file ini untuk membantu fungsionalitas framework.
2.3.3.1 Menkonfigurasi file validation.xml
Sekali lagi, kita akan mempelajari elemen yang dibutuhkan oleh file konfigurasi pada contoh. Dibawah ini adalah potongan yang akan terlihat dari file jika kita akan mengkonfigurasi form login terlebih dahulu.
Berikut adalah macam elemen yang terdapat pada file XML ini.
<formset>
Elemen ini berfungsi sebagai container untuk elemen – elemen pada form
<form>
Setiap form dalam aplikasi yang memerlukan proses validasi harus memiliki <form> elemen yang berhubungan. Atribut name pada hal ini harus sesuai dengan name dari form-bean yang dikonfigurasi pada struts-config.xml. Elemen ini dapat mengandung satu atau lebih elemen <field>.
<field>
Tiap elemen field merepresentasikan sebuah property pada form yang memerlukan validasi. Elemen ini memiliki atribut – atribut sebagai berikut :
o property – nama dari property dalam form yang akan divalidasi
Mendefinisikan key pada error message yang akan ditampilkan jika property gagal dalam proses validasi. Key dan error message yang akan ditampilkan dapat ditemukan pada resource bundle yang dibuat oleh developer.
<var>
Tiap elemen var mendefinisikan sebuah variabel dengan value masing – masing yang akan diteruskan menuju validator. Nama dari variabel didefinisikan dengan elemen turunan <var-name>, sedangkan isi value-nya didefinisikan menggunakan elemen turunan <var-value>.
Telah dijelaskan di atas informasi – informasi tentang bermacam elemen pada file konfigurasi, dapat dikatakan bahwa contoh tersebut mengkonfigurasi form login aplikasi Struts sehingga loginName dan password field harus memiliki value yang dimasukkan. Sebagai tambahan, password field harus memiliki panjang minimal 4 karakter untuk melewati proses validasi.
2.3.3.2 Mendefinisikan resource bundle
Elemen <arg0> di atas mendefinisikan sebuah key yang perlu dicocokkan dengan sebuah entry pada resource bundle. Entry tersebut kemudian digunakan untuk menentukan pesan yang akan ditampilkan pada user. Validator framework menggunakan resource bundle yang juga digunakan oleh Struts framework, dimana pada kondisi default, dapat ditemukan pada direktori WEB-INF/classes dengan nama ApplicationResources.properties. Jika file resource bundle tersebut tidak ditemukan pada aplikasi, maka buatlah sebuah text file dengan nama yang sama.
Entry pada resource bundle adalah pasangan sederhana berupa key=value. Pada konfigurasi file diatas, kita dapatkan isi file sebagai berikut :
Langkah terakhir dalam menggunakan validation framework adalah mengubah ActionForm dan DynaActionForm classes untuk memakai classes yang disediakan. Gunakan DynaActionForm pada contoh sebelumnya :
Advanced MVC 6
error.loginname.required=Masukkan nama anda
error.password.required=Anda belum mengisi password atau password kurang dari 4 karakter
<?xml version=”1.0”?>
2.4
Tiles
Framework lain yang bekerja dengan Struts adalah Tiles framework. Dengan menggunakan Tiles, kita dapat mendefinisikan templates dan screen instances yang dapat digunakan dalam aplikasi dengan mudah.
Apakah templates itu?
Secara ringkas, sebuah halaman template adalah desain layout halaman yang dapat digunakan kembali oleh halaman apapun pada aplikasi. Penggunaan templates membuat aplikasi terlihat lebih konsisten.
Untuk lebih memahami konsep templates, mari kita perhatikan beberapa halaman dari aplikasi web :
HALAMAN DARI SITUS TERPERCAYA
Seperti terlihat pada halaman – halaman tersebut, terdapat beberapa elemen desain yang dipakai. Secara keseluruhan menggunakan rangkaian navigational links yang sama pada bagian kiri dan rangkaian gambar pada bagian atas, serta bagian yang berubah antara halaman yang berbeda adalah bagian tengah halaman.
Pertimbangkan bagaimana cara kita untuk mengimplementasikan beberapa halaman yang sama. Jika kita implementasikan pada setiap halaman seperti yang terlihat, dalam hal ini tepat satu halaman yang berhubungan dengan halaman-halaman yang terlihat pada gambar, pada nantinya kita akan mengalami kesulitan pada saat melakukan proses maintenance. Hal itu dikarenakan oleh banyaknya duplikasi kode yang akan digunakan, jika pada suatu saat seseorang memutuskan bahwa gambar pada halaman tidak terlihat bagus, ataupun navigational menu pada bagian kiri tidak terlalu menarik, perubahan akan dilakukan terhadap seluruh halaman yang ada.
Seorang programmer mengetahui bahwa pembagian area kode dapat diduplikasikan pada seluruh halaman aplikasi. Konsep ini juga dapat diterapkan pada halaman JSP/HTML : navigational links dapat berupa satu halaman tersendiri, header images sebagai halaman lain, begitu pula dengan footer. Halaman – halaman ini kemudian dapat digunakan pada halaman dengan isi body. Hal ini dapat dilakukan tanpa menggunakan framework apapun, cukup menggunakan <jsp:include> action yang telah dibahas sebelumnya pada bagian dasar JSP.
Terdapat penyelesaian yang lebih baik, yaitu dengan membuat bagian body sebagai halaman bagian JSP tersendiri, kemudian membuat sebuah halaman JSP lain yang akan berfungsi sebagai default format dan layout dari halaman halaman yang ada. Seorang developer kemudian akan mengimplementasikannya dengan cara memasukkan halaman yang berisi body content dalam template tersebut.
Terlihat jelas kelebihan dari cara diatas : segala keperluan perubahan hanya akan dilakukan pada satu aspek pada presentation layer, sebagai contoh header, akan diterapkan pada seluruh halaman aplikasi hanya dengan memodifikasi satu halaman. Jika anda ingin mengganti layout dari aplikasi, disamping mengerjakan content dari aplikasi, cukup dilakukan dengan mengubah halaman template yang digunakan
2. Langkah berikutnya, salin file struts-tiles.tld dan tiles-config.dtd dari direktori library Struts menuju direktori /WEB-INF. File pertama berisi macam – macam tags yang dibutuhkan dalam penggunaan Tiles, sedangkan file kedua berisi struktur file konfigurasi dari tiles-defs.
3. Buat sebuah file konfigurasi kosong yang akan diisi kemudian. Buat sebuah file XML pada direktori /WEB-INF. kemudian beri nama dengan tiles-defs.xml. Isi file tersebut dengan kode sebagai berikut :
Jika langkah – langkah tersebut telah dijalankan seluruhnya, maka Tiles Framework siap digunakan.
2.4.2 Membuat Layout Template
Langkah pertama dalam pembuatan sebuah template adalah mengidentifikasi komponen yang akan ditempatkan. Sebagai contoh, sebagai besar halaman web memiliki komponen header, footer, menu bar dan body.
Berikut ini rancang diagram dasar template yang akan dibuat :
Header
Menu
Bar
Body
Footer
Untuk membuat sebuah halaman template yang menerapkan layout tersebut, ikuti langkah – langkah berikut ini :
1. Buat sebuah halaman JSP baru 2. Import tag library dari Tiles
3. Buat file HTML yang menerapkan layout tersebut, biarkan kosong pada bagian elemen yang digunakan
4. Gunakan tag <tiles:insert> yang berfungsi sebagai penentu letak dari komponen layout
Halaman HTML yang menerapkan layout tersebut memiliki bentuk sesederhana tabel, dengan komponen sebagai elemen tabel seperti terlihat pada halaman JSP di bawah ini :
<TD colspan="2"><tiles:insert attribute="header"/></TD> </TR>
<TR>
<TD width="140" valign="top">
<tiles:insert attribute="menu"/>
</TD>
<TD valign="top" align="left">
<tiles:insert attribute="body"/>
</TD> </TR>
<TR>
<TD colspan="2">
<tiles:insert attribute="footer" />
</TD> </TR>
Terdapat dua macam tag pada contoh yang diberikan diatas : <tiles:insert> dan <tiles:getAsString>.
o <tiles:insert> - tag ini cukup sering digunakan pada Tiles Framework. Dalam hal ini berfungsi untuk memasukkan bagian JSP yang direferensikan dengan nama yang terisi pada atributattribute.
o <tiles:getAsString> - tag ini berfungsi menampung value yang diisikan pada komponen dengan atribut namesebagai String.
2.4.3 Membuat Screen Definitions
Setelah memuat sebuah template, kita dapat menggunakannya untuk mendefinisikan sebuah screen. Pembuatan screen definition dapat dilakukan dalam dua cara dalam Tiles framework : didefinisikan dalam halaman JSP, atau dalam file XML yang dikenali oleh framework.
Membuat sebuah definition menggunakan halaman JSP:
Pembuatan definition dalam halaman JSP menerapkan banyak macam tag yang disertakan oleh Tiles Framework :
o <tiles:definition> - tag dasar yang digunakan untuk mendefinisikan layer. Value dari attribute id adalah nama yang terhubung dengan komponen lain. Value dari page attribute adalah lokasi dimana template file tersebut berasal.
o <tiles:put> - tag ini digunakan untuk menempatkan sebuah value ke dalam sebuah attribute dalam template. Name attribute adalah nama dari lokasi target dalam template, sedangkan value mendefinisikan lokasi dari fragmen JSP yang akan digunakan.
Perhatikan contoh dibawah ini :
Pada contoh tersebut, kita membuat sebuah screen definition untuk halaman utama, yaitu halaman muka aplikasi. Halaman tersebut menggunakan layout yang didefinisikan pada daftar, dan menempatkan komponen title, header, footer, menu dan body pada lokasi yang ditentukan pada template.
Secara default, definition ini hanya terlihat pada halaman JSP yang memiliki deklarasi definition terkait. Untuk mengubahnya, kita dapat menambahkan sebuah value kedalam atribut opsional scope pada tag <tiles:definition>. Values pada atribut tersebut mencakup : page, request, session dan application.
2.4.4 Membuat definition menggunakan konfigurasi file XML
Cara kedua untuk membuat screen definitions adalah mencantumkan konfigurasi pada file tiles-defs.xml. Syntax penulisan konfigurasi tersebut sangat mirip dengan tag <tiles:definition> yang digunakan sebelumnya :
Apakah perbedaan antara dua cara tersebut? Kedua cara menyimpan definition
"-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd">
membuatnya terlihat hanya pada halaman yang sama. Kondisi ini membuat penggunaan ulang dari screen definition pada aplikasi sedikit lebih sulit, dibutuhkan perhatian ekstra untuk menghindari loading dan loading definition yang tidak penting terhadap memory. framework. Hal ini dapat mengurangi secara drastic halaman JSP yang dibutuhkan oleh aplikasi. Menggunakan definition sebagai ActionForwards merupakan pokok pembahasan yang akan dibahas lebih detail selanjutnya.
2.4.5 Menggunakan Screen Definitions
Membuat sebuah screen definition belum cukup untuk ditampilkan pada user. Supaya sebuah definition dapat dipakai, gunakan tag <tiles:insert> dan isikan nama definition yang akan ditampilkan :
Salah satu permasalahan dengan pendekatan ini adalah meningkatkan jumlah halaman JSP yang dibutuhkan untuk menampilkan layer yang berbeda pada user, disamping komponen body content, tiap screen membutuhkan halaman terpisah yang akan menggunakan screen definition. Untuk sebuah aplikasi yang membutuhkan 100 screen atau lebih, jumlah halaman yang dibutuhkan akan berlipat ganda.
Disini kita melakukan modifikasi atas contoh dari struts-config.xml sebelumnya, sehingga pada situasi dengan kondisi success dipetakan pada definition
welcomePage. Seperti yang terlihat, pendekatan ini cukup sederhana, mudah digunakan, dan mengurangi jumlah halaman JSP yang harus dibuat.
2.4.6 Menambahkan Definitions
Salah satu kekuatan dari Tiles framework dari templating method lain adalah mengijinkan extensions pada screen definitions. Screen extensions bekerja dengan cara yang sama dengan inheritance class pada Java : extended screen menurunkan seluruh properties dan attributes dari parent Definition. Hal ini mengijinkan kita untuk membuat sebuah definition dasar yang mendeklarasikan values untuk attribut yang diextend oleh definitions terutama pada halaman – halaman tertentu.
Perhatikan contoh dibawah ini :
Dengan pembuatan sebuah base screen yang kemudian dapat di extend, kita menghindari penulisan ulang pada definisi value attribute. Dan juga, jika diperlukan perubahan dalam sebuah komponen yang terdapat pada base attributes, perubahan tersebut dapat dengan cepat diterapkan pada seluruh screen secara otomatis dengn memodifikasi base screen definitions.
Advanced MVC 1
<definition name="basicDefinition" page="/layout/basicLayout.jsp"> <put name="header" value="/header.jsp"/>
<put name="footer" value="/footer.jsp"/> <put name="menu" value="/menu.jsp"/> </definition>
<definition name="welcomePage" extends="basicDefinition"> <put name="title" value="Welcome!"/>
<put name="body" value="/welcome.jsp"/> </definition>
<definition name="otherPage" extends="basicDefinition"> <put name="title" value="My title"/>
Bab 3
Pengembangan Aplikasi Java dengan MVC
3.1 Tujuan
Dalam bab ini, kita akan mendiskusikan bagaimana perkembangan dari teknologi Java Enterprise Edition dan juga bagaimana kemudian teknologi ini dengan dukungan dari komunitas open source-nya menciptakan turunan-turunan baru yang tidak distandarisasi oleh Sun Microsystem, yang kemudian menciptakan elemen-elemen yang mendukung Model View Controller pattern yang telah dikembangkan sebelum Java sendiri lahir.
Pada akhir bab ini, pelajar diharapkan dapat mengetahui : Sejarah perkembangan dari Java EE
Politik dalam perkembangan MVC
Elemen-elemen dari turunan Java EE yang menjadi bagian-bagian utama dalam MVC Perkembangan MVC sebagai solusi web menuju WARS dan implementasi AJAX Perkembangan AJAX dan dukungan MVC terhadap AJAX
3.2 Sejarah Singkat Perkembangan Java EE
Java memang tidak lepas dari kata Sun, sang penciptanya. Berkat Sun pula dan diikuti dengan gelombang Free Software paling hot abad ini yaitu Linux, telah membuat Java yang merupakan teknologi hot abad ini didunia pemograman bertransformasi secara sangat cepat.
Java yang semula diciptakan untuk membuat aplikasi yang berjalan di browser, tetapi karena performancenya sangat jelek, telah berevolusi menjadi sebuah solusi untuk server. Dimana bundle semua teknologi berbasis Java ini lebih sering disebut J2EE, singkatan dari Java 2 Enterprise Edition. Resmi tahun 2005, Sun mengganti kata J2EE menjadi Java EE, karena tidak lah bagus Java terus menerus versi 2 setelah lebih dari satu dekade menyandang kata itu. Padahal sebenarnya saat ini Java telah memasuki versi 5.0, sehingga bundle Java untuk solusi yang lebih komplek juga berganti nama menjadi Java EE 5.0
Implementasi Java EE ini ternyata sangat beragam, karena didalam spesifikasi Java EE terdapat banyak sekali teknologi yang siap pakai seperti servlet, JSP, JSF, EJB, JMS atau JCA. Karena Java EE adalah merek dagang dari Sun Microsystems, sehingga untuk informasi lebih lanjut
mengenai Java EE, dapat mengunjungi websitenya di http://java.sun.com.
Implementasi dilapangan Java EE memerlukan container atau middleware, sehingga setiap objek-objek yang dikembangkan dapat dijalankan didalam container tersebut, termasuk juga pengelolaan objek dilakukan oleh container tersebut. Beberapa implementasi container Java EE adalah JBoss, Jonas, Weblogic, Websphere atau Glassfish. Umumnya Java EE yang disebutkan adalah full stack Java EE container.
Ternyata banyak sekali kebutuhan yang tidak memerlukan fitur-fitur Java EE yang sangat banyak tersebut, yang mana umumnya memerlukan hanya fitur yang berhubungan dengan Web, teknologi Java EE yang hanya berurusan dengan Web ini disebut servlet, singkatan dari server applet. Sebuah container Java EE yang hanya berisikan servlet ini disebut servlet container, implementasi dilapangannya adalah Tomcat dari Apache, Jetty, Resin dari Caucho, atau yang commercial Websphere Express, JRun dari Adobe. Geronimo dari Apache atau JBoss AS menggunakan Tomcat sebagai servlet containernya. Sehingga, setiap aplikasi yang
dikembangkan di atas Tomcat, umumnya dapat berjalan tanpa modifikasi bilamana dideploy di Geronimo atau JBoss AS.
Turunan teknologi servlet ini ada bermacam-macam, tetapi yang distandarisasikan adalah JSP dan JSF. Sedangkan yang dibahas pada modul ini yaitu turunan dari teknologi servlet ini yang tidak distandarisasi di JCP, dimana pengembangan teknologi non JCP ini juga sedemikian pesatnya. Teknologi turunan ini akan dibahas lebih detail dalam modul ini, karena teknologi tersebut, telah bertransformasi dari sekedar teknologi untuk web menjadi teknologi code generator, yang artinya kode yang kita kembangkan akan menghasilkan kode baru baru lagi, atau dengan kata lain aplikasi yang menghasilkan aplikasi lain
3.3 Politik MVC
Dengan semakin kompleksnya dan naiknya popularitas servlet yang merupakan salah satu teknologi yang menjembatani JavaBean dengan Enterprise JavaBean atau teknologi lainnya didalam Java EE, seperti JTA, JCA, atau komponen didalam Java SE. Kemudian, kepopuleran SmallTalk pada tahun 80-an yang mengusung pemrograman berorientasi object yang mirip Java dan mendukung teknologi MVC, hal tersebut telah membuat dunia Java juga dipenuhi banyak teknologi manajemen pengembangan yang mengimplementasikan servlet, artinya sebuah teknologi berbasis MVC untuk web.
Apalagi setelah tim Smalltalk yang sekarang semuanya bermarkas di IBM, membuat Eclipse, dengan teknologi SWT yang merupakan turunan dari Smalltalk, telah membuat Java dan Smalltalk menjadi satu. Tentu saja primadona Smalltalk masuk kedalam Java.
Sebenarnya sebelum MVC muncul, dan saat web programming meledak, yang dipelopori oleh Microsoft dengan ASPnya, kemudian disusul oleh PHP yang multiplatform dan sangat cepat, membuat tim Sun membuat sebuah teknologi JSP, yang mana bekerja mirip dengan teknologi web scripting ASP atau PHP, tetapi membawa sifat awal dari Java, yaitu OOP. JSP yang
merupakan turunan dari servlet, memungkinkan sebuah HTML diberi kode Java dan
berinteraksi dengan object didalam container Java EE. Metode ini dikenal dengan pemograman model 1, yang mana dalam dunia nyatanya, karena JSP setiap kali dieksekusi harus dirubah menjadi sebuah class Java, membuat JSP dianggap the dark side of Java didunia Web programming.
Pengembangan Java Model 1 dengan JSP
Dengan sifat JSP yang dianggap buruk, dan membuat sampah didalam container Java EE, sedangkan implementasi pemogramanan berbasis Web dengan servlet adalah sangat rumit dan tidak semudah kompetitornya yaitu ASP dan PHP. Membuat programmer Java harus berpikir keras untuk membuat Java menjadi sebuah teknologi yang layak dipakai didunia Web.
Akhirnya tepatnya sekitar tahun 1996-an, muncul sebuah projek yang mengacu pada model 2 yaitu MVC, model yang getol dipopulerkan oleh tim Smalltalk, jauh sebelum Java lahir, tepatnya sekitar tahun 1988.
Tahun 1996-an, lebih tepat diakhir tahun 2000, Apache yang saat itu sedang mulai melakukan hosting projek Java, dengan bendera Java, tetapi harus mengganti menjadi Jakarta, karena kasus merek dagang. Memiliki sebuah subprojek baru yang bernama Struts.
Struts yang berupa controller memerlukan JSP sebagai presentation layernya. Struts bekerja dengan EJB untuk modelnya, sehingga dalam format MVC, M diisi oleh EJB, C diisi oleh Struts, dan V diisi oleh JSP.
Walaupun setelah itu Apache mengeluarkan teknologi yang merupakan jawaban dari dunia hitam JSP dengan nama Velocity yang akan dibahas dibab berikutnya, serta beberapa teknologi untuk mereplace EJB khusus untuk non distributed computing, seperti iBatis. Bersamaa dengan itu, searah dengan ledakan Java didunia. Lahirlah gerakan framework yang merupakan sebuah nilai tambah terhadap servlet atau lebih tepatnya Java EE.
Struts adalah projek MVC Java pertama yang secara langsung telah merubah peta pasar Java di dunia. Adopsi Struts hampir disemua solusi berbasis Java, mulai dari perusahaan kecil sampai bank-bank kelas dunia mengadopsinya.
Pendekatan Struts yang implementasinya mirip dengan EJB, memerlukan banyak class untuk sebuah eksekusi aplikasi Web, telah membuat seorang jenius didunia Java bernama Richard Oberg mengeluarkan WebWork, dengan konsep HMVC, Hierarhical MVC. Richard Oberg ini adalah salah satu dari orang yang mewarnai dunia Java dengan teknologi populer seperti JBoss dan Xdoclet. Yang terakhir, Xdoclet, merupakan hacking tools paling populer didunia Java. Yang memungkinkan teknologi Java dapat dibuat menjadi apa saja, dengan hanya memanage
sebuah comment didalam class.
Sayangnya Struts yang diciptakan Craig, ditinggalkan sang empunya tanpa sempat mentransfer ide beriliannya, Craig akhirnya mengembangkan sebuah spesifikasi standard berbasis MVC juga dengan nama JavaServer Faces. Yang saat ini sedang getol dipromosikan oleh Oracle, Sun dan JBoss. Dimana mereka semua adalah leader dari spesifikasi ini,
MVC dalam Java
Perang Struts vs WebWork ini adalah perang Java paling menarik, karena WebWork 2.3 diganti namanya menjadi Struts 2.0. Mengapa demikian? Padahal secara projek mereka tidak
berhubungan. Bab berikutnya akan membahas kasus ini.
Teknologi MVC ini sebenarnya tidak hanya ada didunia web atau Java EE saja, sebenarnya didalam Java standard yang lebih dikenal dengan Java SE, telah ada teknologi berbasis MVC, yaitu Swing. Teknologi ini konon diciptakan oleh tim IBM, yang notabene merupakan perusahan pemilik MVC, karena akusisi Smalltalk tadi.
Swing yang berjalan diteknologi AWT, merupakan MVC juga, hampir semua objectnya seperti JTable adalah MVC. Malah beberapa sumber mengatakan hal ini terjadi karena IBM sangat yang terdapat tim Smalltalk didalamnya, telah berkontribusi lebih dari 80% terhadap Swing. Ini yang menjadi alasan mengapa Swing sangat MVC.
Jadi bilamana ingin jadi programmer Java, kata MVC adalah hal biasa. Malahan didunia i yang terkenal dengan solusi yang selalu memikirkan arsitektur dan kekuatan container, MVC telah memiliki banyak turunan, yang berbentuk pola yang lebih sering disebut dengan Pattern.
Struts, Webwork, yang kemudian diikuti oleh Tapestry, JSF, Stripes, akhirnya muncul
SpringMVC. Semua ini adalah teknologi yang memungkinkan pemograman memisahkan antara
data, business logic dan presentation layer dalam sebuah pola standar bernama MVC.
Malah SpringMVC yang berdiri diatas IOC (Injection of Control) atau Depednency Injection, telah membuat framework-framework MVC ini dapat saling dipertukarkan. Sebagai contoh sebuah solusi menggunakan model EJB3, kemudian diganti denagn Hibernate saja, atau solusi lain dengan TopLink. Hal ini memungkinkan revolusi IOC yang semula diciptakan karena EJB yang memang diciptakan untuk komputasi terdistribusi, tetapi ternyata tidak cocok untuk projek yang berbudget kecil, bertransformasi menjadi sebuah layer baru dalam pemograman, terutama sebagai perekat antara model, viewer dan controler dalam implementasi aplikasi berbasis MVC didunia Java khususnya.
3.4 MVC sebagai solusi Java untuk Web
Dalam pengembangan MVC, sebenarnya kita dapat melakukan kombinasi berbagai teknologi untuk membuat solusi berbasis MVC. Jadi jangan berharap dengan pakai Struts saja kita dapat mengimplementasikan MVC.
Alfresco (http://www.alfresco.org), merupakan solusi digital library yang mengimplementasikan MyFaces, Spring, Hibernate, digabung dengan teknologi JCR untuk penyimpanan file, Lucense untuk search engine.
Arsitektur Alfresco
JBoss Seam, merupakan solusi fondasi Web 2.0, yang mengintegrasikan MyFaces, Hibernate, dan JBoss Micro Kernel sebagai IOCnya.
Arsitektur JBoss Seam
Sedangkan produk dalam negeri Indonesia, BlueOxygen Cimande, menggunakan WebWork/Struts 2.0, Spring dan Hibernate sebagai kombinasi MVCnya.
Arsitektur BlueOxygen Cimande
Seperti yang dijelaskan disubbab sebelumnya, ke-3 teknologi ini adalah memiliki kerangka awal yang sama, tetapi merupakan kombinasi yang berbeda.
Malah reposisi Spring yang menyaingi JBoss AS, memungkinkan Cimande suatu hari bersaing dengan JBoss AS. Apakah itu memungkinkan?
3.5 Dari MVC ke WARS, dilanjutkan dengan AJAX
Tahun 2005, MVC telah berkembang dengan lahirnya produk Open Source untuk Workflow, seperti Shark dari Enhyrda, JBPM dari JBoss, serta teknologi rulemanagement seperti Mandarax, Drools (JBoss), serta diadopsinya teknologi expert system kedalam Java, yang memungkinkan setiap MVC bukan hanya mengakses model data saja, tetapi telah memelukan sebuah interupsi tambahan seperti status pekerjaan dalam workflow repository, serta
memungkinkannya setiap proses harus melalui peraturan yang disisipkan dalam kode kita, menggunakan rule script.
Arsitektur AJAX
Yang lebih hebatnya, Workflow dan Rule scriptnya ini dapat berubah dan bekerja terpisah secara dinamis diluar MVC.
Mekanisme ini pernah dicetuskan dengan sebutan WARS singkatan dari Workflow, Action, Result and State, yang sebenarnya sebuah nama baru dari MVC+W. Maklum orang Java paling suka nama baru, konon biar keren dan setiap yang keren-keren ini memiliki daya jual lebih. Jadi kalau mendengar kata WARS, sebenarnya itu adalah MVC yang didalam memiliki teknologi workflow.
Mekanisme yang terjadi dalam dunia Javascript, yang mana setiap interaksi dengan server dengan XMLHttp, disebut AJAX.
3.6 Jenis-jenis MVC
Kembali ke tahun 2000-an, sebenarnya perang MVC terjadi antara Struts dengan WebWork, yang mana WebWork lebih mengutamakan kemudahan, dengan implementasi teknologi dispatcher, sedangkan Struts yang bernaung di Apache, yang mana Apache merupakan nama yang paling hot dalam dunia Open Source, telah membuat Struts menjadi framwork untuk MVC paling populer saat itu. Secara marketing, terlihat WebWork yang mengatakan dirinya pull MVC, sedangkan Struts adalah push MVC, terlihat berbeda. MergerWebWork dengan Struts ditahun 2005, telah membuat kombinasi yang menarik sekali.
Saat itu, orang beranggapan Struts dan WebWork adalah MVC, tetapi dengan berkembannya waktu, dan semakin banyak rekan-rekan kita diseluruh dunia yang membuat framework yang mungkin saja berbasis pada framework yang sudah ada, tetapi dengan tambahan fitur, seperti setelah Struts muncul JSF, sedangkan setelah WebWork lahir Stripes. Dimana Stripes,
walaupun belum sehandal WebWork, terlihat mengimplementasikan annonation didalamnya, yang konon tim WebWork sedang mencari cara bagaimana mengimplementasikan annonation yang mudah didalamnya.
Teknologi mirip MVC yang khusus untuk XML adalah Cocoon yang juga dari Apache, dilanjutkan dengan Turbine, lalu lahir lagi komponen sejenis seperti Tapestry.
Alhasil dalam modul ini untuk memudahkan pemilihan MVC, MVC dipisahkan menjadi MVC yang berbasis Component dan MVC yang berbasis Action.
MVC tipe lain adalah yang berbasis component adalah yang bekerja seperti halnya
pemograman event driven, setiap tag memungkinkan dibuat komponennnya, teknologi yang sangat serius dengan model ini adalah JSF. Yang mana implementasi JSF ini sebenarnya merupakan adopsi teknologi Swing kedalam teknologi berbasis Web.
Sedangkan teknologi MVC berbasis Action, adalah adopsi implementasi yang mengacu pada request dan responsenya teknologi HTML, teknologi ini dilead oleh WebWork, yang mana setiap pengembangan mengadopsi page-page dari HTML.
Tahun-tahun kedepan sepertinya akan terjadi integrasi antara framework ini, seperti Struts 2.0 yang merupakan projek integrasi dari Struts dan WebWork, ternyata mulai memasukan unsur komponen kedalamnya, dengan memasukan JSF sebagai komponennya.
Jadi dapat dikatakan, tahun-tahun kedepan akan lahir MVC yang mengadopsi kedua teknologi ini. Ini tentu saja evolusi MVC selama lebih dari 10 tahun yang dilakukan komunitas Open Source.
Dari semua ini yang menarik adalah, teknologi Web yang tidak Open Source malahan tidak dapat bertahan, seperti WebObject dari Apple, merupakan teknologi Java berbasis komponen yang sangat bagus, tetapi sayang karena tidak Open Source dan berjalan diatas Mac saja, serta focus Apple yang bukan di Java, membuat produk ini tenggelam.
3.7 AJAX dan MVC
Searah dengan semakin cepatnya Internet, serta keterbatasan HTML untuk memungkinkan terjadi sebuah aplikasi berbasis Web yang interaktif. Lahirlah sebuah teknologi bernama AJAX, yang mana populer setelah Google meluncurkan Gmail, yang merupakan free email yang bekerja sangat cepat.
Pengembangan Web Classic vs AJAX
AJAX yang merupakan singkatan dari Asyncrhonous JavaScript and XML, merupakan sebuah mekanisme yang memungkinkan proses Web dipisah antara server dan client, ini disebabkan PC client yang diasumsikan sudah terlalu cepat, dan mubajir bilamana kita menggunakan teknologi berbasis MVC sekalipun. Karena ternyata dengan menggunakan AJAX, sebuah penekanan beban server dari 30% sampai 60% dapat terjadi pada server yang sama.
Metode Request dan Response aplikasi Classic / Non AJAX
Yang lebih hebat lagi, AJAX memungkinkan kita mengakses beberapa data resource tanpa perlu melakukan refresh page didalam browser, yang tentu saja ini merupakan teknologi interaktif yang bagus sekali, terutama untuk mereka yang memerlukan analisa dan proses yang cepat.
Metode Request dan Response AJAX
Kehebatan AJAX ini terus berkembang, yang malahan dipercaya merupakan teknologi yang akan memungkinkan kita dapat bekerja untuk melakukan pekerjaan harian perkantoran tanpa perlu menginstall aplikasi Office Automation seperti OpenOffice atau Microsoft Office.
Untuk membuat aplikasi AJAX sebenarnya tidaklah sulit, karena komunitas AJAX telah banyak membuat sebuah wrapper atau script library yang siap pakai, seperti Yahoo dengan Yahoo UI, Google dengan GWT, DojoToolkit, atau JSON, ataupun DWR buatan Joe Walker yang
memungkinkan object Java dapat berinteraksi dengan object Javascript.
Mekanisme Pengembangan AJAX dengan DWR
Alhasil dari semua evolusi internet ini, dalam waktu dekat akan muncul duo MVC, yaitu MVC diserver serta MVC untuk pemorsesan XML dengan AJAX.
Dengan merger antara MVC berbasis komponen dan action, serta integrasi MVC baru ini
kedalam teknologi AJAX, membuat sebuah pemograman semakin kompleks, interaktif dan lebih mudah didebug.
Teknologi duo MVC ini diimplementasikan juga di Indonesia dalam project dibawah Cimande dengan nama Cimande Thin, yang mengutilisiasi DWR serta fitur WebWork untuk validasi berbasis AJAX. Diharapkan dalam waktu dekat akan muncul result management dari WebWork yang berbentuk AJAX. Saat ini, fitur ini sedang dikembangkan oleh tim DWR untuk DWR 2.0.
