Архитектура веб-приложения

В чем смысл ограничения на статичность HTML-я?

Ну можно и не совсем статический, но на клиенте будет логики дохрена, на сервере будет своя бизнес-лигика. И размывать эту довольно четкую границу не очень хочется.

ничё не понял. у тебя сервер данные клиенту отдает? какая разница, кому он отдает - AJAX'ине (которая срендерит на клиенте) или шаблонине (которая срендерит на сервере) ?

> Сервак - куча веб-сервисов (rest || soap).

мне всегда казалось что если есть REST то это уже не статический HTML - ведь приходят, говорят GET /userinfo/pupkin , и выдавать надо не статический HTML а что-то сгенеренное, про пупкина. Или я чего-то не понимаю?

У меня морда на jQuery UI общается с Pylons через JSON. Проблем почти нет, единственное бывает браузеры тормозят при создании большого количества элементов(input'ы, по ним считаются некоторые данные).

Я так посовокуплялся, и кончилось это тем что ресурсоемкие части вынесенны в апплет, ибо например таблицу с результатами запроса кошерно не сделать (так чтоб офисный комп тянул), и эт ос учетом оптимизаций, пейджинга, отложенной подгрузки и прочих кошерных вещей.

Да, работа с сревером происходит только по хттп, в рамках одной итойже сессии, и все что вызывает апплет может вызывать и жабаскрипт, апплет скриптуем, можно грабить коро-ванны.

>мне всегда казалось что если есть REST то это уже не статический HTML

Под статическим хтмылем имелось ввиду то, что он не генерится на серваке, а передается клиенту, который уже через аякс данные вытягивает из сервисов и рендерит конечную страницу.

>ничё не понял. у тебя сервер данные клиенту отдает? какая разница, кому он отдает - AJAX'ине (которая срендерит на клиенте) или шаблонине (которая срендерит на сервере) ?

Разница в том, чтобы убрать рендеринг страницы с сервера. Поскольку рендеринга на клиенте все-равно не избежать (и при этом довольно большого его количества) то было-бы логично перетащить туда его полностью.

>У меня морда на jQuery UI общается с Pylons через JSON. Проблем почти нет, единственное бывает браузеры тормозят при создании большого количества элементов(input'ы, по ним считаются некоторые данные).

Хм, а насколько большого количества? Таблица в 5-7 колонок и примерно 100 записей (на самом деле записей может быть и больше гораздо, но они будут создаваться динамически при развертывании очередного узла) сколько на средней машинке будет рендериться?

>Я так посовокуплялся, и кончилось это тем что ресурсоемкие части вынесенны в апплет, ибо например таблицу с результатами запроса кошерно не сделать (так чтоб офисный комп тянул), и эт ос учетом оптимизаций, пейджинга, отложенной подгрузки и прочих кошерных вещей.

А насколько большую таблицу (см. пост выше, я там описал условия)?

Несколько миллиардов записей - результат запроса, данны егрузятся постранично, страница 200 записей, в кеше находится три-четыре страницы, остально подгружается при прокрутке.

Да, используемая раньше для рендеринга таблицы библиотека dojo аццки тормозила и на 100 записях, конечно не на самой мощной машине.

> Хм, а насколько большого количества? Таблица в 5-7 колонок и примерно 100 записей (на самом деле записей может быть и больше гораздо, но они будут создаваться динамически при развертывании очередного узла) сколько на средней машинке будет рендериться?

не могу сказать точно, но есть вариант пересадить всех на Chrome, он нормально справляется с такими вещами.

>Несколько миллиардов записей - результат запроса, данны егрузятся постранично, страница 200 записей, в кеше находится три-четыре страницы, остально подгружается при прокрутке.

Т.е. как я понимаю тормоза начинаются когда одномоментно создается ~200 строк в таблице?

>Да, используемая раньше для рендеринга таблицы библиотека dojo аццки тормозила и на 100 записях, конечно не на самой мощной машине.

Не, с доджей я потрахался в свое время, не поперло.

>не могу сказать точно, но есть вариант пересадить всех на Chrome, он нормально справляется с такими вещами.

Я не настолько великий шаман, чтобы ударив раз в бубен превратить 2-3% рыночной доли браузера в 100 ;) (предполагаемый сервис будет публично доступен)

тормоза даже от 50 строк, но там тормоза в разборе json, и проч. мусоре, прозреваю что если вместо голимого dojo написать все ручками то оно работало бы быстрее, но на яве оно все равно шутрее получилось и проще реализовать многопоточную загрузку.

>тормоза даже от 50 строк, но там тормоза в разборе json, и проч. мусоре, прозреваю что если вместо голимого dojo написать все ручками то оно работало бы быстрее, но на яве оно все равно шутрее получилось и проще реализовать многопоточную загрузку.

Хм, а вот интересно, что быстрее разбирается json || xml?

З.Ы. Да я и собираюсь пока ручками довольно много делать.

json, надеюсь догадаешься почему, осбенно он быст когда он не разбирается, и имеет оптимальную структу, чтоб после загрузки его не нужно было преобразовывать для работы с ним. И еще хотел яб знать, что быстрее и оптимальнее для построение таблиц в HTML:

1) [{id:1, col1:"blah", col2:"bugaga"},{id:2, col1:"blah", col2:"bugaga"}..и так 50 раз..]
2) [[1,"blah","bugaga"],[2, "blah", "bugaga"]..и так 50 раз..]
3) {id:[1,2..и так 50 раз..], col1:["blah","blah"..и так 50 раз..], col2:["bugaga","bugaga"..и так 50 раз..]}

Юзай ExtJS и выкинь апплет.

> Я не настолько великий шаман, чтобы ударив раз в бубен превратить 2-3% рыночной доли браузера в 100 ;) (предполагаемый сервис будет публично доступен)

Ну тут тогда лучше смотреть в сторону гугла.

всмысле разработок.

>Ну тут тогда лучше смотреть в сторону гугла.

Ага, мне уже советовали посмотреть в сторону google app engine и gwt. Как разгребусь с текучкой буду копать.

Grails+(gwt/flex), не?