Apa kekuatan dan kelemahan dunia nyata dari banyak kerangka kerja berdasarkan backbone.js? [Tutup]

Semoga seseorang dapat berbagi pengalaman mereka dengan beberapa varian backbone.js terbaru yang muncul di luar sana. Saya memiliki pengalaman yang baik dengan backbone / garis bawah / memerlukan dalam beberapa proyek dan saya ingin mengambil langkah selanjutnya menuju solusi yang lebih maju untuk struktur aplikasi yang kompleks.

Saya tahu kerangka kerja berikut tersedia:

• Boneka
• Geppetto (berdasarkan Marionette)
• Chaplin , Chaplin - chaplin-boilerplate
• Tulang belakang
• Manajer Tata Letak
• Thorax
• Aura
• Luca
• Singool
• backstack
• UI tulang punggung

• hulk

• BTW - titik awal yang sangat baik untuk proyek skala besar

Dan mungkin saya melewatkan beberapa.

Ada pengantar singkat tentang perbedaan di sini:

• tautan bicara talkerdeck

tapi ini sangat umum. Saya bertanya-tanya apakah seseorang dapat berbagi pengalaman mereka dengan aplikasi kehidupan nyata menggunakan kerangka kerja ini.

Apa manfaat memilih satu dari yang lain? Kapan marionette akan menjadi solusi yang lebih baik daripada chaplin, atau mengapa vetebrae lebih baik untuk aplikasi tertentu, misalnya.

Tentu, jawaban yang jelas akan " menggunakan apa yang terbaik untuk kebutuhan Anda ", tetapi saya kurang pengalaman dengan kerangka kerja ini untuk mengetahui kekuatan / tujuan / keunggulan mereka atau skenario yang disukai.

Terima kasih!

Sunting 1: menemukan posting ini: Backbone.Marionette vs Backbone-Boilerplate

Sunting 2: Jawaban oleh Mathias schafer (Chaplin) melalui surat:

Singkatnya, struktur saat ini dekat dengan versi 1.0 karena sudah digunakan dalam produksi. Kami tidak berencana untuk menambah fitur baru yang besar atau merusak perubahan API hingga 1.0.

Marionette pasti perpustakaan paling komprehensif dan stabil di luar sana. Ini membahas beberapa aspek pengembangan aplikasi JS dengan Backbone. Misalnya, ia memiliki lapisan tampilan yang kuat yang membuat Backbone sendiri benar-benar kosong. Tentu saja, Anda akan menemukan bahwa beberapa aspek tidak akan memenuhi tuntutan Anda dan Anda mungkin merasa perlu untuk membuat struktur di sekitar Marionette.

Sebaliknya, Chaplin berfokus pada aspek yang agak kecil, tetapi sangat penting dari aplikasi Backbone, yaitu keseluruhan struktur aplikasi dan siklus hidup modul. Dalam hal ini Chaplin sangat opionated dan lebih seperti kerangka daripada perpustakaan (seperti dalam "kode Anda memanggil perpustakaan, kerangka kerja memanggil kode Anda"). Chaplin menyediakan beberapa kelas pusat yang berada di atas modul aplikasi individual dan mengontrol keadaan aplikasi secara keseluruhan. Ini memberi aplikasi Anda struktur konvensional seperti Ruby on Rails yang melakukannya misalnya.

Di Chaplin, Anda mendeklarasikan beberapa rute yang dipetakan ke pengontrol, dan Chaplin memulai pengontrol setelah rute cocok. Ini juga menangani pembuangan pengendali lama, dan menunjukkan dan menyembunyikan pandangan utama, yang seharusnya dibuat oleh pengontrol. Ini adalah ide dasar, tetapi Chaplin menangani detail yang jelek untuk membuat ini berjalan dengan lancar.

Ada dua prinsipal yang datang bersama dengan struktur ini: - Modularisasi, decoupling dan sandboxing - Komunikasi lintas-modul menggunakan Publish / Berlangganan dan Mediator (s)

Tentu saja pola-pola ini bukan hal baru di dunia pengembangan perangkat lunak, dan Chaplin bukan satu-satunya perpustakaan yang menerapkannya pada aplikasi Backbone.js.

Chaplin juga menyediakan perangkat tambahan untuk lapisan Tampilan, misalnya CollectionView yang sangat canggih, tetapi secara total tidak sebanyak Marionette dengan Wilayah dan Tata Letaknya. Tetapi relatif mudah untuk menulis kelas meta seperti itu menggunakan sarana yang disediakan Chaplin Views.

Sebagian besar (semua?) Kerangka yang Anda cari memecahkan masalah yang sama, tetapi mereka melakukannya dengan cara yang sedikit berbeda dengan tujuan yang sedikit berbeda.

Saya pikir adil untuk mengatakan bahwa semua proyek ini akan menyelesaikan masalah dalam kategori ini:

• Berikan serangkaian standar yang masuk akal
• Kurangi kode boilerplate
• Berikan struktur aplikasi di atas blok bangunan BackboneJS
• Ekstrak pola yang digunakan penulis di aplikasi mereka

Marionette, yang telah saya bangun sejak Desember 2011, memiliki beberapa tujuan dan cita-cita yang sangat berbeda, juga:

• Arsitektur aplikasi komposit
• Pengaruh pola olahpesan perusahaan
• Opsi modularisasi
• Penggunaan tambahan (tidak ada persyaratan semua atau tidak sama sekali)
• Tidak ada penguncian server
• Buatlah mudah untuk mengubah default-default itu
• Kode sebagai konfigurasi / konfigurasi berlebih

Saya tidak mengatakan tidak ada kerangka kerja lain yang memiliki tujuan yang sama. Tapi saya pikir keunikan Marionette berasal dari kombinasi tujuan-tujuan ini.

Arsitektur Aplikasi Komposit

Saya menghabiskan lebih dari 5 tahun bekerja di klien-tebal, sistem perangkat lunak terdistribusi menggunakan WinForms dan C #. Saya membuat aplikasi untuk desktop, laptop (smart-client), perangkat seluler dan aplikasi web, semuanya berbagi set fungsional inti dan bekerja dengan server yang sama back-end berkali-kali. Saat ini, saya belajar nilai dari modularisasi dan sangat cepat bergerak ke jalur desain aplikasi komposit.

Ide dasarnya adalah untuk "menyusun" pengalaman runtime aplikasi Anda dan memproses dari banyak potongan kecil yang tidak perlu saling mengenal. Mereka mendaftarkan diri dengan sistem aplikasi komposit keseluruhan dan kemudian mereka berkomunikasi melalui berbagai cara pesan dan panggilan terpisah.

Saya telah menulis sedikit tentang ini di blog saya, memperkenalkan Marionette sebagai arsitektur aplikasi komposit untuk Backbone:

• http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/
• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/

Antrian / Pola Pesan

Skala besar yang sama, sistem terdistribusi juga memanfaatkan antrian pesan, pola integrasi perusahaan (pola pesan), dan bus layanan untuk menangani pesan. Ini, lebih dari segalanya, memiliki pengaruh luar biasa pada pendekatan saya terhadap pengembangan perangkat lunak yang dipisahkan. Saya mulai melihat proses-tunggal, dalam-memori aplikasi WinForms dari perspektif ini, dan segera sisi server saya dan pengembangan aplikasi web mengambil pengaruh dari ini.

Ini secara langsung menerjemahkan bagaimana saya melihat desain aplikasi Backbone. Saya menyediakan agregator acara di Marionette, untuk objek aplikasi tingkat tinggi, dan untuk setiap modul yang Anda buat dalam aplikasi.

Saya berpikir tentang pesan yang dapat saya kirim di antara modul saya: pesan perintah, pesan acara, dan banyak lagi. Saya juga berpikir tentang komunikasi sisi server sebagai pesan dengan pola yang sama. Beberapa pola telah masuk ke Marionette, tetapi beberapa belum.

• http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
• http://lostechies.com/derickbailey/2012/04/03/revisiting-the-backbone-event-aggregator-lessons-learned/
• http://lostechies.com/derickbailey/2009/12/23/understanding-the-application-controller-through-object-messaging-patterns/ (kode WinForms, tetapi masih berlaku)

Modularisasi

Modularisasi kode sangat penting. Membuat paket kecil, enkapsulasi baik yang memiliki fokus tunggal dengan titik masuk dan keluar yang ditentukan dengan baik adalah suatu keharusan bagi sistem apa pun dengan ukuran dan kompleksitas yang signifikan.

Marionette menyediakan modularisasi langsung melalui moduledefinisi itu. Tetapi saya juga mengakui bahwa beberapa orang menyukai RequireJS dan ingin menggunakannya. Jadi saya memberikan build standar dan build yang kompatibel dengan RequireJS.

MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(Belum ada posting blog untuk ini)

Penggunaan Tambahan

Ini adalah salah satu filosofi inti yang saya gunakan untuk setiap bagian Marionette yang saya dapat: tidak ada persyaratan "semua atau tidak sama sekali" untuk penggunaan Marionette.

Backbone sendiri mengambil pendekatan yang sangat bertahap dan modular dengan semua objek blok pembangunnya. Anda bebas memilih mana yang ingin Anda gunakan, kapan. Saya sangat percaya pada prinsip ini dan berusaha untuk memastikan Marionette bekerja dengan cara yang sama.

Untuk itu, sebagian besar karya yang saya buat untuk Marionette dibangun untuk berdiri sendiri, untuk bekerja dengan potongan-potongan inti dari Backbone, dan untuk bekerja bersama lebih baik lagi.

Sebagai contoh, hampir setiap aplikasi Backbone perlu secara dinamis menampilkan tampilan Backbone di tempat tertentu di layar. Aplikasi juga perlu menangani penutupan tampilan lama dan membersihkan memori ketika yang baru ditempatkan. Di sinilah Marionette Regiondatang untuk bermain. Wilayah menangani kode boilerplate untuk mengambil tampilan, memanggil render di atasnya, dan memasukkan hasilnya ke DOM untuk Anda. Kemudian akan menutup tampilan itu dan membersihkannya untuk Anda, asalkan tampilan Anda memiliki metode "tutup" di atasnya.

MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

Tetapi Anda tidak diharuskan untuk menggunakan pandangan Marionette untuk menggunakan suatu wilayah. Satu-satunya persyaratan adalah bahwa Anda memperluas dari Backbone. Lihat di beberapa titik dalam rantai prototipe objek. Jika Anda memilih untuk memberikan closemetode, onShowmetode, atau lainnya, Wilayah Marionette akan memanggilnya untuk Anda pada waktu yang tepat.

• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
• http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

Tidak Ada Server Lock-in

Saya membangun aplikasi Backbone / Marionette di atas beragam teknologi server:

• ASP.NET MVC
• Ruby on Rails
• Ruby / Sinatra
• NodeJS / ExpressJS
• PHP / Slim
• Jawa
• Erlang
• ... dan banyak lagi

JavaScript adalah JavaScript, ketika harus dijalankan di browser. JavaScript sisi server juga mengagumkan, tetapi tidak memiliki efek atau pengaruh nol pada cara saya menulis JavaScript berbasis browser.

Karena keragaman dalam proyek yang saya bangun dan teknologi back-end yang digunakan klien saya, saya tidak bisa dan tidak akan mengunci Marionette ke tumpukan teknologi sisi server tunggal untuk alasan apa pun. Saya tidak akan menyediakan proyek boilerplate. Saya tidak akan memberikan permata ruby ​​atau paket npm. Saya ingin orang-orang mengerti bahwa Marionette tidak memerlukan server back-end tertentu. Ini JavaScript berbasis browser, dan back-end tidak masalah.

Tentu saja, saya sepenuhnya mendukung orang lain yang menyediakan paket untuk bahasa dan kerangka kerja mereka. Saya mencantumkan paket-paket itu di Wiki dan berharap orang-orang terus membangun lebih banyak paket sesuai kebutuhan. Tetapi itu adalah dukungan masyarakat, bukan dukungan langsung dari Marionette.

• https://github.com/derickbailey/backbone.marionette/wiki/Available-packages

Mudah Mengubah Defaultnya

Dalam upaya saya untuk mengurangi kode boilerplate dan memberikan default yang masuk akal (yang merupakan ide bahwa saya langsung "meminjam" dari Tim Branyen LayoutManager), saya menyadari perlunya pengembang lain untuk menggunakan implementasi yang sedikit berbeda dari yang saya lakukan.

Saya memberikan rendering berdasarkan <script>tag inline untuk templat, menggunakan templat Underscore.js secara default. Tetapi Anda dapat mengganti ini dengan mengubah objek Rendererdan / atau TempalteCachedi Marionette. Dua objek ini menyediakan inti dari kemampuan rendering, dan ada halaman wiki yang menunjukkan cara mengganti ini untuk mesin templating tertentu dan berbagai cara memuat template.

Dengan Marionette v0.9, itu menjadi lebih mudah. Misalnya, jika Anda ingin mengganti penggunaan blok skrip templat inline dengan templat yang sudah dikompilasi sebelumnya, Anda hanya perlu mengganti satu metode di Renderer:

Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

dan sekarang seluruh aplikasi akan menggunakan templat yang telah dikompilasi sebelumnya yang Anda lampirkan ke templateatribut tampilan Anda .

Saya bahkan menyediakan add-on Marionette.Async dengan v0.9 yang memungkinkan Anda untuk mendukung tampilan rendering secara tidak sinkron. Saya terus berupaya untuk membuatnya semudah mungkin untuk mengganti perilaku default di Marionette.

Konfigurasi Kode Sebagai

Saya penggemar "konvensi konfigurasi" dalam konteks tertentu. Ini adalah cara yang ampuh untuk menyelesaikan sesuatu, dan Marionette memberikan sedikit ini - meskipun tidak terlalu banyak, jujur. Banyak kerangka kerja lainnya - terutama LayoutManager - memberikan lebih banyak konvensi atas konfigurasi daripada Marionette.

Ini dilakukan dengan maksud dan tujuan.

Saya telah membangun cukup banyak plugin, kerangka kerja, add-on, dan aplikasi JavaScript untuk mengetahui kesulitan mencoba membuat konvensi bekerja dengan cara yang bermakna dan cepat. Ini dapat dilakukan dengan kecepatan, tetapi biasanya dengan biaya untuk mengubahnya.

Untuk itu, saya mengambil pendekatan "kode sebagai konfigurasi" ke Marionette. Saya tidak menyediakan banyak "konfigurasi" API di mana Anda dapat memberikan objek literal dengan nilai statis yang mengubah petak perilaku. Sebagai gantinya, saya mendokumentasikan metode yang dimiliki setiap objek - baik melalui kode sumber beranotasi dan melalui dokumentasi API yang sebenarnya - dengan maksud memberi tahu Anda cara mengubah Marionette agar berfungsi seperti yang Anda inginkan.

Dengan menyediakan API yang bersih dan jelas untuk objek Marionette, saya membuat situasi di mana mengganti perilaku objek tertentu atau Marionette secara keseluruhan relatif sederhana dan sangat fleksibel. Saya mengorbankan konfigurasi API "sederhana" untuk fleksibilitas menyediakan kode Anda sendiri untuk membuat hal-hal bekerja dengan cara yang Anda inginkan.

Anda tidak akan menemukan API "konfigurasi" atau "opsi" di Marionette. Tetapi Anda akan menemukan sejumlah besar metode yang masing-masing melayani tujuan yang sangat spesifik, dengan tanda tangan bersih, yang membuatnya mudah untuk mengubah cara kerja Marionette.

Saat ini saya menggunakan backbone dengan modul manajer tata letak dan setang sebagai mesin templating dan saya merasa sangat mudah untuk mengatur aplikasi kecil menggunakan backend Grails yang sudah ada. Sebelum mulai menggunakan manajer tata letak, saya membaca tentang Marionette dan Chaplin dan menurut saya keduanya sangat kuat tetapi kompleks. Kemudian saya ingat mengapa saya memilih backbone.js: kesederhanaan. Semua kerangka kerja itu menambahkan tulang punggung apa yang ditinggalkan oleh desain. Saya tidak mengatakan bahwa kerangka kerja itu buruk, tetapi jika saya memerlukan sesuatu yang lebih kompleks saya akan mencoba proyek lain, seperti bara.js atau sproutcore, karena mereka memiliki basis kode yang unik, ditulis dengan tujuan dalam pikiran pengembang mereka. Di sini kita memiliki kerangka kerja di atas yang lain. Tentu saja, tulang punggung adalah tulang punggung tidak hanya untuk membangun aplikasi, tetapi juga untuk menulis beberapa perpustakaan yang lebih kuat, tetapi satu-satunya hal yang saya pikir sangat buruk dengan itu adalah lapisan tampilan, karena tidak ada manajer tata letak dan kemungkinan tampilan bersarang. Dengan layout manager, celah itu terisi dengan cukup baik.

Jadi, jawaban saya untuk pertanyaan Anda adalah: mulai dari menggunakan backbone apa adanya, dan tanyakan pada diri sendiri apa yang hilang dan apa harapan Anda tentang kerangka kerja. Jika Anda menemukan ada terlalu banyak hal yang ditinggalkan oleh backbone, kemudian pergi dan mencarinya di kerangka lain dan memilih yang terdekat dengan kebutuhan Anda. Dan Jika Anda masih tidak yakin dengan pilihan, mungkin backbone bukan untuk Anda dan Anda harus mencari beberapa solusi lain (ember.js, sproutcore, ExtJs, JavaScript MVC semuanya baik). Jika Anda memiliki pengalaman dalam menulis aplikasi klien, Anda tidak benar-benar membutuhkan pengalaman pada semua kerangka kerja di luar sana untuk memilih yang tepat (untuk Anda, tentu saja)

Saya telah mempelajari berbagai kerangka kerja yang dibangun dengan Backbone.js dan membangun Vertebrae untuk sebuah proyek di HauteLook. Sasaran proyek termasuk ... pemuatan skrip dinamis, format modul AMD, manajemen ketergantungan, dibangun dengan sebagian besar pustaka sumber terbuka, susun kode dalam paket, optimalkan dan bangun untuk satu atau banyak aplikasi halaman tunggal, host pada server yang di-cache sepenuhnya, misal tidak ada server skrip sisi hanya menggunakan API untuk data, dan yang paling menyenangkan bagi saya, gunakan pengembangan yang didorong perilaku untuk proyek. Ada deskripsi tentang proyek di: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Masalah kami:

Perpustakaan yang dipilih (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) menyediakan pemuatan modul, manajemen dependensi, struktur aplikasi (untuk model, koleksi, tampilan dan rute), interaksi asinkron dengan API, berbagai utilitas dan objek untuk mengelola perilaku asinkron. , misalnya (Janji) Ditangguhkan, Callback. Logika yang tersisa yang dibutuhkan untuk menyelesaikan kerangka kerja meliputi:

• sebuah objek (model) untuk mengelola keadaan aplikasi satu halaman;
• seorang manajer tata letak untuk menyajikan, mengatur / transisi dan pandangan yang jelas, dan
• pengendali yang merespons rute, mendapatkan / mengatur status aplikasi, dan menyerahkan pekerjaan ke manajer tata letak.

Solusi kami (diimplementasikan dalam Vertebrae):

Manajer Negara Aplikasi -

Manajer aplikasi menyimpan data dalam memori dan juga menyimpan data dalam penyimpanan browser untuk menyediakan sumber daya untuk data / metadata umum. Juga menyediakan data (status) untuk merekonstruksi tampilan halaman berdasarkan interaksi sebelumnya (misalnya tab yang dipilih, filter yang diterapkan). Manajer status aplikasi menyediakan strategi sumber daya untuk mengambil status. Dimaksudkan untuk bertindak sebagai mesin negara.

Manajer Tata Letak -

Manajer tata letak memiliki satu atau banyak tampilan serta tujuan dokumen (DOM) untuk setiap tampilan (yang diberikan). Halaman mungkin berpindah di antara banyak tampilan, sehingga pengelola tata letak melacak status tampilan, misalnya yang ditampilkan, tidak ditampilkan, ditampilkan, tidak ditampilkan. Anda dapat menggunakan pengelola tata letak untuk malas memuat dan merender tampilan (terpisah) yang kemungkinan besar diminta oleh pengunjung situs, mis. Perubahan tab pada halaman. Transisi antara status tampilan dikelola oleh objek ini. Seluruh tata letak dapat dihapus sehingga objek melihat dan binding-nya dihapus, menyiapkan objek-objek ini untuk pengumpulan sampah (mencegah kebocoran memori). Manajer tata letak juga mengkomunikasikan status tampilan dengan pengontrol.

Pengendali -

Objek pengontrol dipanggil oleh fungsi pengendali rute, dan bertanggung jawab untuk mendapatkan status yang relevan (model aplikasi) untuk menghasilkan halaman (tata letak), (juga bertanggung jawab untuk mengatur status saat rute berubah). Pengontrol meneruskan data dependen (model / koleksi) dan membuat objek tampilan untuk halaman yang diminta ke manajer tata letak. Sebagai efek samping penggunaan pengontrol mencegah objek rute menjadi kembung dan kusut. Rute harus memetakan ke controller yang kemudian memulai tampilan halaman, menjaga fungsi penanganan rute tetap ramping.

Aplikasi Todos di-host baik dalam mode dev dan dioptimalkan pada ...

• http://vertebrae-framework.herokuapp.com/
• http://vertebrae-optimized.herokuapp.com/

Banyak konsep dalam kerangka kerja lain yang dipinjam, misalnya kebutuhan untuk merusak tampilan untuk melihat kebocoran memori seperti yang ditunjukkan oleh Derick Bailey - http://lostechies.com/derickbailey/ ; Manajer Tata Letak oleh Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

Singkatnya, Backbone.js dimaksudkan untuk menjadi alat dalam aplikasi Anda, perpustakaan Backbone.js tidak menyediakan semua arsitektur yang Anda perlukan untuk membangun sebuah aplikasi, tetapi memberikan interaksi yang hebat dengan API dan struktur kode ... Tampilan (bertindak seperti pengontrol juga) dan Model dan Koleksi lapisan data Anda, dan akhirnya Rute. Kami membangun Vertebra untuk memenuhi tujuan proyek kami, dan memutuskan untuk mengekstrak kode tersebut sebagai kerangka kerja bagi orang lain untuk digunakan, dipelajari, atau apa pun.

Jawaban atas pertanyaan Anda menurut saya adalah belajar dari semua kerangka kerja dan menggunakan apa yang Anda butuhkan untuk memenuhi tujuan Anda, jika Anda menemukan bahwa tujuan proyek Anda cocok dengan salah satu kerangka kerja yang dibangun dengan Backbone lalu bagus, jika tidak, buat kerangka kerja Anda sendiri ada banyak contoh bagus yang dibagikan oleh komunitas. Atau jika Anda menemukan diri Anda sedikit hilang ke arah aplikasi Anda maka pilihlah sesuatu yang lebih keras dan terstruktur mungkin Ember.js. Yang hebat adalah ada banyak pilihan untuk membantu Anda membuat kode menggunakan pola (MVX) seperti MVC dengan JavaScript.

Saya mengembangkan kerangka kerja Luca saat bekerja di BenchPrep di mana kami menggunakannya untuk mengembangkan beberapa aplikasi halaman tunggal besar di atas perpustakaan backbone.js.

Saya telah bekerja dengan ExtJS selama beberapa tahun sebelumnya dan telah mencuri konsep favorit saya dari kerangka itu seperti arsitektur berbasis komponen di mana Anda mengembangkan pandangan Anda sebagai komponen mandiri dan kemudian bergabung bersama-sama dengan komponen lain menggunakan tampilan wadah. Dan karena sangat didasarkan pada konfigurasi, mengembangkan aplikasi di Luca terasa sangat mirip dengan menggambarkan objek dengan JSON.

Satu keuntungan dari pendekatan ini adalah kemampuan untuk menggunakan kembali komponen di beberapa aplikasi atau di berbagai tempat di aplikasi Anda, dengan hanya dengan sedikit perubahan menggunakan perluasan Backbone. Juga sangat mudah untuk bereksperimen dengan banyak tata letak / presentasi komponen yang berbeda dengan hanya membuat sedikit perubahan pada konfigurasi JSON.

Selain berbagai fungsi penolong / utilitas, Luca Ships dengan banyak turunan Backbone tingkat tinggi yang dapat Anda gabungkan bersama dengan cara apa pun yang dapat dibayangkan untuk membangun UI yang kompleks.

Tampilan, Komponen, Wadah

• Model Augmented, Lihat, Koleksi, kelas Router
• Opsi konfigurasi yang memfasilitasi komunikasi antara Model, Koleksi, Tampilan, Aplikasi dan manajernya masing-masing.
• Wadah (Tata Letak Split / Kolom, Tata Letak Kotak, Tampilan Tab, Tampilan Kartu / Wisaya)
• FormView dengan semua komponen bidang standar, dan pembantu untuk menyinkronkan dengan Backbone.Model
• GridView, untuk menghasilkan elemen grid yang dapat digulir dari Luca.Collection
• CollectionView, untuk menghasilkan tampilan berdasarkan koleksi
• Bilah Alat / Tombol

Twitter Bootstrap Styles dan Markup Gratis

• Luca bermain sangat baik dengan kerangka bootstrap Twitter. Cukup dengan mengatur Luca.enableBootstrap = true, dan termasuk CSS, komponen Anda (seperti tampilan tab, bilah alat, tombol, formulir, bidang, kisi, dll) akan secara otomatis menggunakan markup yang kompatibel dengan Twitter Bootstrap dan konvensi kelas CSS.
• Menggunakan sistem Grid untuk tata letak, dan merespons sebagian besar kelas css bootstrap dasar dengan cara yang cerdas
• Komponen Luca.Viewport dan GridLayout dirancang untuk bekerja dengan sistem grid responsif, fluid, atau statis bootstrap.
• Bertujuan untuk memberikan kecocokan satu lawan satu untuk komponen bootstrap twitter, untuk mewakili mereka sebagai Tampilan Backbone yang dapat dikonfigurasi

Komponen Aplikasi

• Mesin negara berbasis Backbone.Model menyediakan metode pengambil / penyetel dan peristiwa perubahan atribut sebagai gaya aliran kontrol aplikasi
• Komponen Pengontrol Terintegrasi yang menyembunyikan / menampilkan halaman aplikasi sebagai respons terhadap peristiwa Backbone.Router atau Mesin Negara
• Integrated Collection Manager yang melacak koleksi yang telah Anda buat, memungkinkan Anda untuk mengaturnya, mengelompokkannya, menetapkan parameter default untuknya
• Socket Manager yang merupakan lapisan abstraksi di atas layanan websocket yang membuat push semudah Backbone
• Router acara Keyboard yang memicu peristiwa utama bernama pada komponen yang peduli untuk menanggapi peristiwa tersebut

Peningkatan Koleksi dan Model

• Koleksi didasarkan pada backbone-query , yang menyediakan antarmuka kueri yang sangat mirip dengan mongoDb
• aktifkan Backbone.sync penyimpanan lokal hanya dengan mengatur collection.localStorage = true
• populasi koleksi otomatis yang datanya di-boot pada beban halaman
• metode cache / properti yang dihitung. cache hasil metode pengumpulan, dan kedaluwarsa cache sebagai respons untuk mengubah / menambah / menghapus acara pada koleksi atau modelnya
• properti yang dihitung pada model. membangun atribut berdasarkan fungsi yang kompleks, dan secara otomatis memperbarui nilai yang dihitung sebagai respons terhadap perubahan

Acara dan Pengait

Komponen Luca lebih liberal dengan peristiwa yang mereka pancarkan dibandingkan dengan komponen Backbone stok. Mereka akan memancarkan peristiwa seperti sebelumnya: inisialisasi, setelah: inisialisasi, sebelum: render, setelah: render, aktivasi, pertama: aktivasi, deaktivasi, pertama: deaktivasi, dan ini memungkinkan Anda untuk lebih menyempurnakan perilaku komponen Anda. Plus, dengan mendefinisikan suatu peristiwa dalam porperty @hooks pada tampilan Anda, ia akan secara otomatis memanggil fungsi yang sama namanya untuk Anda jika ada. Ini mencegah banyak kode gaya panggilan balik yang meningkatkan keterbacaan.

Anda juga dapat mengonfigurasi kelas Luca.Events untuk menerbitkan acara ke saluran publikasi / berlangganan global, yang membuat pembuatan aplikasi besar lebih mudah dan membantu dalam komunikasi antar modul.

Permata Ruby

Luca dikembangkan secara khusus saat bekerja melawan Rails dan Sinatra APIs dan karena ini saat ini dioptimalkan untuk tumpukan tertentu, tetapi itu sama sekali tidak mengunci Anda ke server tertentu.

Luca didistribusikan sebagai bagian dari Ruby Gem yang dikonfigurasi untuk bekerja pada pipa aset, atau sebagai file JS yang dapat diunduh.

Anda tidak diharuskan menggunakan Rails, atau Sinatra. Tetapi jika Anda melakukannya, saya telah memasukkan banyak hal berguna:

• File dengan ekstensi .luca diproses sebagai HAML dengan interpolasi variabel gaya JST. (setara dengan .jst.ejs.haml) oleh pipa aset
• Test Harness untuk browser, atau Unit Test berbasis Jasmine tanpa kepala bersama dengan banyak pembantu tes Backbone dan Underscore.
• Titik akhir API untuk toolset pengembangan yang dikirimkan bersama Luca (lebih lanjut tentang ini nanti)
• Titik akhir API yang memungkinkan Anda menggunakan Redis sebagai mesin penyimpanan schemaless untuk Luca. Koleksi dengan konfigurasi minimal

Alat Pengembangan

• Aplikasi Luca dapat mengaktifkan konsol naskah dalam browser dengan bantuan dan perintah khusus Luca yang membantu dalam memantau, memeriksa, men-debug aplikasi dan komponen Luca

• Dengan bantuan Rails Gem, dan editor komponen berbasis Luca CodeMirror, Anda dapat mengedit kode sumber Luca Framework serta komponen spesifik aplikasi langsung di browser, menggunakan Coffeescript. Anda akan melihat umpan balik segera sebagai tanggapan terhadap suntingan Anda, dengan contoh objek yang terpengaruh disegarkan dengan prototipe yang diperbarui, dan Anda dapat menyimpan perubahan Anda ke disk.

• The Component Tester adalah kotak pasir langsung untuk bermain dengan komponen yang membentuk aplikasi Anda secara terpisah. Ini memberi Anda alat untuk memodifikasi prototipe komponen, mengatur dependensinya, dan mengkonfigurasi komponen. Komponen akan merender ulang segera setiap kali Anda mengedit. Anda dapat melihat dan mengedit markup yang dihasilkan komponen, serta CSS langsung di browser dan melihat perubahan Anda segera. Ini membuatnya menjadi alat eksperimen yang sangat berharga.

• Penguji Komponen akan segera diintegrasikan dengan Jasmine sehingga Anda dapat melihat hasil pengujian unit komponen Anda secara langsung saat Anda mengedit kode mereka.

Luca sedang dalam proses, tetapi mempertahankan API yang stabil (belum 1.0) dan telah digunakan di beberapa aplikasi produksi besar. Ini jelas merupakan kerangka kerja yang sangat keras, tetapi saya sedang berupaya membuatnya lebih modular. Saya aktif mengerjakan komponen dokumentasi dan sampel.

Saya adalah rekan penulis Chaplin dan saya telah menulis perbandingan mendalam antara Chaplin.js dan Marionette.js:

http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/

Ini bukan "baku tembak" tetapi mencoba menjelaskan kedua pendekatan secara seimbang.