Велосипед состоит из следующих деталей. Разметка генерируется на сервере, 125 строк PHP. Интерфейс редактирования — это 642 строки JS (в несжатом виде), которые включают:
— класс-модель, обрабатывающую изменения данных (включая моментальное сохранение в jStorage и отложенную отправку на сервер, не блокирующую редактирование);
— класс-представление, обрабатывающее ввод данных и передающее его в модель, а также отображающее наличие несохраненных изменений — использует jQuery для работы с DOM;
— подробные комментарии с jsdoc'ом к методам.
Для обхода структуры пришлось написать метод, содержащий 6 вложенных for'ов.
На Angular получилось 44 строки HTML-разметки + 170 строк JS, в которых определяется несколько директив для обработки логики. Да, меньше в 3 раза, но там еще нет никакой отправки на сервер, контроля изменений и проч., то есть приложение по сути еще ничего не делает — я бросил на том, что рендеринг завис намертво на несколько секунд.
Писать веб-приложение, используя jQuery — не значит писать бешеные цепочки jQuery(selector).click(callback).find(selector).end().fadeIn(time) и подобные, которые подходят разве что для добавления простой интерактивности в веб-сайты.
Это проблема строковых шаблонизаторов. Да, оно-то компилируется в функцию, но функция всё равно возвращает строку, которая потом целиком идет в innerHTML. Если в этой строке оказался, например, canvas, то нарисованное на нём с помощью Canvas API изображение при пере-рендеринге шаблона пропадёт.
Строковой сборкой и пересборкой HTML (с Metamorph всё сложнее, там еще и добавляется пара тегов script вокруг каждой из меняющихся областей, которые фреймворк находит и меняет текст между ними при обновлении модели).
Возможно, я еще не до конца разобрался (только прочитал исходники, не было времени провести тот же эксперимент, который я провел с Angular). Но в приложении, для которого я рассматриваю переход на один из современных фреймворков с data-binding'ом, есть достаточно нетривиальные вомпоненты, которые выходят за рамки работы с текстовыми данными (например, Flash-объект с ExternalInterface'ом, canvas, video). Эти компоненты невозможно пересоздать из HTML-кода в том же состоянии, в котором фреймворк обнаружил изменение модели. Более того, с Flash-объектом вообще следует поступать осторожно и нельзя удалять и пересоздавать, когда вздумается, поскольку это сторонний плагин, и взаимодействие с ним в некоторых браузерах (апчх-ие) происходит асинхронно.
Тормоза образовались из-за того, что Angular не только вставляет в DOM, но и гуляет по тегам и атрибутам в поисках директив. Это очень круто, если директив немного, а вложенность DOM-дерева небольшая (например, для небольших приложений или для приложений, где в один момент времени идет работа с одним ресурсом). Но в случае с `ng-repeat`, внутри которого есть еще куча директив, на время их сбора наступает зависание.
В результате свой «велосипед» без binding'а и repeat'ов. Из Angular позаимствовал обработку ввода в текстовое поле. Летает.
Это был эксперимент с Angular после прочтения его исходников и вдохновения его крутостью. Такой же эксперимент хотел провести с Ember после аналогичных действий, но уже не осталось времени — нужно было отдавать инструментарий переводчику.
С отправкой проблем нет, сервер принимает JSON со структурированными изменениями. Проблема с binding'ом на такую структуру с декларативным построением интерфейса пользователя (ng-repeat + другие директивы).
См. мой комментарий выше. Хотелось именно декларативности, с преобразованием из одной структуры в другую и автосохранением. Пришлось делать по-старинке.
Попробуйте с помощью Angular и ng-repeat отобразить и заbindить структуру с вложенными коллекциями. В каждом элементе самой глубокой коллекции требуется изменение одного поля, на сервер требуется отправить изменения, структурированные так же, как исходная структура. Для представления требуется также перегруппировать вложенные коллекции по сравнению с исходной структурой. Изменить/упростить представление — не предлагать. Требования реальные: инструментарий локализации интерфейса пользователя. Вложенные коллекции: для каждой локализуемой строки, для каждого языка, между которыми осуществляется перевод, строка, которую нужно отредактировать.
Мой опыт на сравнительно небольшом объеме данных показал время компиляции директив более 2-4 секунд зависания браузера, причем это уже на перегруппированной для представления структуре, которую как-то нужно возвращать в исходный вид.
В результате свой «велосипед» без binding'а и repeat'ов. Из Angular позаимствовал обработку ввода в текстовое поле. Летает.
Вывод: Angular крут для маленьких формочек. Когда дело доходит до коллекций, он меркнет. Будем надеяться, что переход на Object.observe, который идет в отдельной ветке, хоть как-то поможет в runtime (на инициализации при компиляции директив не спасет все равно — DOM штука медленная).
P.S. Ember разочаровывает Handlebars'ом и Metamorph'ом.
Интересно узнать, планируете ли вы подключить OCR и уточнять поиск по картинке текстовым поиском по словам на картинке, а также по совпадениям имён загруженного и исходного файлов, или по совпадению имени с текстом на картинке.
Насколько я понимаю, dirty checking Angular'а позволяет Вам иметь в качестве моделей обычные JavaScript-объекты со свойствами и, возможно, с методами. То есть для реализации берется функция-конструктор, присваиваются свойства, на прототип навешиваются методы.
Angular понимает массивы и, по идее, массиво-подобные объекты — то есть Вы можете создать обычный Array, заполнить его своими объектами и отдать Angular'у в качестве модели коллекции.
Только начал разбираться с Angular. Поправьте, если ошибаюсь.
Простите, конечно, но я нашел более удобный для себя выход: использовать Chrome, где этой проблемы нет.
Я пользовался Opera во времена до Chrome, когда она была лучшим браузером (главное для меня — быстрым, хотя я и пользовался настройкой панелей и прочими прелестями). Потом Opera стала обзаводиться ошибками и особенностями рендеринга, и с появлением Chrome потеряла меня в качестве пользователя (несмотря на это, будучи веб-разработчиком, я с интересом слежу за её судьбой, а на смартфоне ей до недавней смены движка не было равных, так что здесь я по-прежнему с Opera).
Я думаю, вы все равно чаще переключаетесь между вкладками, чем перетаскиваете окно между мониторами, особенно, если у вас вкладок столько, что нет свободного места (справа), за которое можно схватиться. Без этого пресловутого отступа небрежным движением руки курсор доезжает до края экрана и кликает там на желаемую вкладку; если отступ есть, то после небрежного движения потребуется еще и обратное более точное движение вниз.
BigDecimal.valueOf("1.1"), а неBigDecimal.valueOf(1.1), если я правильно Вас понял.Здесь опечатка или
valueOf(1.1)как-то специальным образом компилируется, что1.1оказывается не IEEE754?— класс-модель, обрабатывающую изменения данных (включая моментальное сохранение в jStorage и отложенную отправку на сервер, не блокирующую редактирование);
— класс-представление, обрабатывающее ввод данных и передающее его в модель, а также отображающее наличие несохраненных изменений — использует jQuery для работы с DOM;
— подробные комментарии с jsdoc'ом к методам.
Для обхода структуры пришлось написать метод, содержащий 6 вложенных
for'ов.На Angular получилось 44 строки HTML-разметки + 170 строк JS, в которых определяется несколько директив для обработки логики. Да, меньше в 3 раза, но там еще нет никакой отправки на сервер, контроля изменений и проч., то есть приложение по сути еще ничего не делает — я бросил на том, что рендеринг завис намертво на несколько секунд.
Писать веб-приложение, используя jQuery — не значит писать бешеные цепочки
jQuery(selector).click(callback).find(selector).end().fadeIn(time)и подобные, которые подходят разве что для добавления простой интерактивности в веб-сайты.canvas, то нарисованное на нём с помощью Canvas API изображение при пере-рендеринге шаблона пропадёт.Или я чего-то не понимаю?
scriptвокруг каждой из меняющихся областей, которые фреймворк находит и меняет текст между ними при обновлении модели).Возможно, я еще не до конца разобрался (только прочитал исходники, не было времени провести тот же эксперимент, который я провел с Angular). Но в приложении, для которого я рассматриваю переход на один из современных фреймворков с data-binding'ом, есть достаточно нетривиальные вомпоненты, которые выходят за рамки работы с текстовыми данными (например, Flash-объект с ExternalInterface'ом,
canvas,video). Эти компоненты невозможно пересоздать из HTML-кода в том же состоянии, в котором фреймворк обнаружил изменение модели. Более того, с Flash-объектом вообще следует поступать осторожно и нельзя удалять и пересоздавать, когда вздумается, поскольку это сторонний плагин, и взаимодействие с ним в некоторых браузерах (апчх-ие) происходит асинхронно.Это был эксперимент с Angular после прочтения его исходников и вдохновения его крутостью. Такой же эксперимент хотел провести с Ember после аналогичных действий, но уже не осталось времени — нужно было отдавать инструментарий переводчику.
Мой опыт на сравнительно небольшом объеме данных показал время компиляции директив более 2-4 секунд зависания браузера, причем это уже на перегруппированной для представления структуре, которую как-то нужно возвращать в исходный вид.
В результате свой «велосипед» без binding'а и repeat'ов. Из Angular позаимствовал обработку ввода в текстовое поле. Летает.
Вывод: Angular крут для маленьких формочек. Когда дело доходит до коллекций, он меркнет. Будем надеяться, что переход на Object.observe, который идет в отдельной ветке, хоть как-то поможет в runtime (на инициализации при компиляции директив не спасет все равно — DOM штука медленная).
P.S. Ember разочаровывает Handlebars'ом и Metamorph'ом.
Angular понимает массивы и, по идее, массиво-подобные объекты — то есть Вы можете создать обычный Array, заполнить его своими объектами и отдать Angular'у в качестве модели коллекции.
Только начал разбираться с Angular. Поправьте, если ошибаюсь.
А вы не пробовали для такого рода анимаций CSS Transitions? Какая ваша целевая (браузерная) аудитория?
Я пользовался Opera во времена до Chrome, когда она была лучшим браузером (главное для меня — быстрым, хотя я и пользовался настройкой панелей и прочими прелестями). Потом Opera стала обзаводиться ошибками и особенностями рендеринга, и с появлением Chrome потеряла меня в качестве пользователя (несмотря на это, будучи веб-разработчиком, я с интересом слежу за её судьбой, а на смартфоне ей до недавней смены движка не было равных, так что здесь я по-прежнему с Opera).