ExtJS4 практически впечатления
Когато избирате софтуерна платформа, очите ви обикновено се разширяват - ето я, ето я и всичко е неизменно отлично. Сравнителните матрици от всякакъв вид вече не помагат - можете да видите, че в X рамката няма връзка с индустриална автоматична система за промиване на тоалетни, но тази информация не винаги е полезна.
И искам да разбера за какво е добра тази или онази библиотека в практически приложения, искам да прочета за нечий опит. А с това не толкова. Например, не намерих нищо подобно в ExtJS. Трябваше да го пробвам сам.
Следват моите впечатления от работата върху ExtJS 4.1.1. По дефиниция те са субективни и не претендират да бъдат универсални обобщения.
Така че условията. Трябва да напиша красив уеб интерфейс с доста голяма сложност. Много искам всичко да изглежда като приложение, а не като уебсайт. Приложението е интранет, така че красотата не е особено необходима. Потребителите оценяват удобството и бързината на работата си много повече от малките неща, с които свиквате за три дни. Те също обичат да предлагат промени и са много благодарни, когато промените се правят бързо. Въпросът за съвместимостта с браузърите не си струва - те ще седнат на това, което казвам.
Допълнително условие е, че не обичам да бъркам в уеб интерфейса и се опитвам да се отърва от тази част възможно най-бързо.
И така, положителните аспекти на ExtJS 4.1.1.
С негова помощ е възможно да постигнете глобално поставена цел - наистина можете да напишете уеб приложение върху него. Ще изглежда професионално и красиво, дори бих казала луксозно. Богат избор от контроли, внимателно подбрани цветове, предварително написани стилове. Достатъчно е да се каже, че никога не можете да се справите нито с HTML, нито с CSS изобщо и да ги забравите като лош сън. Достъпима DOM в библиотеката за всеки случай, но никога не съм го ползвал - всичко е решено така.
Приложението лесно се свързва с REST, основното е, че REST дава данни в правилния (и не много сложен) формат. Достатъчно е да опишете само къде да отидете за данните - и готово. Целият джентълменски комплект CRUD работи от кутията.
Почти всички потребителски действия могат да бъдат поставени в интерфейса и да не зареждат сървъра с тях. Делът на последния е само допълнителна проверка на коректността на данните и работа с базата данни. Това много го опростява - буквално до 5-10 kb код (nodejs, mojo - пробвах няколко варианта, работи добре навсякъде).
Сега за недостатъците.
Той е един, но глобален - всичко това, като тези коледни украси, не радва. Програмирането в ExtJS не само не е забавно, а точно обратното. Това е изобилен източник на разочарования, комплекси и скоби.
Общият стил на библиотеката се предава най-добре от думата "чудовищна". Това е един вид мастодонт, в който броят на изходните файлове достига десетки. Когато свържете страницата към браузъра, се зареждат около 6 мегабайта от всякакви стоки и това време е много, много забележимо.
Заради ужасно бавното зареждане е невъзможно да програмирам по любимия си начин, който научих от Forth - малки редакции. Правите една промяна, гледате резултата, редактирате. Повторете. Това не работи така - докато този слон се зарежда след всяка промяна, вие забравяте какво сте искали да направите. Мислите вече са отишли някъде далече, към тучни полета от зеленина и бели планини с водопади.
Научаването на ExtJS е ужасно трудно. Огромен е, не знам откъде да започна. Учебниците и книгите се отнасят предимно до третата версия, а тя от своя страна малко прилича на версия 4, в която почти всичко е направено по различен начин. С товаПо същата причина форумите са почти безполезни, защото всичко, което е написано там, е отдавна остаряло.
Срам ме е да кажа, но написах банално приложение от нулата почти седмица, докато страдах от внезапни промени в настроението. През цялото време исках да си блъскам главата в стената - абсолютно всичко беше неразбираемо. Никаква технология не съм преподавал с такова страдание.
Второто приложение обаче не беше по-добро. Малко по-бързо, но не много.
Във версия 4 вашето приложение трябва да бъде направено в съответствие с принципа MVC. На практика това означава, че дори hello world ще се състои от дузина файлове, разпределени в няколко различни директории. И преди да започнете да програмирате каквато и да е задача, тези файлове ще трябва да бъдат създадени и декомпозирани. Не HTML се отваря дори и с празна страница. Ситуацията напомня на професионални щангисти, които преди да се доближат до снаряда, трябва да загреят и загреят мускулите си в продължение на няколко часа.
Комплектът е стандартен. Моделът описва вашите данни, в хранилището (Storage) - как да стигнете до тези данни, в изгледите - как ще изглежда всичко. Тук всичко е повече или по-малко логично.
Контролерът на типа свързва изгледа с манипулаторите, но всъщност в четвъртата версия той не се припомня и обикновено е безполезен. Предполага се, че ще имате глобален контролер за всеки обект и е напълно невъзможно да напишете някакъв вид самодостатъчна джаджа с него, която след това да бъде вмъкната където искате.
Не всичко е наред и с данните. Складът предполага, че всички данни винаги са идеално хомогенни. Вярно е, че е възможно да се опишат някои вложени обекти по начин едно към много, но тези допълнителни данни се четат само - не могат да бъдат записани, което прави цялата идея безполезна.
Описанието на интерфейса е нещо. Описва се чисто декларативно −и това е плюс. Но как е описано, сър. С помощта на декларацията за данни в Javascript - и има няколко типа данни, масиви и хешове. Следователно всеки екран, само с няколко контроли, е дълга кърпа за крака от декларативен код, със структури, които многократно се влагат една в друга. Търсете при такива условия, на кое място има допълнителна скоба - това е ад. Невъзможно е да се опростят декларациите - всяко кихане трябва да бъде описано, практически няма полезни стойности по подразбиране.
Следователно всяка промяна в интерфейса или кода, дори корекцията на граматична грешка, задължително включва дълго търсене на мястото, където всъщност трябва да редактирате. Първо трябва да се опитате да си спомните къде се намира, след това да претърсите куп вложени директории, да изберете отново желания файл от дузина и да претърсите кода за дълго, дълго време в него, който обикновено отива Бог знае къде поради множество отстъпи, и в същото време се молете влагането да не се счупи.
Библиотеката има грешки. Не много, но ги има. Но поради цялостната сложност те се превръщат в кошмар - не могат да бъдат поправени по никакъв начин. Не е ясно от какво идват, не е ясно какво трябва да се промени, не е ясно за какво става дума въобще. Особено трудно е, ако това са грешки в алгоритмите за оформление - тогава просто се оказвате с празна страница и неразбираемо съобщение в конзолата.
Или потребителите ви пишат - нашата таблица не е заредена. Отваряте го - и истината е, че не зарежда. Вчера се зареди, но днес не, въпреки факта, че не сте променили нищо на това място.
Не е по-добре за собствените ви грешки. Диагностиката много често е изключително загадъчна и само след няколко месеца започвате да се досещате, че „недефинирано“ някъде дълбоко в дълбините на ExtJS означава липсващия атрибут Store, когато описвате падащия списък.
Съответно ставабезполезен и отстраняване на грешки. Вашият собствен код е чисто декларативен, няма нищо за отстраняване на грешки и работата с мегабайти код за самата библиотека е упражнение, което изисква голяма смелост.
Писането на собствени контроли или модифицирането на стари е друга работа. Но ако модификациите не са много големи, то това става сравнително лесно - старият обект се наследява и се правят промени в него. Обикновено това е най-лесният начин да накарате библиотеката да прави това, което искате. Но ако има малко повече промени, следва рязък скок в сложността. От декларативни описания се озоваваме някъде дълбоко в яма с лъвове, КЪЩА, неочевидни събития, родителски предмети и дявол знае какво още.
Въз основа на гореизложеното, в следващия ми проект (и имам много различни) все пак ще опитам нещо друго за интерфейса.