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

Почему JSF, а не Spring MVC или Struts?

iZEN> Весь стек Java EE для Web не нужен.

Он хотя бы нужнее freebsd :3

Если ты только набираешь опыт в веб-деве, то это будет хорошо, но если уже имеешь и нужно выбрать инструмент для сложного проекта, то я бы посоветовал много раз подумать, т.к. после первой тысячи посетителей в день, на RoR можно ощутить большие проблемы производительности.
Сейчас есть 3 «платформы»: Java(Grails, Spring, Play-fw etc), Ruby(Rails), Python(Django, Flask, Pyramid). Есть и Node.js, как я уже писал выше, но я с большим сомнением отношусь к нему.
Между ними и выбирай.

Ну, вообще говоря, JSF, Spring, PHP etc долго ещё будут висеть в верхушке, потому как на западе работы много для них, а вот RoR не сдулся, он процветает. Просто из стадии «вы посмотрите какой няшный фреймворк!» он перешёл в стадию «просто юзать, потому как удобно».

Тред в куски. Ты осторожнее.

Почему JSF, а не Spring MVC или Struts?

Struts — седая старина.

По JSF 2.0 вышла новая книжка «JavaServer Faces. Библиотека профессионала, 3-е издание», Дэвид М. Гери, Кей С. Хорстманн.

Spring MVC — это немного нестандартная альтернатива JSF от сторонней компании.

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

Тогда и не любой лисп сгодится.

> Тогда и не любой лисп сгодится.

Конечно. Но зачем нужен Lisp, когда есть Scheme?

А как GWT с этим всем добром пляшет? Или в джава-вебе тоже царит jQuery?

GWT и jQuery никаким боком к частям Java EE не относятся.

Чувак, а на чем же динамику страниц писать?

выбирай пыхпых, голодным никогда не останешься .)

JSF + AJAX, естественно.

Шутник? AJAX чем делать, руками?

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

Что лучше для сайтописания: Lisp VS Perl VS PHP VS Tcl VS Ruby VS Smalltalk VS Scala VS etc.?

Буду оригинальным: Oracle Application Express (Oracle APEX)!

А на этом сайте можно заказать себе демо-площадку размером вплоть до 50MB «чиста посмотреть» технологию удалённо, не тратя «любопытства ради» свои ресурсы на развёртывание.

Ложка дёгтя: сам APEX бесплатен, но ему для работы нужна Oracle DB, которая остаётся платной.

Есть и хорошая новость: существует бесплатный Oracle XE, где в инсталляторе Oracle DB 10g + APEX 2.2 «из-коробки», но имеются некоторые ограничения по функциональности (будет использовать только 1 процессор, только 1ГБ памяти и только 4ГБ пользовательских данных).

P.S. А, вообще, тот, кто способен диктовать свои условия в подобных вопросах, обычно давно уже определился с инструментами...

:-)

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

Продолжения - отличная штука, но только не для веб. Утверждающий обратное ничего в веб не понимает.

Хорошая штука, но мало распространена, привязана к одной недешёвой СУБД и от производителя, который здесь не популярен :)

> Но зачем нужен Lisp, когда есть Scheme?

А-а.. Не понял.

Пользуясь случаем. Есть для CL библиотека по созданию sequence expression на основе cl-cont? Sequence expression - это когда мы можем задать ленивую последовательность декларативно как в F#. Вот пример:

> // Sequence with a side effect
let noisyAlphabet =
  seq {
    for c in 'A' .. 'Z' do
      printfn "Yielding %c..." c
      yield c
  };;

val noisyAlphabet : seq<char>

> let fifthLetter = Seq.nth 4 noisyAlphabet;;
Yielding A...
Yielding B...
Yielding C...
Yielding D...
Yielding E...

val fifthLetter : char = 'E'

Ну если по востребованности то PHP
Как альтернативу могу посоветовать python c его DJANGO
perl с его Catalyst
ruby с RoR.

> Есть для CL библиотека по созданию sequence expression

на основе cl-cont?

Совершенно не в курсе. cl-cont разработана для weblocks, а я категорически против подобных фрэймворков. Впрочем, можешь ещё посмотреть dwim.hu - там вроде своя реализация продолжений, а уровень веществ значительно выше )

P.S. Реализовать полноценные продолжения для CL нельзя, это всегда костыль.

Вот чудак-анонимус, зачем же тогда JSF?

http://java.sys-con.com/node/1352885

HTML+JavaScript, можно ещё HTML5. Если найдёшь хоть одно хорошее руководство на своём родном языке.

Спасибо, посмотрю. А про костыль я в курсе. Смотрел код cl-cont.

Как продолжения связаны с TCO (tail call optimization?)?

> Продолжения - отличная штука, но только не для веб. Ок. Как же на языке без поддержки продолжений будет выглядеть какая-нибудь простенькая модель взаимодействия с пользователем? Ну например - показать страницу с формой запроса некоторого числа n, потом показать поочередно n страниц, с формой запроса числа на каждом, и далее вывести страницу с суммой этих n чисел? С континуациями это будет так: (display-number (apply + (build-list (get-number) (lambda (x) (get-number)))))

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

Вы свой каменный век покиньте и почитайте что-нибудь про REST, да про AJAX.

Ну с этого нужно было и начинать.

То есть без продолжений решение этой задачи весьма нетривиально и вы не можете его привести. Чего и следовало ожидать. Кстати, с каких пор аякс перестал быть stateless? И как он в данном случае избавляет вас от надобности пидорасить запрос?

> Продолжения - отличная штука, но только не для веб.

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

> Почему?

Интересуюсь исключительно из любопытства.

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

Если раньше (году этак в 95-ом) это имело какой-либо смысл, то сейчас, в виду развития технологий, использовать этот древний подход не имеет никакого практического смысла, от него только проблемы и больше ничего.

> Ну например - показать страницу с формой запроса некоторого числа n,

потом показать поочередно n страниц, с формой запроса числа на

каждом, и далее вывести страницу с суммой этих n чисел? С

континуациями это будет так: (display-number (apply + (build-list

(get-number) (lambda (x) (get-number)))))

Поверите, что полное решение на JavaScript будет гораздо проще и надёжней вашего?

Ясно, спасибо за за ответ

> Фрэймворки на пр одолжениях пытаются создать видимость, что HTTP имеет состояние.

Чушь. Вы совершенно не понимаете, что такое продолжения. В HTTP как раз изначально закардкожено понятие «состояния» в запросе. И вам приходится работать с ним (с этим состоянием) руками. При использовании продолжений никакого состояния нет. Вот это главная проблема веб-разработчиков - иначе как в рамках состояний конечного автомата они мыслить просто не в состоянии.

Получается ресурсоёмко, совершенно не масштабируемо

С какой это стати?

понятие ссылки теряет какой-либо смысл.

Вот именно. Это и есть смысл продолжений - вам не приходится контролировать состояние приложения вручную через ссылку. Можете считать, что у вас вообще нет ссылок. Они в данном случае не нужны.

> Поверите, что полное решение на JavaScript будет гораздо проще и надёжней вашего?

Вы приведете решение или нет? Вам так долго написать пол строчки?

Ну это сильно на любителя. Я вот люблю все ручками прописать. Ну я таки да, известный jsf-hater :) Абстракии и на*балово - это не одно и тоже. Вот что есть абстракция, а что на*ебалово я и считаю главным вопросом в технологии программирования.

По теме - мне сейчас наиболее оптимальным выбором кажется Scala, либо Python. Ну или Java, но у нее verbosity высоковата, хотя жить можно, я с этим научился даже как-то бороться.

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

grails

> В HTTP как раз изначально закардкожено понятие «состояния» в запросе.

Да вы что такое говорите? Ещё раз, погуглите на тему REST.

При использовании продолжений никакого состояния нет.

Как же нет, когда есть? В weblocks раньше даже такая кнопка была, типа «сбросить сессию».

Получается ресурсоёмко, совершенно не масштабируемо

С какой это стати?

Потому что нельзя к этому делу приставить систему балансировки нагрузки.

понятие ссылки теряет какой-либо смысл.

Вот именно.

Бу-га-га. Я так люблю ссылки. Их можно опубликовать на сайте или отправить друзьям. А вы предлагает вернуться в каменный век.

> Вы приведете решение или нет? Вам так долго написать пол строчки?

Если вам не трудно, то приведете сначала своё решение, потому что выше было не решение, а только его малая часть. Тогда и будем сравнивать.

> Да вы что такое говорите? Ещё раз, погуглите на тему REST.

И?

В weblocks раньше даже такая кнопка была, типа «сбросить сессию».

И при чем тут состояние, о котором вы говорите? Я задам простой вопрос - вот вы если пишете (display (+ (read) (read))) - вы тут задумываетесь о каких-либо состояниях? Нет. Это и есть стиль написания приложений с использованием континуаций. А теперь напишите то же самое с использованием конечного автомата - вам придется явным образом обрабатывать состояние. Это и есть современный стиль написания веб-приложений.

Потому что нельзя к этому делу приставить систему балансировки нагрузки.

Да кто вам сказал-то?

Бу-га-га. Я так люблю ссылки. Их можно опубликовать на сайте или отправить друзьям.

Ссылок «нету» для программиста. А для пользователя - есть.

> А теперь напишите то же самое с использованием конечного автомата

- вам придется явным образом обрабатывать состояние. Это и есть

современный стиль написания веб-приложений.

О каком конечном автомате вы толкуете? Что то я применительно к современным веб-приложениям никак не могу этого понять.

Потому что нельзя к этому делу приставить систему

балансировки нагрузки.

Да кто вам сказал-то?

Для корректной обработки «продолжений» запрос должен поступать на тот самый сервер, который держит сессию. Какая тут может быть балансировка?

Ссылок «нету» для программиста. А для пользователя - есть.

Что показывается по ссылке зависит не только от ссылки, но и от состояния (которого вы утверждаете нет). В итоге, я хотел послать другу сиски, а у него там какие-то ромашки открываются.

>Там же написано etc. (и другие), просто я начинающий веб-программист и хотел бы сразу начинать с Ъ и того что будет применимо, а не набивать шишки, которых можно избежать

То есть ты желаешь не программировать, а быть Ъ? И писать на не Ъ языках тебе претит, вот ты и пришёл с вопросом, что есть Ъ? В 15 лет это бывает…

Если вам не трудно, то приведете сначала своё решение, потому что выше было не решение, а только его малая часть.

прекрасно, с этого и надо было начинать. Привожу полное решение:

(define (get-number)
  (string->number 
   (extract-binding/single 'number
                           (request-bindings (send/suspend 
                                              (λ (k-url) (response/expr (include-template "get-number.html"))))))))

(define (start req)
  (response/xexpr `(html ,(apply + (build-list (get-number) (λ (x) (get-number)))))))

get-number.html пишет человек, ответственный за верстку, ясное дело. Нас не волнует, что там.

> О каком конечном автомате вы толкуете? Что то я применительно к современным веб-приложениям никак не могу этого понять.

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

Для корректной обработки «продолжений» запрос должен поступать на тот самый сервер, который держит сессию.

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

> Что показывается по ссылке зависит не только от ссылки, но и от состояния (которого вы утверждаете нет). В итоге, я хотел послать другу сиски, а у него там какие-то ромашки открываются.

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

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

var sum = 0;
$("input").each( function (i, input) { sum += parseInt($(input).val()); } );
alert(sum);

> Любое современное веб-приложение - конечный автомат. Оно парсит

запрос и в зависимости от состояния (которое передается в запросе)

делает бла-бла-бла.

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

Вобщем-то это ограничение, накладываемое протоколом. Другое дело,

что продолжения позволяют эффективно скрыть этот факт.

Это не ограничение, это фундаментальная основа. А костыль не может ничего делать эффективно в силу своей костыльности. Нельзя эффективно перевернуть основу веб.

Есть сериализуемые продолжения, которые можно хранить

в тех же cookies.

Вы верно издеваетесь. Вы в курсе, что cookies имеют ограничения на размер? Да если бы даже не имел, таскать постоянно туда-сюда всё состояние? Оно же может быть очень большим.

Но это для всех веб-приложений верно, при чем тут континуации?

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