LINUX.ORG.RU

> XScript

Нет, не слышали.

anonymous
()

Передернуло когда кто-то назвал спринг библиотекой. Хотя вообщем-то библиотека.

А что такое XScript?

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Передернуло когда кто-то назвал спринг библиотекой. Хотя вообщем-то библиотека.

ну реальные пассаны это называют framework, ага

А что такое XScript?

яндексовская штука для преобразования XML/XSLT.

xpahos ★★★★★
() автор топика

> Склоняемся к Spring. Люди вот тут советуют XScript.

склоняемся к жопе, а люди советуют палец. помогите сравнить жопу с пальцем.

heisenberg ★★
()

Может задачу распишите? А то как то сложно советовать без понимания на фига оно. Навскидку можно еще использовать для контроллеров и бизнес -логики Play, EJB3(мне понравились) и много чего. Если конкретно для морды - JSF, Struts, Wicket.

TheKnight ★★★
()

щас тут такое начнется....

Советую стек java ee 6 - наилучший вариант на сегодня. JPA 2.0+ EJB 3.1 + Weld + JAAS +
Сейчас работаем в такой связке под glassfish v3 - проект успешен.
И да, спринг нынче ужасен, стратс неактуален уже года 4. Викет более-менее, подходит для тех, кто не осилил jsf lifecycle, простенький темплейтный движок. Но jsf, имхо, гораздо приятнее и на нем намного быстрее писать на всех стадиях - от дизайна до дебага.
А, ну и в качестве бонуса в таком случае вы автоматически получаете web services и rest services для вашего приложения и автоматический маршаллинг в/из XML для ваших бинов, поддержку embedded контейнера для тестов, поддержку мавена, автогенрацию классов из xsd. А так же много-много других плюшек, принятых крупнейшими разработчиками java ee.

JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM

Вот кстати в EJB3 мне понравилась простота конфигурации многих вещей. Сейчас изучаю Spring - пока не очень. приемлемо, но не очень. А JSF имеет ряд проблем, но во многих случаях - это хороший выбор. Работал с ним, правда так и не пришлось писать свои компоненты. Но принцип построения и способ осуществления этого - мне понравились) Со всем остальным не работал(

TheKnight ★★★
()
Ответ на: комментарий от TheKnight

Веб приложение. Я как бы больше за Python и после одной статьи по настройке Spring мне уже не хочется вообще этим пользоваться. Так столько аббревиатур трехбуквенных, которые куда-то подключаются. Плюс куча XML кода.

xpahos ★★★★★
() автор топика
Ответ на: комментарий от maloi

чож тогда яндексовский поиск не может её найти?

в паблике оно умерло уже 2 года как.

xpahos ★★★★★
() автор топика
Ответ на: комментарий от JFreeM

Спасибо. Почитаю. Сложновато разбираться в XXX, YYY, ZZZ и прочем.

xpahos ★★★★★
() автор топика
Ответ на: комментарий от xpahos

>Плюс куча XML кода. Ну, не такая уж и куча.

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

OramahMaalhur
()
Ответ на: комментарий от JFreeM

Быстрее, если знаешь, как. А тащить всего java ee 6 монстра, зарываться в тонну документации, - может, проект и не стоит того?

OramahMaalhur
()
Ответ на: комментарий от OramahMaalhur

>java ee 6 монстра
не монстр он, в том то и фишка. Оно намного легче и меньше того же спринга.

может, проект и не стоит того?

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

JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM

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

Я почти уверен, что они пока дружно выбирают, что учить :)

OramahMaalhur
()

XSript использовали, в итоге отказались и сделали свою версию агрегатора - https://github.com/hhru/frontik

Есть еще mail.ru-шный FEST Вообще подход «агрегация XML от бекенда» очень хороший, на него с радостью перешли со всяких Spring/Struts/JSP/JSTL. Но это при условии, что вы реально хотите построит хорошую архитектуру. Если хотите без заморочек «а бы работало», то это не для вас.

Почитать про агрегацию можно здесь: http://andrewsumin.livejournal.com/55370.html

dizza ★★★★★
()
Ответ на: комментарий от JFreeM

Но jsf, имхо, гораздо приятнее и на нем намного быстрее писать на всех стадиях - от дизайна до дебага.

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

dizza ★★★★★
()
Ответ на: комментарий от JFreeM

не монстр он, в том то и фишка. Оно намного легче и меньше того же спринга.

А вот тут по-подробней. Чем же по-твоему спринг тяжелее?

ЗЫ. У спринга есть killer feature - он очень быстро развивается и вглубь и вширь (готовые интеграции на все случаи жизни). А мажорные релизы JEE-шных спецификаций выходят раз в 20 лет. Но если оно сейчас реально стало легче спринга, то очень даже интересно.

dizza ★★★★★
()
Ответ на: комментарий от OramahMaalhur

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

нагрузка большая, да. тырпрайз не нужен. Если бы был жив Python -> LLVM транслятор гугловский, то проблемы сразу же отпали :)

xpahos ★★★★★
() автор топика
Ответ на: комментарий от maxcom

если много XML, то значит дока на старый Spring. В 3.x XML сильно меньше

Да. Я так понимаю, что это все из-за статической типизации Java.

xpahos ★★★★★
() автор топика
Ответ на: комментарий от dizza

Есть еще mail.ru-шный FEST Вообще подход «агрегация XML от бекенда» очень хороший, на него с радостью перешли со всяких Spring/Struts/JSP/JSTL. Но это при условии, что вы реально хотите построит хорошую архитектуру. Если хотите без заморочек «а бы работало», то это не для вас.

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

xpahos ★★★★★
() автор топика
Ответ на: комментарий от xpahos

Учти еще, что архитектурное разделение слоев особенно полезно при соответствующем разделении команд.

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

Опять же нужно смотреть а нужно ли это вам? Если системы маленькая (и комманда тоже), особо не мудрите. Возьмите какой-нибудь django/kohana/rails и вперед.

dizza ★★★★★
()
Ответ на: комментарий от dizza

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

Да, я понимаю это. В идеале я бы взял то, что использует Facebook для построения интерфейсов на JS. Но тут уже решаю не я, я только предлагаю :)

Опять же нужно смотреть а нужно ли это вам? Если системы маленькая (и комманда тоже), особо не мудрите. Возьмите какой-нибудь django/kohana/rails и вперед.

Я предлагал Tornado, но как-то не очень хотят Python. Для меня это было бы действительно проще, т.к. с Python чаще сталкиваюсь.

xpahos ★★★★★
() автор топика

Play Framework

Сабж. А также Wicket и... GWT =)

stevejobs ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.