Po pierwsze, najważniejszym elementem projektu, który chciałbym stworzyć, jest silnik wiki zaimplementowany jako pojedyncza strona internetowa aplikacji. Planuję mieć zestaw funkcji dostępnych od samego początku z wieloma dodatkami w przyszłości.
Podstawowe funkcje
- tworzenie strony (tworzy artykuł wiki i forum dyskusyjne dla tego artykułu)
- markup i WYSIWYG ala markitup
- konwersja w locie między znacznikami / html / WYSIWYG
- boczny pasek do szybkiej nawigacji
- górny pasek narzędzi do wyboru edycji / widoku
Zaawansowane funkcje
- konfigurowalny pasek boczny do nawigacji inną metodą
- konfigurowalny pasek narzędzi (ewentualnie dodaj wybrany język znaczników)
- tagi
- edytowalne todo's
- przeciągnij i upuść przesłane pliki i załączniki graficzne
Silnik pierwotnie składał się z najbardziej podstawowych funkcji tworzenia stron, oznaczania oraz edycji i zapisywania w trybie WYSIWYG. Ostatecznie chciałbym rozszerzyć ten podstawowy silnik o obsługę obrazów metodą przeciągnij i upuść, przesyłanie plików, wykresy danych na żywo i pasek boczny do dostosowywania widoków.
Przeprowadziłem dość obszerne poszukiwania przyzwoitego projektu, na podstawie którego mógłbym oprzeć swój projekt, ale poza TiddlyWiki nie wydaje się, aby istniał żaden dobry silnik wiki oparty na javascript. Rozważałem również zastosowanie Jquery na istniejących silnikach wiki, ale wydaje mi się, że i tak w końcu mógłbym go przepisać (dodatkowo dodawanie funkcji, które chcę na bieżąco, jest po prostu bardziej ekscytujące). Tak czy inaczej, udało mi się zaimplementować tę bestię z biblioteką javascript + frameworkiem.
Wiem, że tak naprawdę nie można porównywać niektórych z tych frameworków ze sobą, ponieważ nie są one jabłkami do jabłek. Próbowałem ułożyć wszelkie komentarze / pytania porównawcze z porównywalnymi fragmentami odpowiednich ram, ale jestem otwarty na poprawianie.
Więc zaczynamy:
Na podstawie własnych badań i opinii zawęziłem listę do poniższych pozycji. Celowo pominąłem takie rzeczy, jak SproutCore, corMVC, YUI i inne, ponieważ, mając ograniczone możliwości, uważałem, że poniższe elementy będą lepiej pasować.
Moje opcje
jquery / UI + backbonejs
Ogólny
Z tego, co przeczytałem, ta kombinacja jest używana i uwielbiana przez wielu i jest bardzo elastyczna i rozszerzalna. Moim głównym zmartwieniem jest to, że ta kombinacja po prostu nie jest najlepszym punktem wyjścia do tworzenia interfejsu użytkownika bardziej zorientowanego na komputery.
UI
Chociaż jQueryUI lub jqueryTools mogą być konkurencyjne, z pewnością nie wydają się być na równi z możliwościami interfejsu użytkownika innych platform. W szczególności wydają się być ciężkie pod względem efektów, ale brakuje im przyzwoitej obsługi krojenia układu.
javascriptMVC
Ogólny
Wydaje mi się, że JavascriptMVC jest zasadniczo rozszerzeniem jquery + MVC (jqueryMX), wraz z kilkoma innymi aplikacjami do dokumentowania (documentJS), testów funkcjonalnych (funcUnit) oraz zarządzania kodem i zależnościami (stealJS). Poza korzyściami płynącymi z dodatkowego modułu, myślę, że debata funkcjonalna naprawdę sprowadza się do kwestii backbonejs vs. jqueryMX. Czy mam rację i czy ktoś pracował z obydwoma lub je porównywał?
UI
JavascriptMVC dodaje elementy MXUI do wszystkiego, co jest dostępne dla Jquery, więc myślę, że przynajmniej jest to niewielka wygrana w tej kategorii.
knockoutjs
Ogólny
Moje przemyślenia i obawy na ten temat są bardzo podobne do komentarzy w jquery + backbone. Oba wydają się oferować podobne funkcje, ale tylko z innej perspektywy. Często przytaczanym minusem jest to, że knockoutjs zbyt ściśle łączy logikę biznesową i prezentację z powiązaniem danych oraz że ta metoda wiązania może zepsuć się w przypadku złożonych interakcji z interfejsem użytkownika, ale chciałbym usłyszeć, dlaczego nie jest to problem.
- Dyskusja na temat koncepcji szkieletu vs knockoutJS
- Funkcje knockoutjs
UI
W tej chwili puste
Dojo i ExtJS
Ogólny
Mam zamiar połączyć dyskusję Dojo i ExtJS, ponieważ wiem o nich najmniej i wydają się grać w niemal tej samej przestrzeni. Większość informacji na temat przepełnienia stosów dotyczących tych dwóch wydaje się nieaktualna. Z tego, co widziałem, wynika, że oba są dużymi frameworkami, które są dobre do implementacji aplikacji kalibru komputerowego. Dojo zostało zbesztane za kiepską dokumentację, ale wydaje się, że już tak nie jest. ExtJS ma oczywiście licencję komercyjną, ale jest to naprawdę rozsądne, jeśli chodzi o to, co dostajesz i nie miałbym tego zbytnio zarzucać. Widżety w ExtJS wydają się być trochę bardziej profesjonalnie wykonane niż Dojo, ale z pewnością dałbym się tam poprawić. Chciałbym usłyszeć od każdego, kto ma doświadczenie w obu.
UI
Dojo ma bibliotekę interfejsu użytkownika dijit. ExtJS ma funkcje interfejsu użytkownika, ale nie ma ich w rdzeniu Ext. Oto dokumentacja, a tutaj ich dema
Cappuccino
Ogólny
Jest jeszcze Cappuccino. Bez CSS, bez html, ale również może być trudne użycie istniejących bibliotek javascript. Objective-J nie wydaje się być przerażające, zwłaszcza biorąc pod uwagę, że zachwalają również możliwość pisania zwykłego javascript. Dema są imponujące i wydają się być bardzo zbliżone do potrzeb interfejsu użytkownika silnika wiki. API oparte na kakao to dużo do przyjęcia dla kogoś, kto go nie zna, ale może warto. Słyszałem, że praca z silnikiem układu graficznego nie zawsze jest łatwa, ale taka młoda i prawdopodobnie rewolucyjna technologia z pewnością będzie miała pewne wady.
UI
W tej chwili puste
Przepraszam, że tak dużo pisałem, ale hej, przynajmniej nie jest to pytanie ax vs y vs z, licząc na mnóstwo tanich odpowiedzi. Więc co o tym myślisz? Jaka powinna być podstawa mojego silnika typu wiki na komputery stacjonarne, który, miejmy nadzieję, z czasem stanie się bardziej bogaty w funkcje (kompleksowy odczyt)?