[web-программирование] Что выбрать?

> Ну, раз генерацию html мы пропустили, тогда вот:

Ну и где же здесь решение? Задача ведь состояла именно в том, чтобы вывести последовательно для взаимодействия с пользователем соответствующие страницы. Полноценное решение будет? То есть такое, которое делает то же самое, что и мое? Понятно, что конкретно цифры можно сложить и тем же джаваскриптом, но суть была в том, чтобы сравнить традиционный подход к реализации взаимодействия с пользователем с подходом, основанным на континуациях. Хотя ваши планомерные попытки уйти от ответа весьма красноречивы.

> но суть была в том, чтобы сравнить традиционный подход к реализации

взаимодействия с пользователем с подходом, основанным на

континуациях.

Традиционный подход заключается в том, чтобы запросить у пользователя все необходимы данные прямо на странице и обработать их без перезагрузки страницы (возможно с выполнение AJAX-запроса). Вы как будто современных веб-приложений не видели. Вы же предлагает вместо этого естественного и просто способа замучить пользователя постоянными переходами от страницы к другой. Такой подход к сбору данных остался во всяких древних ASP, но мы же говорим о современных технологиях?

> Какое у вас интересное представление о «состоянии». SQL-запрос это тогда тоже состояние? Что-то с терминологией у вас проблемы.

Никаких проблем. я же не винвоат, что HTTP спроектирован так, что состояние приходится хранить в запросе?

Это не ограничение

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

Нельзя эффективно перевернуть основу веб.

Ну продолжения вед переворачивают.

Вы верно издеваетесь. Вы в курсе, что cookies имеют ограничения на размер

Да.

Да если бы даже не имел, таскать постоянно туда-сюда всё состояние?

А в чем проблема?

Оно же может быть очень большим.

Я не понял - вы результаты запросов к БД в остсоянии таскать собираетесь? Если нет - можно пример состояния, которое не влезет в cookie. На практике длина больше сотни символов у вас если и получится, то весьмаааа редко.

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

На помойку как раз стоит выкинуть REST.

Согласен по всем пунктам. Я сотый раз твержу - сложные абстракции не жизнеспособны. Продолжени в вебе - классический пример.

> Вы как будто современных веб-приложений не видели.

Как раз видел. И то, что я предлагаю, используется в 99.99% существующих веб-приложений.

(возможно с выполнение AJAX-запроса)

Ну так для аякс-запросов продолжения вообще идеальны.

Такой подход к сбору данных остался во всяких древних ASP, но мы же говорим о современных технологиях?

Естественно, о современных - там этот подход и используется повсеместно. Я повторяю - вычисление чисел было взято просто как пример. Важна только логика взаимодействия, можете взять любую другую функцию. Ситуации, когда требуется запрашивать у пользователя информацию несколькими порциями, встречаются повсеместно. Так решение будет?

> На помойку как раз стоит выкинуть REST.

Счастливо оставаться в каменном веке.

> Естественно, о современных - там этот подход и

используется повсеместно.

Наверное у нас с вами разный веб.

Ситуации, когда требуется запрашивать у пользователя информацию

несколькими порциями, встречаются повсеместно.

Прекрасно, юзайте JavaScript и проблем не будет.

Так решение будет?

Дык, я его привёл же.

> Счастливо оставаться в каменном веке.

Каменный век - это HTTP. А REST (который появился вместе с HTTP) - это просто попытка убедить себя при помощи мантр, что HTTP не такое говно, какое оно есть на самом деле.

> Наверное у нас с вами разный веб.

Да нет, один и тот же.

Прекрасно, юзайте JavaScript и проблем не будет.

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

Дык, я его привёл же.

Ненадо делать вид, что не поняли, в чем состояла задача. Хотя я уже даже пошел вам навстречу, предположил, что вы действительно не поняли, и разложил все по полочкам. Итак - вывести страницу с запросом некоего числа n, потом вывести n страниц с запросом числа на каждой и потом вывести страницу с результатом. Решение будет, или всемогущий непротухший REST не может быть использован для реализации даже такой примитивной логики? Боюсь представить, что случится, если я попрошу send/suspend/dispatch или аналог затенения данных, лол.

> Вы же сами прекрасно понимаете, что этот подход сопряжен

с рядом принципиально неразрешимых проблем.

Не понимаю. Каких?

И использовать не станут.

Значит оно просто уйдут с рынка. Вот и всё.

Итак - вывести страницу с запросом некоего числа n, потом вывести

n страниц с запросом числа на каждой и потом вывести страницу с

результатом.

Блин, ну вы же понимаете, что в соответствии с REST так делать категорически нельзя? И я не буду так делать никогда. Я динамически создам форму, пользователь введёт в неё данные и я её обработаю. При этом, данное решение будет полностью масштабируемым, ибо не связано с хранением не сервере какой-либо сессии.

> Не понимаю. Каких?

Критически возрастает сложность разработки и поддержки.

Значит оно просто уйдут с рынка. Вот и всё.

Не уйдут. Нет причин уходить.

Блин, ну вы же понимаете, что в соответствии с REST так делать категорически нельзя?

но все делают. Потому что альтернатив нет.

Я динамически создам форму, пользователь введёт в неё данные и я её обработаю.

Да можно хоть весь сайт написать на жабоскрипте, но так практически не делается.

При этом, данное решение будет полностью масштабируемым, ибо не связано с хранением не сервере какой-либо сессии.

Я вам уже про сериализацию продолжений говорил, нет?

Давайте вы уже перестанете отнекиваться? Мы же понимаем, что ваше нежелание объясняется одной причиной - вырвиглазностью результата. Я упрощу задачу - сперва введите одно число, потом второе, потом выведите сумму. Такая схема (спросить у пользователя чтото, в зависимости от этого еще чтото и выдать результат) применяется повсеместно, и с вашей стороны заявить тут что-то о «другом вебе» будет уже полным пиздобольством.

> Критически возрастает сложность разработки и поддержки.

Совсем нет же. Почему это она должна возрастать?

но все делают. Потому что альтернатив нет.

Можно пример приложения от Google, которое так делает?

Такая схема (спросить у пользователя чтото, в зависимости от

этого еще чтото и выдать результат) применяется повсеместно

Я вам уже какую страницу объясняю, что эта схема из середины 90-ых и в современных веб-приложениях использоваться не должна. А то что всё ещё используется, ну так это просто нужно время, что бы всё это г.. разошлось. А вы опять за своё. Да, продолжения были очень круто в 1995-ом, но не в 2011.

> Совсем нет же.

Конечно, да. именно по-этому и не используют это дело, хотя ему уже сто лет в обед.

Почему это она должна возрастать?

Потому что у вас логика размазана кусками по разным местам.

Я вам уже какую страницу объясняю, что эта схема из середины 90-ых и в современных веб-приложениях использоваться не должна.

А я вам объясняю, что это ваши мокрые фантазии.

А то что всё ещё используется, ну так это просто нужно время, что бы всё это г.. разошлось.

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

Можно пример приложения от Google, которое так делает?

Э... прошу прощения - а какое не делает? Ну то есть кроме самого гуглопоиска и иже с ним.

> Да, продолжения были очень круто в 1995-ом, но не в 2011.

Это как раз про REST.

Ваша способность игнорировать все современные тенденции и очевидные факты просто поражает. Счастливо оставаться в 90-ых.

> современные тенденции

очевидные факты

Спасибо, пополнил свой словарик демагога.

В Smalltalk нет TCO, но есть продолжения и самый юзаемый уебфреймворк построен на них. И ничего не падает, и с памятью ок. Как же так? :]

> В Smalltalk нет TCO, но есть продолжения

Нету.

> Конечно же, это должен быть язык с нативной поддержкой продолжений

Какие реализации этого подхода можешь посоветовать?

> Ваша способность игнорировать все современные тенденции и очевидные факты просто поражает. Счастливо оставаться в 90-ых.

Современные тенденции как раз показывают, что ты не прав. Все аяксово-жабаскриптовые обвязки остались на том же уровне, на каком были несколько лет назад (по указанным мною причинам). А подход с использованием продолжений дает такой выигрыш, что тебе просто стыдно предоставить stateless аналог (а если бы ты предоставил, то я бы попросил нажать кнопку back, лол). Кстати, работы по RESTfull-continuations это 2004+ год. Инджой ю страна фей.

> Какие реализации этого подхода можешь посоветовать?

Racket же!

> Racket же!

Там же гигена. Это разве не ставит крест на метапрограммировании?

> Там же гигена. Это разве не ставит крест на метапрограммировании?

с чего б вдруг?

>Изучить синтаксис - две недели

Для эффективной разработки на определенном языке одного синтаксиса мало. Важно ещё прочуствование и понимание семантики, а это приходит не сразу

> Нету.

Есть

> с чего б вдруг?

Слишком усложняет и ограничивает.

> Там же гигена. Это разве не ставит крест на метапрограммировании?

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

> Есть

Полноценных - нету.

> Слишком усложняет и ограничивает.

Я уже давным-давно сделал себе 1 макрос для реализации сложных форм на основе syntax-parse, 1 макрос аналогичный define-syntax-rule, но с доступом к среде, и еще один ридер-макрос, который выводит следующую за макросом форму из-под гигиены. В результате от варианта на CL простые макросы с обходом гигиены отличаются обычно парой-тройкой символов (использование того самого макроса для обхода гигиены). Ну а сложные вообще на порядок проще, потому что это же CL - все низкоуровнево, все руками, куча бойлерплейта, никаких батареек нету.

Спасибо, интересно, буду пробовать.

Ок, чем полноценные отличаются от неполноценных?

> Спасибо, интересно, буду пробовать.

И сразу hint. Гигиена обходится так: (syntax-local-introduce #`var). Никаких, нахер, (datum->syntax #`yoba #`var) и прочей белиберды, что выдается за обход гигиены во всяких FAQ по схеме.

> Спасибо, интересно, буду пробовать.

Все полноценные реализации полноценны одинаково, а вот каждая неполноценная - неполноценна по своему.

В REST это решается так:

POST /summer с параметром n -> 201 (Created ) Location: /summer/<id>

id - некий последовательно увеличивающийся глобальный сиквенс

Вот сейчас на запрос GET /summer/<id>/result будет 409

Далее нужно на /summer/<id>/parameter/<parameter> сделать PUT с вводимым числом, где <parameter> - номер страницы от 1 до n.

После n POST-запросов делаем GET /summer/<id>/result и получаем результат.

Все отлично реализовывается на KV базе.

Так никто не спорил, что оно решается, вопрос в том, какой ценой. Куча бойлерплейта, вводим руками состояния и переменные в строку запроса, логика вообще оказывается непонятной, если не проследить что к чему. С использованием же продолжений все выглядит так, как если бы мы писали обычную программу.

Оцтой какой-то. С континуациями решается в разы проще

>С использованием же продолжений все выглядит так, как если бы мы писали обычную программу

Анонимус дело говорит

Продолжения - это всего лишь абстракция. Для простых случаев такие хитрые штуки «делают все за тебя». Когда нужно прикрутить что-то кастомное они начинают только мешаться.

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

Например на запрос GET /summer/<id>/parameter/<parameter> проверять является ли текущий пользователь пользователем, создавшим summer, если нет, то предложить залогиниться и делать редирект на введеную страницу. При этом я могу менять стратегию хранения/удаления объектов. Могу вначале сделать все на РСУБД, потом перенести в Redis или memcached. Могу кучу-кучу всего наворотить и все будет под 100% контролем, 100% масштабируемым.

Вообще пример с продолжениями можно перенести на все «волшебные» фреймворки. Почитай про системы, которые автоматически, якобы, умеют параллелить код. Простейший цикл паралелится на раз-два, в сложных случая - вынос мозга. И так далее.

Явное лучше не явного. Это закон. Копипасте да, нету оправдания. А все волшебство идет лесом.

Анонимус не знает как бороться со сложностью систем. Он предлагает простенькое и очень не расширяемое решение. Оно просто супер для простых систем, и просто ад для сложных.

> Оцтой какой-то.

Конечно, поэтому это и не REST ) В REST мы оперируем ресурсами, которые доступны по собственным URL. Подобная логика просто не укладывается в парадигму REST, поэтому традиционно для этого использовались различные костыли. И продолжения просто самый красивый из этих костылей. Сейчас же подобная логика тривиально решается с помощью JavaScript и мы может делать чистые REST-приложения, а всю логику пользовательского интерфейса выносить на сторону JS.

В REST мы оперируем ресурсами, которые доступны по собственным URL

Поясни, где в моемем примере не-REST? Вроде бы все доступно по своим уникальным урлам. То, что ресурсы не stateless, так в REST никто и не говорит, что они должны быть stateless, таковым должен быть сам протокл общения (от туда и халявная балансировка).

(а если бы ты предоставил, то я бы попросил нажать кнопку back, лол)

Кнопка back с ajax возможна.

> Кнопка back с ajax возможна.

А в HTML5 так вообще супер: http://html5demos.com/history

Сайты пишутся только на двух языках: HTML и XML. Все остальное это программирование. </thread>

> Я упрощу задачу - сперва введите одно число, потом второе, потом выведите сумму.

extJS + direct + нормальная сервеная обвязка (например hqextdirect) решают проблему как нефиг нафиг.

> Анонимус дело говорит

он не разбирается в вопросе. тот же extJS предлагает вменяемые средства разработки, егойный direct предлагает вменяемые средства передачи запросов, а серверная часть (hqextdirect) предлагает вменяемые обработчики.

т.е. я прозрачно могу позвать у книента сервеный код сложения math.add (1, 2, 3), которое без моего участие уйдет на сервант, там автоматом сериализуется, автоматом подставится в math.add (1, 2, 3), результат автоматом передастся клиенту и у него появится ответ. все красиво и удобно. то, что у нативных приложений есть уже лет 50 наконец-то перебралось в вэб.

а онанимус тут рассказывает про продолжения.... да кому они нужны?