Aerisjs: Google map untuk aplikasi Backbonejs

Mengurus peta pada aplikasi laman tunggal anda bukanlah sesuatu yang mudah. Ini kerana pustaka peta seperti Google Map, Leaflet dan yang seangkatan dengannya memerlukan anda sebagai seorang developer untuk menimbang segala faktor bagi membuatkan aplikasi anda benar-benar interaktif dan cekap dalam pemanfaatan memori. Malah skop application program interface (API) yang disediakan juga tidak memuaskan apabila ia banyak menggunakan ruang global berbanding local dan ini memudahkan aplikasi kita terdedah kepada memory leak dan sebagainya.

Sehubungan dengan masalah ini, Aerisjs adalah sebuah pustaka javaskrip yang dapat memastikan aplikasi anda sentiasa berada dalam keadaan 'segar'.

 https://github.com/hamweather/aerisjs

Pustaka ini dibina dengan tujuan asalnya untuk menvisualisasikan data-data cuaca seperti hujan, salji, ribut dan jerebu diatas peta dan pada saat ini, ia giat dibangun secara komersial. Jadi ia memerlukan anda untuk berdaftar sekiranya mahu menggunakan khidmat maklumat cuaca tersebut. Cuma pustaka ini masih lagi boleh dimanfaatkan tanpa daftar yakni secara percuma untuk menguruskan peta dan segala propertinya seperti marker, event dan lain-lain lagi. Lihat sini.

http://jsfiddle.net/pwRyt/10/

Antara ciri-ciri Aerisjs yang menarik adalah

Kelancaran penukaran khidmat peta untuk Google Map, Leaflet dan Open Layers

Tambahan objek-objek peta (Info Box, KML, Polygon dan Polylines)

Menghimpun marker menjadi sebuah cluster

Memautkan objek Backbone.Event kepada objek peta

Khidmat geocode dan geolocation

Walau bagaimanapun, pustaka ini masih lagi dalam proses pembangunan dan pengujian kerana masih terdapat lagi kekurangan dari segi khidmat cuacanya.

Sekiranya anda berminat untuk dapatkan bantuan bagi penggunaannya boleh tinggalkan komen di bawah. Selamat koding!

Aplikasi Laman Tunggal, Single Page Application

Ini adalah sebuah kalimat yang telah lama berlegar ketika seseorang itu merancang untuk membangun sebuah aplikasi mobil yang bersifat hybrid. Konsep ini rata-ratanya dipengaruhi oleh kecekapan Gmail, sebuah aplikasi email yang dibangun oleh Google. Bertitik tolak dari Gmail, Google mengembangkan konsep aplikasi laman tunggal ini kepada Google Docs, Drive, dan kini, Search. Anda tentu perasan dimana web-web tersebut begitu responsif terhadap setiap permintaan anda sewaktu anda klik pada pautan-pautan yang disediakan. Itulah kelebihan Konsep Aplikasi Laman Tunggal.

Tujuannya tak lain tak bukan adalah mempersembahkan sebuah aplikasi web yang menawarkan pengalaman penggunaannya hampir sama dengan penggunaan aplikasi desktop.

Teknik pembangunan yang digunakan juga amatlah berbeza sekiranya anda sudah terbiasa menyediakan berpuluh halaman untuk sesebuah web. Bagi pengaturcara PHP, anda sudah tentu terbiasa dengan teknik PHP yang dinamik, iaitu menyediakan satu template untuk header dan satu lagi untuk footer yang sifatnya umum bagi penggunaan yang meluas dalam projek web anda. Manakala bahagian dinamiknya adalah pada sidebar atau kandungan paparan utama. Kesimpulannya teknik ini memerlukan anda menjana kesemua template itu tadi di web server, dan membebankan server dan network untuk membawanya sebagai sebuah dokumen HTML kepada komputer client.

Ketika saya membangunkan sebuah aplikasi dashboard beberapa bulan yang lalu, saya berada dalam keadaan dilema ini. Waktu itu saya buntu kerana saya telah pun menghasilkan sebuah laman web yang perlu memaparkan beberapa carta, yang sepenuhnya diproses di server dan ia bersaiz agak besar kerana, terdapat berpuluh pustaka javascript dan CSS, serta data-data yang diperolehi daripada query pengkalan data. Tetapi carta-carta itu hanya akan terhasil ketika dokumen HTML itu lengkap muat sepenuhnya pada komputer client. Saya perlu paparkan sebuah carta yang interaktif. Interaktif beerti pengguna dapat berinteraksi dengan carta yang terpapar bagi memuaskan persoalan-persoalan analisisnya. Jadi disinilah dilema tersebut. 

Masalah ini saya atasi dengan penggunaan jQuery Ajax yang minimal pada mulanya. Tetapi lama kelamaan, ia jadi satu keperluan pula bagi menghasilkan sebuah aplikasi yang hanya ada sebuah halaman tetapi mempunyai berpuluh laman mini didalamnya.

Saya tertarik dengan konsep ini dan berjaya mengolah konsep ini menggunakan pustaka javascript iaitu BackboneJs. Pengalaman yang sudah hampir setahun telah banyak memberi kesan dalam memaknai kalimat tersebut. 

Ada yang pada saya baik untuk dipraktikkan konsep ini ketika mempertimbangkan keperluan-keperluan asas pengguna dan pada masa yang lain konsep ini perlu disederhanakan berikutan had-had atau halangan- halangan  tertentu terdapat pada kemampuan komputer client yang berbagai spesifikasinya.

Jikalau anda seorang yang mementingkan SEO Google, Yahoo dan Bing, konsep ini memerlukan anda untuk memfaktorkan semula kod-kod HTML, javascript dan CSS anda. Ini kerana, Search engine hanya berinteraksi dengan web server berbanding urusan yang terdapat dalam kod javascript anda. 

Apapun ini bukanlah sebuah konsep yang baru dalam dunia teknologi web. Mungkin saja ada yang telah mematangkan lagi konsep ini agar persembahan web tidak hambar di mata kasat pengguna smart phone. 

Pemfaktoran kod yang Perlu diBeri Perhatian Bagi Kelancaran Aplikasi Backbone Anda

Setelah hampir setahun berkubang menggunakan BackboneJs dan RequireJs, berbagai faktor yang perlu diberi perhatian sekiranya anda benar-benar menitik beratkan untuk membangun sebuah aplikasi laman tunggal yang berkesan. Antaranya adalah 

1. Organisasi kod

2. Kebocoran memori pada Backbone.View dan Event

3. Kekerapan berhubung antara client dan server

4. Teknik rendering Backbone.model dalam sesebuah Backbone.Collection

Organisasi kod

Saya menggunakan RequireJs dalam soal organisasi kod. Ini adalah kerana pustaka ini berkhidmat untuk mengatur langsung keperluan-keperluan terhadap pustaka javascript yang lain bagi meminimalkan pencemaran penggunaan pembolehubah yang berskop global. Disamping itu kod yang terhasil adalah lebih mudah dibaca kerana kemodularan skop skrip itu sendiri. Apa yang menarik mengenai teknik ini adalah, aplikasi hanya akan memuat turun pustaka atau skrip yang diperlukan pada saat ia diperlukan. Jadi aplikasi tidak perlu untuk memuat turun keseluruhan kod atau skrip untuk sesebuah aplikasi berfungsi dengan berkesan.

Kebocoran memori pada Backbone.View dan Backbone.Event

Disebabkan ketergantungan BackboneJs kepada jQuery, maka adalah penting untuk anda memastikan setiap elemen yang dihasilkan oleh Backbone.View anda benar-benar dihapuskan dari view sebelum beralih kepada view yang lain. Ini kerana jQuery bertindak untuk meng'cache' atau mengklonkan elemen yang dihasilkan view bagi tujuan pengaksesan yang cepat. Maka kemungkinan besar anda akan terperangkap dengan tindakan jQuery tersebut dengan menghasilkan elemen-elemen yang serupa dengan fungsi yang sama. Ini adalah suatu kesalahan sekiranya anda tidak menyedari peranan tersebut. Anda akan dapati tindakan keatas elemen-elemen yang serupa dan sama itu tadi akan berakibat penghasilan pelaksanaan kod yang beberapa kali diulang-ulang. Backbone ada menyediakan ruang untuk atasi perkara ini, sama ada ada menggunakan kaedah .remove(), .off(), .setElement() atau .delegateEvent(). 

Kekerapan berhubung antara client dan server

Ada keadaan-keadaan tertentu yang memerlukan saya menghubungi server untuk query ke database bagi maklumat-maklumat tertentu. Sebagai contoh, maklumat pengguna yang login ke aplikasi. Maklumat ini pada awal pemulaan aplikasi, sewaktu pengguna sudah berjaya login, telah pun dicapai maklumatnya dari database. Jadi saya akan menentukan untuk menyimpan maklumat ini sama ada melalui kaedah in-memory, sessionStorage atau localStorage. Tetapi saya memilih untuk mengekalkannya sebagai sebagai sebuah objek yang aktif. Cara ini akan menjimatkan masa ulang alik query database kerana maklumat kritikal ini senantiasa diperlukan untuk operasi CRUD. Ini bermakna sebagai seorang pengaturcara, anda perlulah menilai kembali seberapa kerap anda perlu menjalin hubungan dengan server. 

Teknik rendering Backbone.model dalam sesebuah Backbone.Collection

Bagi sebuah Collection yang bersaiz besar, adalah penting untuk memfaktorkan semula teknik anda merender model didalamnya bagi mengelak penyalahgunaan memori pada komputer client. Sekiranya tidak difaktor semula, ini akan menimbulkan ketidakselesaan pada pengguna ketika menggunakan aplikasi. Kebanyakan contoh diluar akan menampilkan teknik jQuery .append() untuk render model dalam collection. Teknik ini akan mengurangkan tahap responsif sesebuah aplikasi terutamanya pada komputer lama. Salah satu cara yang popular untuk mengatasi masalah ini adalah document.createDocumentFragment(). Setakat ini saja cara yang cepat dan efisyen untuk merender subview.

More security added for your BackboneJS apps

I've been exploring this simple login mechanism used by Clint where he simply depends on the PHP session to authorize the user on every request made to PHP REST server. Alhamdulillah it solves my problem on how to authenticate user on BackboneJs apps (star or fork it here). But I still feel something is not right because when you are building the Ajax apps, you cannot simply authorize the session or cookie just like you usually do your traditional PHP apps. I read more about how to validate, authorize, authenticate, etc the AJAX apps.

After spending time reading this, I thought Clint's apps lack of basic CSRF. So here is snippet to make your BackboneJs Apps more secure

Please refer to index.php file where you can see all the slim framework code, look for function name "login" and "authorize" 

Simply replace the code above. The snippet now will authenticate every request made to the server. Check this out in your debugger console.

Before user login

After login and request protected data

As for the front end, you will need to modify your login script by define the request header

The flow with this approach may go something like this:

1. The user navigates in their browser to the BackboneJs application
2. The server returns a basic web page and a JavaScript application
3. The JavaScript application can’t find an authentication token in the web site’s cookies
4. The JavaScript application displays a login form
5. The user enters correct login credentials and then submits the form
6. The server validates the login information and creates an authentication token for the user
7. The server sets the authentication token in a cookie/session and returns it to the JavaScript application
8. The JavaScript application makes a request for some protected data, sending the authentication token in a custom header
9. The server validates the token and then returns the data

as you noticed, i used jQuery's function and Twitter Bootstrap's CSS class.

Belajar BackboneJS I

Pustaka BackboneJS ini boleh juga diibaratkan seperti makanan yang berat umpama Nasi Arab yang lambat dihadam oleh perut. Jika mahu menikmatinya, harus dicuit sikit demi sedikit, dikunyah sebaik-baiknya supaya tercerna sempurna. Jika tidak alamatnya anda mungkin tercekik, atau menjadi sedu bahkan lebih teruk lagi keracunan makanan. Sama juga halnya dengan BackboneJS. Jika mau menguasainya, Ia perlu dipelajari sikit demi sedikit. Ada tatatertibnya. Jika tidak anda akan jemu (atau muntah balik) jika tidak sabar menguasainya. Ada sifat tertentu untuk kuasainya. Sebagai contoh anda memerlukan ketekunan untuk memahami setiap objeknya yang boleh diupaya kebolehannya (extend).

Backbone.Router: Penentu Haluan Aplikasi Anda

Selaku penentu haluan aplikasi anda, ia bertanggungjawab untuk memetakan laluan (path) URL atau parameter dalam URL kepada keadaan aplikasi (application state).  Secara teknikalnya, ia beroperasi dengan mengatur kod-kod aplikasi untuk mengemaskini haluan dan memberi perhatian khusus kepada laluan yang dilalui oleh pengguna melalui objek Backbone.History. Justeru itu, Backbone.Router dimanfaatkan untuk mengawal selia setiap kod javaskrip kita dan mempermudahkan manipulasi Backbone.History dan juga respon, tetapi tidak secara langsung memanipulasi sejarah yang telah wujud pada pelayar.

Backbone.View: Memproses Paparan Front-End

Merupakan representasi ‘kepingan-kepingan’ kecil html  yang terdapat pada sebuah halaman. Inti dari sebuah Backbone.View adalah bagaimana sebuah view dapat mewakili data (backbone.model atau backbone.collection) yang menjadi tanggung jawabnya, serta akibat tindakan-tindakan pengguna pada sebuah view dapat memberi kesan pada data (model atau collection).

Kenali BackboneJS

Tidak seperti kebanyakan bahasa pembangunan web yang lain, JavaScript belum lagi pernah ada sebuah rangka kerja yang benar-benar tulus dan kemas. Kebanyakan dari kita (developer) selalu menghadapi masalah untuk menempatkan javaskrip, baik di bahagian Header maupun Footer dan apabila mula untuk memautkan (bind) antara data dan Document Object Model (DOM), ianya bertambah serabut apabila fungsi aplikasi itu berkembang / bertambah.

Dalam hati ini, kita benar-benar menginginkan laman yang kita hasilkan betul-betul interaktif dan bernyawa. Dan catatan ini diharap dapat dijadikan titik tolak atau pintasan pemahaman untuk mekarnya pengetahuan kita dalam pengaturcaraan




Alhamdulillah, sejak dua menjak ini, keadaan ini mula berubah sedikit demi sedikit. Pelbagai konsep ditampilkan bagi penstrukturan kod dengan lebih teratur dan berkesan. Salah satu konsep yang biasa digunakan adalah model-view-controller dan konsep ini telah diusung kedalam BackboneJS. Cuma ada beberapa kekeliruan pada pustaka Javaskrip ini dimana peranan controller itu telah dimainkan oleh Router dan juga View.

Pustaka kecil Javaskrip ini mula dibina oleh Jeremy Ashkenas sekitar tahun 2010 yang bertujuan menstruktur semula susunan Javaskrip agar aplikasi yang dibangun mudah untuk diselenggara dan dikembang luas fungsinya. Dan secara asasnya, ianya dicipta untuk mengatasi kerumitan dalam membangun sebuah thick web application (aplikasi web dengan business logic yang cukup padat). Di dalam BackboneJS, terdapat 7 komponen dasar, yaitu :

• Backbone.Events
• Backbone.Model
• Backbone.Collection
• Backbone.Router
• Backbone.History
• Backbone.View
• Backbone.sync

Berikut adalah serba sedikit keterangan mengenainya:

M : Model serta Collection

Model merupakan kelas yang mengawal logik data atau keadaan aplikasi (application state). Seperti kebanyakan rangka-kerja yang lain Backbone.model bertujuan untuk menghubungkan aplikasi dengan pengkalan data (DB) melalui sambungan yang kelihatan abstrak (REST). Dengan adanya Backbone.model  pengurusan data akan lebih terkawal dengan pemanfaatan Collection. Kedua-duanya akan wujud didalam memori komputer Klien semasa aplikasi sedang berlangsung dan ianya akan terhapus dari memori apabila kita tidak lagi berinteraksi dengan aplikasi. BackboneJS juga menanggung hubungan yang persisten antara Server dan Backbone.model dan juga Backbone.Collection Yang menarik tentang backbone.model adalah sekiranya terdapat sebarang perubahan pada isi kandungan model, backboneJS menyediakan sebuah pendengar (listener) yang berperanan untuk bertindak balas terhadap sebarang perubahan.

V : View

Tanggungjawab utama view adalah mengkoordinasi interaksi antara pengguna dan khidmat aplikasi secara langsung. Interaksi keduanya dipermudahkan melalui pelbagai cara, termasuk penggunaan jQuery atau zeptoJS untuk mengelola acara DOM, memanggil data Backbone.model dan Backbone.collection secara langsung melalui `this.model` dan `this.collection`, dan penghasilan 'kepingan' HTML baru yang akan ditampilkan kepada pengguna semasa aplikasi kita bertindak balas terhadap perubahan yang dialami pada keadaan aplikasi (application state).


C: Controller

Tiada Controllers sebenarnya dalam backboneJS

Dikatakan peranan Router dan View boleh disifatkan sebagai Controller, tetapi sebenarnya tidak sama sekali. Tiada pelaksanaan yang benar-benar bersifat Controller secara arkitekturnya. Router bukanlah sebuah Controller. Ianya adalah pengawal masuk ke aplikasi anda. Dan View adalah untuk paparan bukan Controller juga.

Kesimpulan

Dengan saiz failnya yang kecil (4kb), ia berupaya untuk mengelolakan pembangunan aplikasi yang jauh lebih besar. Bagi membuktikan kemampuan pustaka kecil ini, di halaman web rasminya tersenarai berpuluh aplikasi yang berbagai ragam untuk memenuhi berbagai keperluan.

Buat yang sudah biasa dengan jQuery mungkin tiada masalah dalam memahami BackboneJS tetapi persepsi kita mengenai penyusunan Javaskrip itu sendiri akan berubah 180 darjah kerana ia sebenarnya diolah dari bahasa Ruby On Rails. Tiada lagi contoh "hello world" seperti kebiasaanya tapi diganti dengan "To Do Apps"