Спасибо за наводку, ознакомился. Ну точнее, посмотрел примеры кода из туториалов - этого обычно достаточно, чтобы оценить предлагаемый coding style. Увы, моя душа уже развращена нокаутом, так что - нет. Dojo это прошлый век.
Возьмем типичный пример. Допустим, нужно нарисовать некую табличку (грид) с фильтрами и сортировками. Данные для этой таблички динамически запрашиваются ajax-ом с сервера в виде json. Юзер может что-то в этой табличке поправить, соответственно нужно сохранять изменения всё тем же ajax-ом c json-ом через новомодный REST.
На первый взгляд, в Dojo всё здорово. Есть навороченный Grid со всеми свистелками и перделками, есть хранилище (store), в котором лежат данные таблицы в виде почти обычных js-объектов. Грид умеет самостоятельно обновляться при изменению объектов в хранилище и наоборот. Кроме того, в Dojo есть хранилище JsonREST, которое умеет само синхронизироваться с сервером при помощи json и REST. Казалось бы, красота - берем два готовых компонента, настраиваем, ???, PROFIT! И ни одной строчки HTML кода.
Но это только на первый взгляд. Берём туториал, смотрим настройку грида. Вот кусочек, отвечающий за описание одного столбца таблицы:
Ну это нормальный стиль для программистов десктопных приложений. Но не для веба. Ну даже закроем глаза на явное указание width и стиля, будем считать что это не быдлокод, а сделано для простоты восприятия. Но! Dojo здесь работает как прослойка с ООП-синтаксисом, которая генерирует html-код. Нафига? Зачем описывать то, что должно быть в html коде? Почему не использовать собственно html-код, как в нокауте? Сферический веб-программист в вакууме отлично знает html, css, чистый javascript. А вот библиотеку dojo - не знает, и по словам recorder-a доки есть не на всё. Вообще, каков смысл существования этой прослойки?
Дальше, про заявленные рюшки типа пейджинга, сортировки и фильтров. Грид сам этого не делает, предоставляя работать хранилищу. Это в-общем разумно. Но! Далее хранилище JsonREST этого тоже не делает, оно сбрасывает всё на сервер. А вот это уже опаньки. Дергать сервер каждый раз, когда юзер прокручивает таблицу - это за гранью. И второе - придется допиливать сервер, чтобы научить его делать пейджинг с сортировкой. Тоже не айс.
Не, ну они приводят пример таблицы со 100500 строками, и типа у них все работает. Извините ребята, но это бред. Таких таблиц не должно быть ни в вебе, ни в десктопных приложениях. Человек не способен воспринять таблицу не то что на сто тысяч строк, даже на сто уже с трудом. Ну максимум - тысяча. Дорабатывайте UI своего приложения так, чтобы таблиц длиннее 1000 строк у вас не было в принципе. Разбивайте данные по группам, по годам, давайте сводные итоги, как хотите. Оставшиеся тысячу строк должны передаваться на клиенте целиком, и их сортировкой должен заниматься клиент, а не сервер.
Это всё конечно решаемо. Можно написать своё хранилище с сортировками и собственным Json... Или перелопатить исходный код и найти, как настроить имеющийся компонент. Только желания как-то не возникает.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2012-02-16 04:12 pm (UTC)Увы, моя душа уже развращена нокаутом, так что - нет. Dojo это прошлый век.
Возьмем типичный пример. Допустим, нужно нарисовать некую табличку (грид) с фильтрами и сортировками. Данные для этой таблички динамически запрашиваются ajax-ом с сервера в виде json. Юзер может что-то в этой табличке поправить, соответственно нужно сохранять изменения всё тем же ajax-ом c json-ом через новомодный REST.
На первый взгляд, в Dojo всё здорово. Есть навороченный Grid со всеми свистелками и перделками, есть хранилище (store), в котором лежат данные таблицы в виде почти обычных js-объектов. Грид умеет самостоятельно обновляться при изменению объектов в хранилище и наоборот. Кроме того, в Dojo есть хранилище JsonREST, которое умеет само синхронизироваться с сервером при помощи json и REST. Казалось бы, красота - берем два готовых компонента, настраиваем, ???, PROFIT! И ни одной строчки HTML кода.
Но это только на первый взгляд.
Берём туториал, смотрим настройку грида.
Вот кусочек, отвечающий за описание одного столбца таблицы:
{ name: "Bats", field: "bats", width: "70px", cellStyles: "text-align: right;" }
Ну это нормальный стиль для программистов десктопных приложений. Но не для веба. Ну даже закроем глаза на явное указание width и стиля, будем считать что это не быдлокод, а сделано для простоты восприятия.
Но! Dojo здесь работает как прослойка с ООП-синтаксисом, которая генерирует html-код. Нафига? Зачем описывать то, что должно быть в html коде? Почему не использовать собственно html-код, как в нокауте? Сферический веб-программист в вакууме отлично знает html, css, чистый javascript. А вот библиотеку dojo - не знает, и по словам recorder-a доки есть не на всё. Вообще, каков смысл существования этой прослойки?
Дальше, про заявленные рюшки типа пейджинга, сортировки и фильтров. Грид сам этого не делает, предоставляя работать хранилищу. Это в-общем разумно. Но! Далее хранилище JsonREST этого тоже не делает, оно сбрасывает всё на сервер. А вот это уже опаньки. Дергать сервер каждый раз, когда юзер прокручивает таблицу - это за гранью. И второе - придется допиливать сервер, чтобы научить его делать пейджинг с сортировкой. Тоже не айс.
Не, ну они приводят пример таблицы со 100500 строками, и типа у них все работает. Извините ребята, но это бред. Таких таблиц не должно быть ни в вебе, ни в десктопных приложениях. Человек не способен воспринять таблицу не то что на сто тысяч строк, даже на сто уже с трудом. Ну максимум - тысяча. Дорабатывайте UI своего приложения так, чтобы таблиц длиннее 1000 строк у вас не было в принципе. Разбивайте данные по группам, по годам, давайте сводные итоги, как хотите. Оставшиеся тысячу строк должны передаваться на клиенте целиком, и их сортировкой должен заниматься клиент, а не сервер.
Это всё конечно решаемо. Можно написать своё хранилище с сортировками и собственным Json... Или перелопатить исходный код и найти, как настроить имеющийся компонент. Только желания как-то не возникает.