JSF, жручесть.

Чисто субъективно - тормозить скорее всего не будет. Тока как ты собираешься jsf на jetty запускать? Оно разве без бубна взлетает?

Насчет простоты. Вроде щас есть множество чудных js-фреймворков. Бери да пользуйся. Но придется покодить на js, да. Это я в пользу Spring MVC как бе. Щя вот смотрю Spring 3.1 обещает быть вкусным. Может вернусь на него с Guice.

>Но придется покодить на js, да.
бекенд вес равно на бинах делать.

Минусы: жрет и тормозит.

Тачка одноядерная, до 2 ГГц, 512 МБ-1 ГБ ОЗУ (точно не помню)

ну это смешно, блин. Нахрена привлекать дорогостоящих джавистов, если у компании нет денег на нормальный сервер? Зачем на эту компанию работать? Это ж бесперспективняк. Или выбей денег на нормальный сервер аргументируя или сваливай. В предложенных рамках задача нерешаема.

Убунтоиды смешные. По теме, несильно.

Вроде щас есть множество чудных js-фреймворков. Бери да пользуйся. Но придется покодить на js, да.

JSF 2.0 — это и есть «поднос» для AJAX. Только на JavaSript ничего писать не не нужно — всё нужное уже написано в этой библиотеке.

Если программой будут пользоваться одновременно 30 человек клацая по ссылкам (сеанс сдачи теста в системе тестирования) - будет ли она ужасно тормозить в случае выбора JSF?

Даже для 512 МБ ОЗУ Java можно оттюнить так, что всё будет летать.

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

>Явное лучше не явного, так что мне js спокойнее ручками писать.
ага, и пока вы все еще пишете ручками, мы уже выпускаем третью бету в лайв.

Даже для 512 МБ ОЗУ Java можно оттюнить так, что всё будет летать.

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

Дорогостоящие джависты - джависты, которые по воле судьбы ходят на военную кафедру, компания бесперспективняк - военная кафедра.

Заводится с пол пинка, Mojarra же

ах, если так, то да)
в целом, летать будет, если критически тяжелых контролов вроде деревьев/таблиц не будет. Если там поля и кнопки - взлетит на ура. А если тебе хватит JSF RI и ты не будешь испольовать другие библиотеки - почти гарантированно будет летать.

Прохождение теста - далее, далее, далее. Небольшие JS свистоперделки от PrimeFaces сильно повредят? В основном это же темки прикольные и разные JS окошки. И еще Push чтобы принудительно вырубить прохождение теста когда истечет время

>Прохождение теста - далее, далее, далее. Небольшие JS свистоперделки от PrimeFaces сильно повредят? В основном это же темки прикольные и разные JS окошки. И еще Push чтобы принудительно вырубить прохождение теста когда истечет время
я думаю, не повредят.

http://vaadin.com/home

Я считаю, что нельзя что-то искусственно ускорять. На долгосрочной перспективе не работает.

> 1. JSF/Primefaces. Плюсы: удобно делать всякие прикольные навороты, Ajaxанутые виджеты искаропки. Минусы: жрет и тормозит.
Оно удобно до тех пор, пока заказчик/начальство не говорит сделать что-то не стандартное. И то что с помощью jQuery бы сделал за пару часов становится совсем^Wпочти не возможным.

скажите это гуглу.

да и вообще всем адептам agile-подхода

>Оно удобно до тех пор, пока заказчик/начальство не говорит сделать что-то не стандартное. И то что с помощью jQuery бы сделал за пару часов становится совсем^Wпочти не возможным.

вы категорически путаете отображение данных и UI framework.
jQuery шикарен ровно до тех пор, пока надо лишь выводить данные. Как только появляется задача хендлить пользовательский ввод, jQuery бессилен и надо прибегать UI framework-ам.

Но ведь jQuery (+ plugins) это не только эффекты для гуя? Это еще и обработка пользовательского ввода: от валидации и до виджетов.

Я самый что ни на есть agile программист с опытом по scrum, kanban, xp сейчас вот изучаю fdd. И мой опыт говорит о том, что во все нужна мера. У agile подходов есть особенность: легко скатиться к говнокодингу, так как все это на грани. Прописывая компоненты ручками, ты инвестируешь в технологии, тем самым делая кривую стоимости изменений более пологой. Что касается задержки при выпуске первых версий продукта, то я бы предпочел показывать демо продукта вообще без ajax. Зачем прикручивать свистоперделки, если еще нет фидбека от заказчика?

но это никоим образом не относится к бекэнду, где фактически происходит процессинг данных. jQuery и плагины - это именно и исключительно эффекты для гуя.

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

то я бы предпочел показывать демо продукта вообще без ajax. Зачем прикручивать свистоперделки, если еще нет фидбека от заказчика?

я имел в виду не конкретно jQuery vs JSF, а саму позицию: больше писать руками. На мой взгляд, чем продуктивнее разработка, тем лучше для проекта. И надо максимально отдавать черновую работу фреймворкам, концентрируясь на бизнес-фичах, важных для пользователей, нежели на деталях реализации.

или я тебя не понял или все таки, чем больше кастомного кода написано, тем выше задирается кривая стоимости изменений?

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

На мой взгляд, чем продуктивнее разработка, тем лучше для проекта.

Тут нужно еще узнать о какой области идет речь. Если это заказная разработка «под ключ», то может быть ты и прав: важно быстрее сдать проект и все. Но у меня как-то попадаются только долгоиграющие проекты. Писать код, что бы впоследствии его выбросить не рационально. Кастомный код ты можешь рефакторить и развивать. Сложные сторонние компоненты обычно либо устраивают, либо нет. Когда они перестают устраивать, то их просто выкидывают. Вот пример: есть проект, довольно большой. Из него сейчас пытаются выпилить древний орм, и встроить хибернейт. Если бы проект писался изначально на голом sql или своем орм (нормальных орм в то время просто не существовало), то так бы и развивался до сих пор, без всяких революций.

Я на предыдущем проекте натерпелся самописного ORM на JDBC пятилетней давности. Для нас раем было писать сторонние модули, которые не зависели от основных DAO. Ведь тогда можно было использовать Hibernate, а не самописный ORM.

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

Этот пример говорит о том, что без поддержки некоторого решения, оно (решение) загнется. И это касается всего - голого SQL, самописного ORM, хибернейта. Вопрос только в цене поддержки. Если бы он писался на голом SQL или самописном ORM, поддержка была бы существенно сложнее. Поэтому на тот момент создатели имхо пошли правильным путем. Неверным было то, что с развитием технологий никто не озаботился поддержкой.

Поэтому на тот момент создатели имхо пошли правильным путем.

Ты не видишь собственно проблемы :) Да, их решение было оправданы, но на очень не долгую перспективу. Разработчикам тогда не хватило профессионализма признать, что тот орм - уг. Они вот так наивно рассуждали, что возьмут модную в то время поделку и сделают по-быстрому.

По моему опыту свои поделки в проектах появляются по двум причинам: от высокого профессионализма и от его недостатка. Если от самописного орм пришлось натерпеться, то он был сделан по второй причине.

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

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

А зачем такие навороты? Вообще не должен тормозить. По крайней мере на Glassfish бы не тормозило. И еще - а чем простые JSP не устраивают? Судя по описанию задачи - как раз бы хватило бы.

Чтобы радовало глаз. А завершение теста реально push нужен, чтобы все понятно было.