Setiap pengembang yang menggunakan servlet saat ini mengetahui JSP, teknologi web yang ditemukan oleh Sun Microsystems dan menghabiskan banyak upaya untuk mempromosikan dan membangun teknologi servlet. JSP melepaskan kode HTML dari servlet, sehingga mempercepat pengembangan aplikasi web dan pemeliharaan halaman. Faktanya, dokumen resmi "Model Pengembangan Aplikasi" yang diterbitkan oleh Sun bahkan lebih jauh lagi: "Teknologi JSP harus dianggap sebagai standar, dan servlet dapat dianggap sebagai pelengkap dalam banyak kasus." Dengarkan versi opini).
Tujuan artikel ini adalah untuk mendengarkan penilaian masuk akalnya pernyataan ini -- dengan membandingkan JSP dengan teknologi berbasis servlet lainnya: mesin templat.
Masalah dengan penggunaan Servlet secara langsung
Awalnya, servlet ditemukan dan seluruh dunia melihat keunggulannya. Halaman web dinamis berdasarkan servlet dapat dijalankan dengan cepat, dapat dengan mudah ditransfer antara beberapa server, dan dapat diintegrasikan secara sempurna dengan database back-end. Servlet diterima secara luas sebagai platform pilihan untuk server web.
Namun, kode html yang biasanya diimplementasikan dengan cara yang sederhana kini mengharuskan programmer untuk memanggil out.println() untuk setiap baris HTML, yang telah menjadi masalah serius dalam aplikasi servlet yang sebenarnya. Konten HTML harus diimplementasikan melalui kode, yang merupakan tugas yang membosankan dan memakan waktu untuk halaman HTML berukuran besar. Selain itu, orang-orang yang bertanggung jawab atas konten web harus mempekerjakan pengembang untuk melakukan semua pembaruan. Oleh karena itu, masyarakat mencari solusi yang lebih baik.
JSP tiba!
JSP 0.90 muncul. Dalam teknik ini Anda menyematkan kode Java ke dalam file HTML dan server akan secara otomatis membuat servlet untuk halaman tersebut. JSP dianggap sebagai cara mudah untuk menulis servlet. Semua HTML dapat diperoleh secara langsung tanpa harus memanggil out.println(), dan penanggung jawab konten halaman dapat memodifikasi HTML secara langsung tanpa risiko merusak kode Java.
Namun, memiliki seniman halaman dan pengembang yang mengerjakan file yang sama bukanlah hal yang ideal, dan menyematkan Java ke dalam HTML terbukti sama memalukannya dengan menyematkan HTML ke dalam Java. Masih sulit untuk membaca kode yang berantakan.
Hasilnya, orang-orang menjadi lebih dewasa dalam menggunakan jsp dan lebih banyak menggunakan JavaBeans. Kacang berisi kode logika bisnis yang dibutuhkan oleh jsp. Sebagian besar kode di JSP dapat dikeluarkan dan dimasukkan ke dalam bean, hanya menyisakan sedikit markup untuk memanggil bean.
Baru-baru ini, orang mulai berpikir bahwa halaman JSP dengan cara ini benar-benar mirip dengan tampilan. Mereka menjadi komponen yang digunakan untuk menampilkan hasil permintaan klien. Jadi orang akan berpikir, kenapa tidak mengirimkan request langsung ke view? Apa yang terjadi jika tampilan target tidak sesuai dengan permintaan? Lagi pula, banyak permintaan memiliki banyak kemungkinan untuk mendapatkan tampilan hasil. Misalnya, permintaan yang sama mungkin menghasilkan halaman yang berhasil, laporan kesalahan pengecualian database, atau laporan kesalahan parameter yang hilang. Permintaan yang sama mungkin menghasilkan halaman dalam bahasa Inggris atau halaman dalam bahasa Spanyol, tergantung pada lokasi klien. Mengapa klien harus mengirim permintaan langsung ke tampilan? Mengapa klien tidak mengirim permintaan ke beberapa komponen server umum dan membiarkan server memutuskan apa yang dikembalikan oleh tampilan JSP
? Model 2" Desain, ini adalah model berbasis model-view-controller yang didefinisikan dalam JSP 0.92. Dalam desain ini, permintaan dikirim ke pengontrol servlet, yang menjalankan logika bisnis dan menghasilkan "model" data serupa untuk ditampilkan. Data ini kemudian dikirim secara internal ke "tampilan" JSP untuk ditampilkan, membuat halaman JSP terlihat seperti JavaBean biasa yang tertanam. Halaman JSP yang sesuai dapat dipilih untuk ditampilkan berdasarkan logika internal servlet yang bertanggung jawab untuk kontrol. Dengan cara ini, file JSP menjadi tampilan template yang indah. Ini adalah pengembangan lain dan telah dipuji oleh pengembang lain hingga hari ini.
Masuk ke Mesin Templat
dan gunakan mesin templat untuk menggantikan JSP tujuan umum. Desain selanjutnya akan menjadi lebih sederhana, sintaksisnya akan lebih sederhana, pesan kesalahannya akan lebih mudah dibaca , dan alatnya akan lebih ramah pengguna. Beberapa perusahaan telah membuat mesin seperti itu, yang paling terkenal mungkin adalah WebMacro ( http://webmacro.org , dari Semiotek), dan mesin mereka gratis.
Pengembang harus memahami bahwa memilih mesin templat untuk menggantikan JSP memberikan keuntungan teknis berikut, yang juga merupakan beberapa kekurangan jsp:
Masalah #1: Kode Java terlalu bertemplat
Meskipun dianggap desain yang buruk, JSP tetap berupaya menambahkan Java kode ke halaman web. Ini mirip dengan apa yang pernah dilakukan Java, yang merupakan modifikasi sederhana dari C++. Mesin templat juga menyederhanakannya dengan menghapus kode sumber tingkat rendah di jsp. Mesin template menerapkan desain yang lebih baik.
Pertanyaan #2: Membutuhkan Kode Java
Diperlukan untuk menulis beberapa kode Java di halaman JSP. Misalnya, halaman menentukan konteks akar aplikasi web saat ini dan mengarah ke halaman beranda.
Yang terbaik adalah menggunakan kode Java berikut di JSP:
＜a href="＜%= request.getContextPath() %＞/index.html"＞Halaman beranda＜/a＞
Anda dapat mencoba menghindari kode Java dan menggunakan tag
property="contextPath"/＞/index.html"＞HomePage＜/a＞
Menggunakan mesin template, tidak ada kode Java dan sintaks yang jelek. Berikut cara penulisannya di WebMacro dengan persyaratan yang sama:
＜a href="$ Request.ContextPath ;/index.html">Halaman beranda
Di WebMacro, ContextPath digunakan sebagai atribut variabel $Request, menggunakan sintaks mirip Perl. Mesin templat lain menggunakan tipe sintaksis lain.
Melihat contoh lain, misalkan "tampilan" tingkat lanjut perlu menyetel cookie untuk mencatat konfigurasi warna default pengguna - tugas ini sepertinya diselesaikan oleh tampilan, bukan oleh pengontrol servlet. Harus ada kode Java seperti ini di JSP:
<% Cookie c = new Cookie("colorscheme", "blue"); respon.addCookie(c);
Tidak ada kode Java di WebMacro:
#set $Cookie.colorscheme = "biru"
sebagai ion terakhir, jika Anda ingin mengambil konfigurasi warna pada cookie asli. Untuk JSP, kita dapat memikirkan kelas alat yang sesuai untuk membantu, karena akan menjadi konyol dan sulit untuk melakukan hal-hal tingkat rendah secara langsung dengan getCookies(). Di JSP:
<% String colourscheme = ServletUtils.getCookie(request, "colorscheme"); %>
Tidak diperlukan kelas alat di WebMacro, biasanya: $Cookie.colorscheme.Value. Untuk seniman grafis yang menulis JSP, sintaksis mana yang lebih mudah dipelajari?
JSP 1.1 memperkenalkan tag khusus yang memungkinkan tag mirip HTML untuk mengeksekusi kode Java di latar belakang halaman JSP. Ini akan memiliki beberapa nilai, tetapi hanya jika ada pustaka tag standar yang dikenal luas, berfitur lengkap, tersedia secara bebas. Saat ini tidak ada perpustakaan tag seperti itu.
Masalah #3: Tugas sederhana masih melelahkan
Bahkan tugas sederhana, seperti memasukkan header dan footer, masih sangat sulit di JSP. Misalkan ada template "header" dan "footer" yang akan disertakan di semua halaman, dan setiap template harus berisi judul halaman saat ini di kontennya.
Cara terbaik di JSP adalah:
＜% String title = "Judul Halaman"; %＞
＜%@ sertakan file="/header.jsp" %＞
...konten halaman Anda...
＜%@ include file="/footer.jsp" %＞
Desainer halaman harus ingat untuk tidak menghilangkan titik koma di baris pertama dan mendefinisikan judul sebagai string. Selain itu, /header.jsp dan /footer.jsp harus berada di direktori root dan harus merupakan file yang dapat diakses sepenuhnya.
Menyertakan header dan footer di WebMacro relatif sederhana:
#set $title = "Judul Halaman"
#urai "header.wm"
Konten Anda di sini
#parse "footer.wm"
Tidak ada titik koma atau definisi judul yang perlu diingat oleh desainer, dan file .wm dapat ditempatkan di jalur pencarian yang dapat disesuaikan.
Masalah #4: Loop yang sangat tebal
Perulangan di JSP sulit dilakukan. Di sini, JSP digunakan untuk berulang kali mencetak nama setiap objek ISP.
<%
Pencacahan e = list.elements();
while (e.hasMoreElements()) {
out.print("Nama selanjutnya adalah ");
keluar.println(((ISP)e.nextElement()).getName());
keluar.cetak("
");
}
%>
Mungkin suatu saat akan ada tag yang ditentukan pengguna untuk melakukan loop ini. Hal yang sama berlaku untuk "jika". Halaman JSP mungkin terlihat seperti kode Java yang aneh. Dan pada saat yang sama, loop webmacro itu indah:
#foreach $isp dalam $isps {
Nama berikutnya adalah $isp.Nama
}
Jika perlu, direktif #foreach dapat dengan mudah diganti dengan direktif khusus #foreach-backwards.
Jika Anda menggunakan jsp, mungkin menjadi seperti ini: (Ini kemungkinan tag
Nama berikutnya adalah ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
＜/foreach＞
Perancang secara alami akan memilih yang pertama.
Masalah #5: Pesan Kesalahan yang Tidak Berguna
JSP sering kali mempunyai beberapa pesan kesalahan yang mengejutkan. Ini karena halaman tersebut terlebih dahulu diubah menjadi servlet dan kemudian dikompilasi. Alat JSP yang baik secara relatif dapat meningkatkan kemungkinan menemukan lokasi kesalahan, namun alat terbaik pun tidak dapat membuat semua pesan kesalahan mudah dibaca. Karena proses konversi, beberapa kesalahan mungkin tidak dapat diidentifikasi oleh alat.
Misalnya, halaman JSP perlu membuat judul yang umum untuk semua halaman. Tidak ada yang salah dengan kode berikut:
=
"Global title";
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Pernyataan diharapkan.
hitungan int statis = 0;
^
Informasi ini menganggap bahwa skrip di atas dimasukkan ke dalam metode _jspService() dan variabel statis tidak diperbolehkan untuk dimasukkan ke dalam metode. Sintaksnya harus <%! %>. Sulit bagi perancang halaman untuk membaca pesan kesalahan ini. Bahkan platform terbaik pun gagal dalam hal ini. Bahkan memindahkan semua kode Java dari halaman tidak menyelesaikan masalah. Juga, apa yang salah dengan ungkapan berikut?
<% hitung %>
kucing jantan memberikan:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Jumlah kelas tidak ditemukan di
ketik deklarasi.
menghitung
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Deklarasi tidak valid.
keluar.tulis("rn");
^
Dengan kata lain, itu hanyalah tanda yang hilang. Seharusnya <%= hitungan %>.
Karena mesin template dapat dihasilkan langsung dari file template tanpa terjemahan dramatis ke dalam kode, sangat mudah untuk memberikan pelaporan kesalahan yang sesuai. Dengan analogi, ketika perintah bahasa C diketik ke dalam baris perintah shell Unix, Anda tidak ingin shell menghasilkan program C untuk menjalankan perintah tersebut, tetapi Anda hanya perlu shell untuk menafsirkan perintah dan menjalankannya, dan langsung melaporkan kesalahan apa pun.
Masalah #6: Membutuhkan Kompiler
JSP memerlukan kompiler yang ditempatkan di server web. Hal ini menjadi masalah karena Sun menolak menyerahkan pustaka tools.jar yang berisi kompiler javac mereka. Server web dapat menyertakan kompiler pihak ketiga seperti IBM Jikes. Namun kompiler seperti itu tidak bekerja dengan lancar di semua platform (ditulis dalam C++) dan tidak kondusif untuk membangun server web Java murni. JSP memiliki opsi prakompilasi yang membantu, meskipun tidak sempurna.
Masalah #7: Pemborosan Ruang
JSP menghabiskan memori ekstra dan ruang hard disk. Untuk setiap file JSP 30K di server, file kelas terkait yang lebih besar dari 30K harus dibuat. Secara efektif menggandakan ruang hard drive. Mengingat file JSP dapat dengan mudah memasukkan file data besar melalui <%@ include> kapan saja, kekhawatiran ini memiliki arti yang sangat praktis. Pada saat yang sama, data file kelas setiap JSP harus dimuat ke dalam memori server, yang berarti memori server harus menyimpan seluruh pohon dokumen JSP selamanya. Beberapa JVM memiliki kemampuan untuk memindahkan data file kelas dari memori; namun, pemrogram biasanya tidak memiliki kendali atas aturan deklarasi ulang, dan deklarasi ulang mungkin tidak terlalu efisien untuk situs besar. Untuk mesin templat, ruang dihemat karena tidak ada file kedua yang dihasilkan. Mesin templat juga memberi pemrogram kendali penuh atas bagaimana templat di-cache di memori.
Ada juga beberapa masalah dalam penggunaan mesin templat:
Masalah templat #1: Tidak ditentukan secara ketat
. Cara kerja mesin templat tidak ditentukan secara ketat. Namun, dibandingkan dengan JSP, hal ini sebenarnya tidak terlalu penting. Berbeda dengan JSP, mesin template tidak memiliki persyaratan khusus untuk server web - server mana pun yang mendukung servlet dapat mendukung mesin template (termasuk server API 2.0 seperti Apache/JServ, server tersebut). tidak sepenuhnya mendukung JSP)! Jika persaingan yang sehat untuk desain mesin template terbaik dapat menyebabkan inovasi yang memukau, terutama dengan promosi open source, (memungkinkan ide untuk saling mendorong dan mempromosikan), maka WebMacro saat ini akan menjadi seperti Perl . Hal ini tidak didefinisikan secara ketat tetapi promosi organisasi open source adalah standarnya.
Masalah Template #2: Tidak Dikenali
Mesin template tidak banyak diketahui. JSP telah menduduki pasar komersial yang besar dan mengakar kuat di hati masyarakat. Penggunaan mesin template g hanya bisa menjadi teknologi alternatif yang tidak dipahami.
Masalah Templat #3: Belum Dikerahkan
Mesin templat belum terkonfigurasi dengan baik. Tidak ada pengujian kinerja dan perbandingan antara mesin template dan JSP. Secara teori, implementasi mesin template yang diterapkan dengan baik harus sesuai dengan JSP yang diterapkan dengan baik, namun mengingat pihak ketiga telah memberikan dorongan besar untuk jsp, hanya jsp yang diterapkan dengan baik.
Peran JSP
Tentu saja JSP pasti akan mendapat tempatnya di masa depan. Kemiripan JSP dan ASP terlihat dari namanya saja, hanya berbeda satu huruf saja. Oleh karena itu, jika orang yang menggunakan ASP beralih ke Java, lingkungan JSP yang sangat mirip akan memainkan peran besar dalam mempromosikan hal ini. Peran menjaga hubungan yang sesuai dengan ASP juga harus menjadi pertimbangan utama bagi desainer yang meluncurkan JSP.
Namun yang menjadi persoalan di sini adalah terdapat perbedaan besar antara manfaat yang diperoleh pekerja saat pindah ke lingkungan baru dan apakah hal tersebut merupakan cara terbaik untuk memanfaatkan lingkungan tersebut.
JSP semakin menunjukkan bahwa ia menjadi salah satu teknologi Java yang paling penting, dan memungkinkan orang untuk meninggalkan dunia ASP - dengan demikian, Sun akan mendukung kasus bisnis yang kuat ini, dan pendukung teknologi terkait Java juga akan memberikan dukungan yang lebih besar.
Namun, ini bukan solusi terbaik untuk platform Java. Ini akan membuat solusi Java tampak seperti solusi tanpa Java.