Jakie są mocne i słabe strony wielu frameworków opartych na backbone.js? [Zamknięte]

Mam nadzieję, że ktoś może podzielić się swoimi doświadczeniami z niektórymi najnowszymi pojawiającymi się wariantami backbone.js. Mam dobre doświadczenia ze szkieletem / podkreśleniem / wymaganiem w kilku projektach i chciałbym zrobić kolejny krok w kierunku bardziej zaawansowanych rozwiązań dla złożonej struktury aplikacji.

Wiem, że dostępne są następujące ramy:

• Marionetka
• Geppetto (na podstawie Marionetki)
• Chaplin , Chaplin - płyta chaplin-kocioł
• Kręgi
• LayoutManager
• Tułów
• Aura
• Luca
• Singool
• backstack
• Interfejs sieci szkieletowej

• ponton

• BTW - doskonały punkt wyjścia dla projektu na dużą skalę

I pewnie kilka mi brakowało.

Oto krótkie wprowadzenie na temat różnic:

• link do rozmowy z głośnikiem

ale to jest bardzo ogólne. Zastanawiałem się, czy ktoś może podzielić się swoim doświadczeniem z aplikacjami z życia codziennego, używając tych ram.

Jaka jest korzyść z wyboru jednego nad drugim? Kiedy marionetka będzie lepszym rozwiązaniem niż chaplin, lub dlaczego na przykład vetebrae jest lepsza w niektórych zastosowaniach.

Jasne, oczywistą odpowiedzią będzie „ użyj tego, co najlepiej dla twoich potrzeb ”, ale brakuje mi doświadczenia z tymi ramami, aby poznać ich siłę / cel / zalety lub preferowane scenariusze.

Dzięki!

Edytuj 1: Znaleziono ten post: Backbone.Marionette vs. Backbone-Boilerplate

Edycja 2: Odpowiedz Mathias schafer (Chaplin) pocztą:

Krótko mówiąc, obecna struktura jest zbliżona do wersji 1.0, ponieważ jest już używana w produkcji. Nie planujemy dodawać dużych nowych funkcji ani przerywać zmian API do 1.0.

Marionetka jest z pewnością najbardziej wszechstronną i stabilną biblioteką na rynku. Zajmuje się kilkoma aspektami rozwoju aplikacji JS za pomocą Backbone. Na przykład ma silną warstwę widoku, która sama Szkielet pozostawia całkowicie pustkę. Oczywiście przekonasz się, że niektóre aspekty nie spełnią twoich wymagań i możesz poczuć potrzebę stworzenia struktury wokół Marionetki.

W przeciwieństwie do tego Chaplin koncentruje się na dość małym, ale bardzo ważnym aspekcie aplikacji szkieletowych, a mianowicie na ogólnej strukturze aplikacji i cyklu życia modułu. Pod tym względem Chaplin jest bardzo funkcjonalny i bardziej przypomina framework niż bibliotekę (jak w „twoim kodzie wywołuje bibliotekę, frameworku twój kod”). Chaplin zapewnia niektóre centralne klasy, które znajdują się nad poszczególnymi modułami aplikacji i kontrolują ogólny stan aplikacji. To daje Twojej aplikacji konwencjonalną strukturę, taką jak na przykład Ruby on Rails.

W Chaplin deklarujesz niektóre trasy, które są mapowane do kontrolerów, a Chaplin uruchamia kontroler po dopasowaniu trasy. Zajmuje się także usuwaniem starych kontrolerów oraz pokazywaniem i ukrywaniem głównych widoków, które kontroler ma stworzyć. Jest to podstawowy pomysł, ale Chaplin dba o brzydkie szczegóły, aby płynnie działał.

Istnieją dwie zasady związane z tą strukturą: - Modularyzacja, odsprzęganie i sandboxing - Komunikacja między modułami za pomocą Publish / Subscribe i Mediator (s)

Oczywiście wzorce te nie są nowe w świecie tworzenia oprogramowania, a Chaplin nie jest jedyną biblioteką, która stosuje je do aplikacji Backbone.js.

Chaplin zapewnia również ulepszenia dla warstwy Widok, na przykład wysoce zaawansowany CollectionView, ale w sumie nie tak bardzo jak Marionetka z jej Regionami i Układami. Ale stosunkowo łatwo jest pisać takie meta-klasy za pomocą środków, które zapewniają widoki Chaplina.

Większość (wszystkich?) Ram, na które patrzysz, rozwiązuje te same problemy, ale robią to w nieco inny sposób z nieco innymi celami.

Myślę, że można śmiało powiedzieć, że wszystkie te projekty rozwiązałyby problemy w tych kategoriach:

• Podaj rozsądny zestaw wartości domyślnych
• Zredukuj kod płyty kotłowej
• Zapewnij strukturę aplikacji na blokach konstrukcyjnych BackboneJS
• Wyodrębnij wzorce, których autorzy używają w swoich aplikacjach

Marionetka, którą buduję od grudnia 2011 roku, ma również na myśli kilka bardzo wyraźnych celów i ideałów:

• Architektura aplikacji złożonych
• Wpływ wzorca komunikatów korporacyjnych
• Opcje modularyzacji
• Zastosowanie przyrostowe (brak wymogu „wszystko albo nic”)
• Brak blokady serwera
• Ułatw sobie zmianę tych ustawień domyślnych
• Kod jako konfiguracja / konfiguracja ponad

Nie twierdzę, że żadne inne ramy nie mają tych samych celów. Myślę jednak, że wyjątkowość Marionetki wynika z połączenia tych celów.

Architektura aplikacji złożonych

Spędziłem ponad 5 lat pracując w grubych klientach, rozproszonych systemach oprogramowania przy użyciu WinForm i C #. Tworzyłem aplikacje na komputery stacjonarne, laptopy (smart-client), urządzenia mobilne i aplikacje internetowe, wszystkie współużytkują podstawowy zestaw funkcjonalny i wiele razy współpracują z tym samym zapleczem serwera. W tym czasie poznałem wartość modularyzacji i bardzo szybko przeszedłem ścieżkę projektowania aplikacji złożonych.

Podstawową ideą jest „skomponowanie” środowiska wykonawczego aplikacji i przetworzenie go z wielu mniejszych pojedynczych elementów, które niekoniecznie się znają. Rejestrują się w całym złożonym systemie aplikacji, a następnie komunikują się za pomocą różnych środków oddzielonych od siebie wiadomości i połączeń.

Pisałem o tym trochę na swoim blogu, przedstawiając Marionette jako architekturę aplikacji złożonej dla 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/

Kolejki / wzory wiadomości

W tej samej dużej skali systemy rozproszone korzystały również z kolejkowania wiadomości, wzorców integracji w przedsiębiorstwie (wzorców przesyłania komunikatów) i magistrali usług do obsługi komunikatów. To, bardziej niż cokolwiek innego, miało ogromny wpływ na moje podejście do oddzielnego tworzenia oprogramowania. Z tej perspektywy zacząłem widzieć jednoprocesowe aplikacje WinForm w pamięci i wkrótce mój wpływ na serwer i tworzenie aplikacji internetowych wpłynęły na to.

To bezpośrednio przełożyło się na moje spojrzenie na projekt aplikacji Backbone. Udostępniam agregator zdarzeń w Marionette, zarówno dla obiektu aplikacji wysokiego poziomu, jak i dla każdego modułu, który tworzysz w aplikacji.

Myślę o komunikatach, które mogę wysyłać między moimi modułami: komunikaty poleceń, komunikaty o zdarzeniach i inne. Myślę też o komunikacji po stronie serwera jako wiadomościach o tych samych wzorcach. Niektóre wzory już dotarły do ​​Marionetki, ale niektóre jeszcze nie.

• 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/ (kod WinForms, ale nadal obowiązuje)

Modularyzacja

Modularyzacja kodu jest niezwykle ważna. Tworzenie małych, dobrze zamkniętych pakietów, które mają szczególny nacisk z dobrze zdefiniowanymi punktami wejścia i wyjścia, jest koniecznością dla każdego systemu o dowolnej wielkości i złożoności.

Marionetka zapewnia modularyzację bezpośrednio poprzez jej moduledefinicje. Ale zdaję sobie również sprawę, że niektórzy ludzie lubią RequireJS i chcą z tego skorzystać. Zapewniam więc zarówno kompilację standardową, jak i kompilację zgodną z RequireJS.

MyApp = new Backbone.Marionette.Application();

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

  // your module code goes here

});

(Na razie brak dostępnego postu na blogu)

Zastosowanie przyrostowe

Jest to jedna z podstawowych filozofii, w których piekę każdą część marionetki, w której mogę: nie ma wymogu „wszystko albo nic” do używania marionetki.

Sam Szkielet ma bardzo inkrementalne i modułowe podejście do wszystkich swoich obiektów budulcowych. Możesz wybrać, które z nich chcesz użyć, kiedy. Mocno wierzę w tę zasadę i staram się, aby Marionetka działała w ten sam sposób.

W tym celu większość elementów, które wbudowałem w Marionetkę, zbudowano tak, aby działały samodzielnie, pracowały z podstawowymi częściami Kręgosłupa i współpracowały jeszcze lepiej.

Na przykład prawie każda aplikacja sieci szkieletowej musi dynamicznie pokazywać widok sieci szkieletowej w określonym miejscu na ekranie. Aplikacje muszą także obsługiwać zamykanie starych widoków i czyszczenie pamięci po zainstalowaniu nowego. To tutaj Regionprzychodzi grać Marionetka . Region obsługuje główny kod wyświetlania widoku, wywoływania renderowania i umieszczania wyniku w DOM. Następnie zamknie ten widok i wyczyści go dla Ciebie, pod warunkiem, że Twój widok ma metodę „Zamknij”.

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

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

Ale nie musisz korzystać z widoków Marionetki, aby korzystać z regionu. Jedynym wymaganiem jest rozszerzenie z Backbone.View w pewnym momencie łańcucha prototypowego obiektu. Jeśli zdecydujesz się podać closemetodę, onShowmetodę lub inne, Region Marionetek zadzwoni po ciebie w odpowiednim czasie.

• 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/

Brak blokady serwera

Tworzę aplikacje Backbone / Marionette na bazie wielu różnych technologii serwerowych:

• ASP.NET MVC
• Ruby on Rails
• Ruby / Sinatra
• NodeJS / ExpressJS
• PHP / Slim
• Jawa
• Erlang
• ... i więcej

JavaScript to JavaScript, jeśli chodzi o działanie w przeglądarce. JavaScript po stronie serwera jest również niesamowity, ale ma zerowy wpływ lub wpływ na to, jak piszę JavaScript w przeglądarce.

Ze względu na różnorodność projektów, które zbudowałem oraz technologii zaplecza, z których korzystają moi klienci, nie mogę i nie zablokuję Marionette w stosie technologii po jednym serwerze z jakiegokolwiek powodu. Nie dostarczę projektu płyty kotłowej. Nie dostarczę rubinowego klejnotu ani pakietu npm. Chcę, aby ludzie zrozumieli, że Marionette nie wymaga określonego serwera zaplecza. Jest oparty na przeglądarce JavaScript, a zaplecze nie ma znaczenia.

Oczywiście w pełni popieram inne osoby dostarczające pakiety dla ich języka i frameworka. Wymieniam te pakiety na Wiki i mam nadzieję, że ludzie będą nadal budować więcej pakietów, gdy tylko będą tego potrzebować. Ale to wsparcie społeczności, a nie bezpośrednie wsparcie Marionetki.

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

Łatwo zmień ustawienia domyślne

W moich staraniach o ograniczenie kodu podstawowego i zapewnienie rozsądnych wartości domyślnych (jest to pomysł, który „pożyczyłem” bezpośrednio od narzędzia LayoutManager Tima Branyena), zdaję sobie sprawę z potrzeby stosowania przez innych programistów nieco innych implementacji niż ja.

Zapewniam renderowanie w oparciu o <script>tagi wbudowane dla szablonów, domyślnie używając szablonów Underscore.js. Ale możesz to zastąpić, zmieniając Rendereri / lub TempalteCacheobiekty w Marionetce. Te dwa obiekty stanowią rdzeń możliwości renderowania, a istnieją strony wiki, które pokazują, jak to zmienić dla określonych silników szablonów i różnych sposobów ładowania szablonów.

Dzięki wersji 0.9 Marionetki jest jeszcze łatwiej. Na przykład, jeśli chcesz zastąpić użycie wbudowanych bloków skryptów szablonów wstępnie skompilowanymi szablonami, musisz zastąpić tylko jedną metodę w module renderującym:

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

a teraz cała aplikacja będzie korzystać ze wstępnie skompilowanych szablonów, które dołączasz do templateatrybutu widoku .

Udostępniam nawet dodatek Marionette.Async z wersją v0.9, który pozwala na asynchroniczne wyświetlanie widoków. Nieustannie staram się jak najłatwiej zastąpić domyślne zachowania w Marionette.

Kod jako konfiguracja

Jestem fanem „konwencji nad konfiguracją” w niektórych kontekstach. Jest to potężny sposób na załatwienie sprawy, a Marionetka zapewnia trochę tego - choć nie za dużo, szczerze mówiąc. Wiele innych frameworków - zwłaszcza LayoutManager - zapewnia więcej konwencji w zakresie konfiguracji niż Marionette.

Odbywa się to celowo i celowo.

Zbudowałem wystarczającą liczbę wtyczek JavaScript, frameworków, dodatków i aplikacji, aby poznać ból związany z próbą uzyskania konwencji w sposób znaczący i szybki. Można to zrobić z szybkością, ale zwykle kosztem możliwości jej zmiany.

W tym celu podchodzę do Marionette metodą „kodowania jako konfiguracji”. Nie udostępniam wielu interfejsów API „konfiguracji”, w których można podać literał obiektu o wartościach statycznych, które zmieniają zakres zachowań. Zamiast tego dokumentuję metody, które posiada każdy obiekt - zarówno za pomocą opatrzonego adnotacjami kodu źródłowego, jak i faktycznej dokumentacji API - z zamiarem powiedzenia Ci, jak zmienić Marionette, aby działała tak, jak chcesz.

Zapewniając czysty i przejrzysty interfejs API dla obiektów marionetek, tworzę sytuację, w której zastąpienie zachowania określonego obiektu lub marionetki jako całości jest stosunkowo proste i bardzo elastyczne. Poświęcam „prostą” konfigurację API wymagającą elastyczności dostarczania własnego kodu, aby wszystko działało tak, jak chcesz.

W Marionette nie znajdziesz interfejsu API „konfiguruj” ani „opcji”. Ale znajdziesz wiele metod, z których każda służy bardzo konkretnemu celowi, z czystymi podpisami, które ułatwiają zmianę sposobu działania Marionetki.

Obecnie używam szkieletu z modułem menedżera układu i kierownicą jako silnikiem szablonów i bardzo łatwo było skonfigurować małą aplikację przy użyciu już istniejącego zaplecza Grails. Zanim zacząłem używać menedżera układu, przeczytałem o Marionette i Chaplinie i oba wydawały mi się naprawdę potężne, ale złożone. Potem przypomniałem sobie, dlaczego pierwotnie wybrałem backbone.js: prostota. Wszystkie te frameworki dodają to, co szkielet pominął z założenia. Nie twierdzę, że framework jest zły, ale jeśli potrzebuję czegoś bardziej złożonego, wypróbuję inne projekty, takie jak ember.js lub sproutcore, ponieważ mają one unikalną bazę kodową, napisaną z myślą o programistach. Tutaj mamy ramy na innym. Oczywiście szkielet jest kręgosłupem nie tylko do budowania aplikacji, ale także do pisania bardziej rozbudowanej biblioteki, ale jedyne, co wydaje mi się bardzo słabe, to warstwa widoku, ponieważ brakuje menedżera układu i możliwości zagnieżdżania widoków. W menedżerze układu ta luka jest dość dobrze wypełniona.

Tak więc, moja odpowiedź na twoje pytanie brzmi: zacznij od używania szkieletu w obecnej postaci i zadaj sobie pytanie, czego brakuje i jakie były twoje oczekiwania dotyczące frameworka. Jeśli okaże się, że jest zbyt wiele rzeczy, które zostały pominięte przez kręgosłup, to poszukaj ich w innych ramach i wybierz ten, który jest najbliższy Twoim potrzebom. A jeśli nadal nie masz pewności co do wyboru, być może kręgosłup nie jest dla Ciebie i musisz poszukać innego rozwiązania (ember.js, sproutcore, ExtJs, JavaScript MVC są dobre). Jeśli masz doświadczenie w pisaniu aplikacji klienckich, tak naprawdę nie potrzebujesz doświadczenia we wszystkich ramach, aby wybrać odpowiedni (oczywiście dla ciebie)

Przestudiowałem różne kompilacje frameworków za pomocą Backbone.js i zbudowałem kręgi dla projektu w HauteLook. Cele projektu obejmowały ... dynamiczne ładowanie skryptu, format modułu AMD, zarządzanie zależnościami, budowanie przy użyciu głównie bibliotek typu open source, organizowanie kodu w pakietach, optymalizację i kompilację dla jednej lub wielu aplikacji jednostronicowych, hostowanie na serwerze w pełni buforowanym, np. Bez serwera - skrypty boczne używające tylko interfejsu API do danych, a dla mnie najśmieszniejsze to projektowanie oparte na zachowaniu. Opis projektu znajduje się na stronie : http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Nasz problem:

Wybrane biblioteki (jQuery, Underscore.js, Backbone.js, RequireJS, Mustache) zapewniają ładowanie modułu, zarządzanie zależnościami, strukturę aplikacji (dla modeli, kolekcji, widoków i tras), asynchroniczne interakcje z API, różne narzędzia i obiekty do zarządzania zachowaniami asynchronicznymi , np. (Obietnice) Odroczone, Oddzwanianie. Pozostała logika potrzebna do ukończenia frameworka obejmuje:

• obiekt (model) do zarządzania stanem aplikacji jednostronicowej;
• menedżer układu do prezentacji, aranżacji / przejścia i czyszczenia widoków oraz
• kontrolery reagujące na trasy, pobierające / ustawiające stan aplikacji i przekazujące pracę menedżerowi układu.

Nasze rozwiązania (wdrożone w kręgach):

Menedżer stanu aplikacji -

Menedżer aplikacji przechowuje dane w pamięci, a także przechowuje dane w pamięci przeglądarki, aby zapewnić zasoby dla wspólnych danych / metadanych. Dostarcza również dane (stan) do odtworzenia wyświetleń strony na podstawie wcześniejszych interakcji (np. Wybrana karta, zastosowane filtry). Menedżer stanu aplikacji zapewnia strategię dotyczącą zasobów w celu odzyskania stanu. Przeznaczony do działania jako maszyna stanowa.

Menedżer układu -

Menedżer układu ma jeden lub wiele widoków, a także miejsca docelowe dokumentów (DOM) dla każdego (renderowanego) widoku. Strona może przechodzić między wieloma widokami, więc menedżer układu śledzi stany widoku, np. Renderowane, nierenderowane, wyświetlane, nie wyświetlane. Możesz użyć menedżera układu do leniwego ładowania i renderowania (odłączonych) widoków, o które użytkownik witryny prawdopodobnie poprosi, np. Zmiany tabulatorów na stronie. Przejście między stanami widoku jest zarządzane przez ten obiekt. Cały układ można wyczyścić, aby usunąć obiekty widoku i ich powiązania, przygotowując te obiekty do wyrzucania elementów bezużytecznych (zapobiegając wyciekom pamięci). Menedżer układu komunikuje również stan widoku z kontrolerem (kontrolerami).

Kontroler -

Obiekt kontrolera jest wywoływany przez funkcję procedury obsługi trasy i jest odpowiedzialny za uzyskanie odpowiedniego stanu (modele aplikacji) w celu wygenerowania strony (układu), (również odpowiedzialny za ustawienie stanu, gdy zmieniają się trasy). Kontroler przekazuje zależne dane (modele / kolekcje) i konstruuje obiekty widoku dla żądanej strony do menedżera układu. Jako efekt uboczny użycie kontrolerów zapobiega rozdęciu i splątaniu obiektu trasy. Trasa powinna zostać odwzorowana na kontroler, który następnie uruchamia widok strony, utrzymując wąskie funkcje obsługi trasy.

Aplikacja Todos jest hostowana zarówno w trybie deweloperskim, jak i zoptymalizowana na Heroku ...

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

Wiele pojęć z innych frameworków jest zapożyczonych, np. Potrzeba przeznaczenia widoków w celu podglądu wycieków pamięci, jak wskazał Derick Bailey - http://lostechies.com/derickbailey/ ; Menedżer układu autorstwa Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

Podsumowując, Backbone.js ma być narzędziem w Twojej aplikacji, biblioteka Backbone.js nie zapewnia całej architektury potrzebnej do zbudowania aplikacji, ale zapewnia świetne interakcje z interfejsem API i solidną strukturą kodu dla ... Widoki (działają również jak kontrolery) oraz modele i kolekcje warstwy danych, a na koniec trasy. Zbudowaliśmy Kręgi, aby opracować cele naszego projektu i postanowiliśmy wyodrębnić kod jako platformę dla innych, aby mogli go używać, uczyć się lub cokolwiek innego.

Moim zdaniem odpowiedź na twoje pytanie polega na tym, aby uczyć się ze wszystkich frameworków i wykorzystywać to, czego potrzebujesz, aby osiągnąć swoje cele, jeśli stwierdzisz, że cele twojego projektu ściśle pasują do jednego z frameworków zbudowanych z Backbone, to świetnie, w przeciwnym razie zbuduj swój własny framework społeczność udostępnia wspaniałe przykłady. Lub jeśli czujesz się trochę zagubiony w kierunku aplikacji, wybierz coś bardziej upartego i uporządkowanego, być może Ember.js. Świetną rzeczą jest to, że istnieje duży wybór opcji, które pomogą Ci kodować za pomocą (MVX) wzorca podobnego do MVC z JavaScript.

Opracowałem framework Luca podczas pracy w BenchPrep, gdzie wykorzystaliśmy go do opracowania kilku dużych aplikacji jednostronicowych na górze biblioteki backbone.js.

Pracowałem z ExtJS od kilku lat i ukradłem moje ulubione koncepcje z tego frameworka, takie jak architektura oparta na komponentach, w której rozwijasz swoje widoki jako samodzielne komponenty, a następnie łączysz je z innymi komponentami za pomocą widoków kontenera. A ponieważ jest on w dużej mierze oparty na konfiguracji, tworzenie aplikacji w Luca przypomina pisanie o obiekcie za pomocą JSON.

Zaletą tego podejścia jest możliwość ponownego użycia komponentów w kilku aplikacjach lub w różnych miejscach w aplikacji, z niewielkimi zmianami przy użyciu rozszerzenia Backbone. Bardzo łatwo jest eksperymentować z wieloma różnymi układami / prezentacjami komponentów, wprowadzając jedynie drobne poprawki w konfiguracji JSON.

Oprócz szerokiej gamy funkcji pomocniczych / narzędziowych, Luca oferuje wiele pochodnych szkieletowych wyższego poziomu, które można łączyć w dowolny sposób, aby sobie wyobrazić, aby stworzyć złożony interfejs użytkownika.

Widoki, komponenty, pojemniki

• Model rozszerzony, widok, kolekcja, klasy routera
• Opcje konfiguracji ułatwiające komunikację między modelami, kolekcjami, widokami, aplikacją i jej odpowiednimi menedżerami.
• Kontenery (układ podziału / kolumny, układ siatki, widok kart, widok karty / kreatora)
• FormView ze wszystkimi standardowymi komponentami pola i pomocnikami do synchronizacji z Backbone.Model
• GridView, do generowania przewijalnych elementów siatki z kolekcji Luca
• CollectionView, do generowania widoków na podstawie kolekcji
• Paski narzędzi / przyciski

Style i znaczniki Bootstrap na Twitterze za darmo

• Luca gra bardzo dobrze ze strukturą bootstrap na Twitterze. Po prostu ustawiając Luca.enableBootstrap = true i włączając CSS, twoje komponenty (takie jak widoki kart, paski narzędzi, przyciski, formularze, pola, siatki itp.) Będą automatycznie korzystać ze znaczników zgodnych z Twitter Bootstrap i konwencji klas CSS.
• Używa układu Grid do układania i inteligentnie reaguje na większość podstawowych klas css bootstrap
• Składniki Luca.Viewport i GridLayout są skonfigurowane do pracy z responsywnymi, płynnymi lub statycznymi systemami gridowymi bootstrap.
• Ma na celu zapewnienie dopasowania jeden do jednego dla komponentów ładowania początkowego Twittera, aby reprezentować je jako konfigurowalne widoki szkieletu

Komponent aplikacji

• Maszyna stanów oparta na Backbone.Model zapewnia metody getter / setter i zdarzenia zmiany atrybutów jako styl przepływu kontroli aplikacji
• Zintegrowany komponent kontrolera, który ukrywa / pokazuje strony aplikacji w odpowiedzi na zdarzenia Backbone.Router lub State Machine
• Zintegrowany menedżer kolekcji, który śledzi utworzone przez siebie kolekcje, pozwala na ich zasięg, grupowanie, przypisywanie im parametrów domyślnych
• Socket Manager, który jest warstwą abstrakcji na szczycie usług websocket, która sprawia, że ​​push jest tak prosty jak Backbone.Event
• Router zdarzenia klawiatury, który wyzwala nazwane kluczowe zdarzenia w komponentach, które chcą reagować na takie zdarzenia

Udoskonalenia kolekcji i modeli

• Kolekcje oparte są na zapytaniu szkieletowym , które zapewnia interfejs zapytań bardzo podobny do mongoDb
• włącz lokalną pamięć masową Backbone.sync, po prostu ustawiając collection.localStorage = true
• automatyczne zapełnianie kolekcji, których dane są ładowane podczas ładowania strony
• metody buforowane / właściwości obliczone. buforuj wyniki metod gromadzenia i wygasaj pamięć podręczną w odpowiedzi na zmianę / dodanie / usunięcie zdarzeń w kolekcji lub jej modelach
• obliczone właściwości modeli. buduj atrybuty na podstawie złożonej funkcji i automatycznie aktualizuj obliczoną wartość w odpowiedzi na zmiany

Wydarzenia i haczyki

Komponenty Luca są bardziej liberalne, jeśli chodzi o zdarzenia, które emitują w porównaniu z zapasowymi komponentami Backbone. Będą emitować zdarzenia takie jak przed: inicjalizacja, po: inicjalizacja, przed: renderowanie, po: renderowanie, aktywacja, najpierw: aktywacja, dezaktywacja, najpierw: dezaktywacja, a to pozwala na bardziej precyzyjne dostrojenie zachowania twoich komponentów. Ponadto, definiując zdarzenie w dziale @hooks w twoim widoku, automatycznie wywoła dla ciebie funkcję o podobnej nazwie, jeśli taka istnieje. Zapobiega to tworzeniu kodu zwrotnego, który poprawia czytelność.

Możesz także skonfigurować klasę Luca.Events, aby publikowała zdarzenia w globalnym kanale publikowania / subskrybowania, co ułatwia budowanie dużej aplikacji i pomaga w komunikacji między modułami.

Rubinowy klejnot

Luca została opracowana specjalnie podczas pracy z interfejsami API Railsów i Sinatry i dlatego jest obecnie zoptymalizowana pod kątem konkretnego stosu, ale w żaden sposób nie blokuje cię na konkretnym serwerze.

Luca jest dystrybuowana jako część Ruby Gem skonfigurowanego do pracy w potoku zasobów lub jako plik JS do pobrania.

Nie musisz używać Railsów ani Sinatry. Ale jeśli tak, zamieściłem wiele przydatnych rzeczy:

• Pliki z rozszerzeniem .luca są przetwarzane jako HAML z interpolacją zmiennych w stylu JST. (odpowiednik .jst.ejs.haml) według potoku zasobów
• Uprząż testowa do przeglądarki lub testy jednostkowe oparte na jaśminie wraz z wieloma pomocnikami testów kręgosłupa i podkreślenia.
• Punkt końcowy interfejsu API dla zestawu narzędzi programistycznych dostarczanych z Lucą (więcej na ten temat później)
• Punkt końcowy interfejsu API, który pozwala używać Redis jako bezproblemowego silnika pamięci masowej dla Luca.Collection przy minimalnej konfiguracji

Narzędzia programistyczne

• Aplikacje Luca mogą włączyć w przeglądarce konsolę do kawy z pomocnikami i poleceniami Luca, które pomagają w monitorowaniu, inspekcji, debugowaniu aplikacji i komponentów Luca

• Za pomocą Rails Gem i edytora komponentów opartego na CodeMirror Lucy możesz edytować kod źródłowy Luca Framework, a także komponenty specyficzne dla aplikacji bezpośrednio w przeglądarce, używając Coffeescript. Zobaczysz natychmiastową informację zwrotną w odpowiedzi na twoje zmiany, z odświeżonymi instancjami wykonanych obiektów za pomocą zaktualizowanego prototypu, i możesz zapisać swoje zmiany na dysku.

• Component Tester to piaskownica na żywo do zabawy ze składnikami, które składają się na twoją aplikację w izolacji. Udostępnia narzędzia do modyfikowania prototypu komponentu, konfigurowania jego zależności i konfigurowania komponentu. Komponent zostanie ponownie wyrenderowany natychmiast po każdej edycji. Możesz przeglądać i edytować znaczniki generowane przez ten komponent, a także CSS bezpośrednio w przeglądarce i natychmiast zobaczyć zmiany. To sprawia, że ​​jest to bardzo cenne narzędzie do eksperymentowania.

• Component Tester wkrótce zintegruje się z Jasmine, abyś mógł wyświetlać wyniki swoich testów jednostek w czasie rzeczywistym podczas edycji ich kodu

Luca jest w toku, ale utrzymuje stabilny interfejs API (jeszcze nie 1.0) i był używany w kilku dużych aplikacjach produkcyjnych. Jest to zdecydowanie bardzo opiniotwórcze środowisko, ale pracuję nad tym, aby był bardziej modułowy. Aktywnie pracuję nad dokumentacją i przykładowymi komponentami.

Jestem współautorem Chaplin i napisałem dogłębne porównanie między Chaplin.js i Marionette.js:

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

To nie jest „strzelanina”, ale próbuje wyjaśnić oba podejścia w wyważony sposób.