Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, _Oleg_, Вы писали:

_O_>>GWT позволяет довольно удобно и быстро разработать тонкий клиент, с довольно таки "богатым" наполнением.
B>Тот же вопрос что и к предыдущему оратору. Какое это иммет отношение к исходному вопросу?

Исходный вопрос:

Начинаем новый небольшой WEB-проект:
десяток страниц; в основном поиск, создание, удаление (сложных) Hibernate-обьектов.
...

Hibernate — это уже решение проблемы внутри проекта, а не условие задачи проекта.
Hibernate никто не возбраняет применить на серверной стороне.

Здравствуйте, _Oleg_, Вы писали:

_O_>Hibernate — это уже решение проблемы внутри проекта, а не условие задачи проекта.
_O_>Hibernate никто не возбраняет применить на серверной стороне.

Что-то вы из view в DAO и обратно. Для чего так скакать? У автора достаточно большой набор бинов. Как GWT поможет замапить эти бины на UI?

Здравствуйте, toxin, Вы писали:

T>Моим аргументом может быть то, что я его ел Уже 2 месяца участвую в разработке проекта, где в качестве View использован GWT. И ничего все живы. На начальном этапе пришлось конечно приложить зубило и какую-то мать, но в данный момент все работает очень даже стабильно.

Я его тоже ел, хотя и не в комерческих масштабах. Огреб кучу граблей, пока не столкнулся с одной почит непреодолимой проблемой в интеграции своих JS в GWT приложение.

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

К сожалению это не единственный минус. Кроме этого я что-то не понял логики в утверждении выше.
GWT->Много скрипта, но у нас большое приложение поэтому много скрипта не так важно. И тут почему-то вывод, что для небольшого приложения GWT годится.

B>>Как это кореллирует с исходным вопросом?
T>С исходным никак, это было замечание на утверждение, что GWT — это суксь.
Ну, мог бы в топике ссылук на котоый я давал и поопровеграьт все мои доводы. А то пока мы видим только один аргумент — "я попробовал у меня получилось"

Здравствуйте, Nicht, Вы писали:

N> программист сидит и париться с этим недоязыком под названием XSL.

Вы просто не умеете их готовить (с)
Лично мне стало немного проще работать с XSL, после того как я познакомился с функциональным программированием (в частности Scheme). Конечно, много логики туда не напихаешь... А вот и не нужно В кукуне XSLT, имхо, на нужном месте, а там, где нужно логику позаворотистей — пишем Жаву

Здравствуйте, Gajdalager, Вы писали:

G>Здравствуйте, Nicht, Вы писали:

N>> программист сидит и париться с этим недоязыком под названием XSL.

G>Вы просто не умеете их готовить (с)
G>Лично мне стало немного проще работать с XSL, после того как я познакомился с функциональным программированием (в частности Scheme). Конечно, много логики туда не напихаешь... А вот и не нужно В кукуне XSLT, имхо, на нужном месте, а там, где нужно логику позаворотистей — пишем Жаву

А кто спорит?
XSL хорошая весчь, только для того что бы xml переформатировать. Для этого он и сделан был. Но то использование, что писали здесь ранее, это мягко говоря не поле деятельности XSL.

Причем самое смешное, что как раз опыт с таким использованием у меня был. И я на себе испытал, во что превращается эти xsl преобразования после n-ой итерации и изменения техзадания. Это был тихий ужас.

Здравствуйте, Blazkowicz, Вы писали:

B>Я его тоже ел, хотя и не в комерческих масштабах. Огреб кучу граблей, пока не столкнулся с одной почит непреодолимой проблемой в интеграции своих JS в GWT приложение.
Пока не возникало желания интегрировать рукописный JS. Все проблемы решаем средствами исключительно самого GWT.

B>К сожалению это не единственный минус. Кроме этого я что-то не понял логики в утверждении выше.
GWT->>Много скрипта, но у нас большое приложение поэтому много скрипта не так важно. И тут почему-то вывод, что для небольшого приложения GWT годится.
Да, извиняюсь, немного коряво выразился. Постараюсь быть более последовательным. Приложение создается от начала и до конца средствами GWT никаких побочных самописных HTML'ин и рукописного яваскрипта не используется. Размер яваскрипта получается настолько большим (уже ~600kb), что уже возникают мысли о разделении приложения на несколько более мелких, с потерей некоторой функциональности и необходимости синхронизации всего этого дела между собой. Отсюда и вывод, что для небольшого веб приложения (что быстро дернули с сервера, красиво показали, отредактировали(заавтокомлитили), проверили правильность ввода, сохранили на сервере, поздравили пользователя, уложились в 50кб яваскрипта) оно еще годится, но для большего нужно использовать уже другие средства.
B>Ну, мог бы в топике ссылук на котоый я давал и поопровеграьт все мои доводы. А то пока мы видим только один аргумент — "я попробовал у меня получилось"
Не сочти за наезд, но все же. Твое сообщение из того топика, по сути самый убойный аргумент:

Ну и окончательное разочарование:
скрипт GWT каким-то образом фильтрует перехватывает то ли все события то ли ещё что. Разбираться лень. Но код JS на странице куда заинтегрированы GWT виджеты перестаёт работать. Думаю что обработчики событий не вызываются.

аргумент — "Я попробовал у меня НЕ получилось"

Резюме от вышенаписанного:
Я никого не агитирую за использование GWT (мне Гугль за это денег не платит).Даже наоборот

Автор: toxin
Дата: 01.11.06

. Я просто против однозначного ярлыка "суксь" в отношение GWT. И у меня только один аргумент — "оно работает", а как говорится в теории автоматического управления — "любая работающая система оптимальна по какому либо показателю"

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, _Oleg_, Вы писали:

_O_>>Hibernate — это уже решение проблемы внутри проекта, а не условие задачи проекта.
_O_>>Hibernate никто не возбраняет применить на серверной стороне.

B>Что-то вы из view в DAO и обратно. Для чего так скакать? У автора достаточно большой набор бинов. Как GWT поможет замапить эти бины на UI?
Никак, обширное поле для ручной кодогенерации

Здравствуйте, toxin, Вы писали:

T>Никак, обширное поле для ручной кодогенерации

Я ж про то же ж.

Здравствуйте, Blazkowicz, Вы писали:

B>Комбинации которые мы применяем это:
B>Tapestry + Spring IoC и там стоко всего полезного не перечислить.
B>Spring MVC + Velocity если UI не так много, я чаще склоняюсь именно к этой комбинации,

А что вы посоветуете для java1.4.2? К чему бы вы склонились?

Здравствуйте, TheOldMan, Вы писали:

TOM>А что вы посоветуете для java1.4.2? К чему бы вы склонились?

Spring, на сколько я знаю, совместим с Java 1.4

Здравствуйте, Blazkowicz, Вы писали:

B>Spring, на сколько я знаю, совместим с Java 1.4

Spring, пожет успешно использоваться без AOP (Java 1.4 же не поддерживает нотаций)?

Здравствуйте, TheOldMan, Вы писали:

B>>Spring, на сколько я знаю, совместим с Java 1.4

TOM>Spring, пожет успешно использоваться без AOP (Java 1.4 же не поддерживает нотаций)?

Аннотаций, а не нотаций. По-моему в спринге их банально нет. Не могу точно сказать за последнюю версию её ещё не сморел.
А в Spring AOP он через AspectJ кажись реализован.

Здравствуйте, Blazkowicz, Вы писали:

B>Аннотаций, а не нотаций.

Спасибо

B>По-моему в спринге их банально нет. Не могу точно сказать за последнюю версию её ещё не сморел.
B>А в Spring AOP он через AspectJ кажись реализован.

Что ж, буду пропобовать

Здравствуйте, Blazkowicz, Вы писали:

TOM>>Spring, пожет успешно использоваться без AOP (Java 1.4 же не поддерживает нотаций)?

B>Аннотаций, а не нотаций. По-моему в спринге их банально нет. Не могу точно сказать за последнюю версию её ещё не сморел.
Срочно смотреть. Вообще немного добавили, чисто для декларации транзакционных методов (@Transaction), для указания того, что проперти должен быть обязательно заиньекчен
(@Required) и еже стереотипный маркер @Repository, типа для пометки DAO-классов. Вроде юзается, если ДАО, например, реализован не через спринговые теплейты, и кидается исключениями реализации (ну там всяки HibernateException и так далее). Так вот спринг автоматом будет конвертировать эти исключения в свои из dao пакета, если класс в котором реализован метод помечен этим маркером. Больше пока ничего не припомню, но моя бы воля — я бы понавтыкал туда аннотаций.

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

B>А в Spring AOP он через AspectJ кажись реализован.
Нет. Он там все-таки через динамические прокси реализован (или сановские или CGLIB-овские или какие захоцца, но писать самому).
Они добавили и даже сделали его основным синтаксис поинткатов из AspectJ (немного ограниченый), а так же сделали поддерку ApsectJ 5.0 аннотаций. Ну, т.е. например сейчас можно просто написать класс

@Aspect 
public class SomeAspect {
    @Before("execution(* SomeService.someMethod(someParam, ..))")
        someBeforeAdvice(SomeClass someParam) {
          //do something;
        }
}

и добавить бин этого класса в контекст, и аспект подцепиться и начнет вейвиться куда надо. Для 1.4 осталась поддержка конфигурябельности аспектов/адвайсов/поинкатов через xml.

Здравствуйте, Lucker, Вы писали:

B>>А в Spring AOP он через AspectJ кажись реализован.
L>Нет. Он там все-таки через динамические прокси реализован (или сановские или CGLIB-овские или какие захоцца, но писать самому).

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

Здравствуйте, Аноним, Вы писали:

B>>так может XML-XSLT тогда то же нафиг? Делов-то для пары десятков бинов CRUD запросы наколбасить и в JSP связать с формами!

А>в отличии от струтсов и прочей дребедени это даёт сокращение кода и разделение компонентов приложения.

А>Соединиться с базой, сделать запрос и отдать его в хмл — в пределах 100 строк кода. Преобразовать по XSL-шаблону и отдать браузеру — ещё 100 строк.

А>Получается запросы отдельно, шаблоны отдельно.

А>Но надо знать SQL, XSL и HTML.


Стоп. А логика domain model куда пойдет? Сюда

Соединиться с базой, сделать запрос и отдать его в хмл — в пределах 100 строк кода

или сюда

Преобразовать по XSL-шаблону и отдать браузеру — ещё 100 строк.

?

Здравствуйте, Аноним, Вы писали:

B>>Отдать запрос в XML? Кстати, отличная оценка трудозатрат проекта — 100 строк здесь, 100 строк там. Надо взять на вооружение. И все это без постановки задачи. Зачет!

А>постановка задачи:

А>- взять из HttpServletRequest переменные, составить по ним запрос к базе, выполнить и преобразовать результат в хтмл. Трудозатраты — примерно 100 строк кода.
А>- взять с диска XSL-файл, преобразовать по нему данные в хмл и результат отдать в HttpServletResponse. Трудозатраты — примерно 100 строк кода
чо т я сомневаюсь в 100 строчках кода для жабы и вот почему:
1) валидацию сделать надо
2) обработку ошибок надо
3) запрос построить (желательно от sql inject обезопасица)
4) из результатов собрать объекты
5) объекты сериализовать в xml
Вот у меня есть объект Заказ с 10 полями и листом Позиций по 7 полей. Нужно написать редактирование всего этого барахла.

Далее.
Тормознутость xslt притча во языцах. Структурированность также не на высоте. В более менее больших проектах количество xslt шаблонов превосходит сотни штук. При отстутствии нормальных редакторов (хотя я может и не видел) рефакторинг и просто использование этой тучи темплейтов печалит


Лобовое решение первой задачи в сравнении с хибернейтом просто отдыхает. Вот где не больше 20 строчек. А если сюда добавить тейпестри или другой нормалььный компонентный фреймворк то ....
Решение задачи вывода на тейпестри преимущест по размеру кода конечно не даст. Ну за исключением всяких удобных валидаций и т.д.
Ждите продолжения трансляции

чего-то по работе показать конечно нет смысла но вот мой опенсорсный проект

http://www.javakonkurs.ru/show_project.screen?project_id=111

сделан именно так. Самый большой класс меньше 300 строк.

Здравствуйте, Безон, Вы писали:

Б>Далее.
Б>Тормознутость xslt притча во языцах. Структурированность также не на высоте. В более менее больших проектах количество xslt шаблонов превосходит сотни штук. При отстутствии нормальных редакторов (хотя я может и не видел) рефакторинг и просто использование этой тучи темплейтов печалит

А) Рефакторинг XSLT это нонсенс. XSLT функциональный язык, строится на шаблонах, нужно что-то поправить — переписал шаблон и все. Куда там можно влепить рефакторинг, к примеру "Extract method" или "Replace Data with Object"?

Б) Oxygen oxygenxml.com редактор с поддержкой рефакторинга XSLT, правда таковой там сводится к двум операциям:http://www.oxygenxml.com/demo/XslRefactoring/XSLRefactoring.html

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Безон, Вы писали:

Б>>Далее.
Б>>Тормознутость xslt притча во языцах. Структурированность также не на высоте. В более менее больших проектах количество xslt шаблонов превосходит сотни штук. При отстутствии нормальных редакторов (хотя я может и не видел) рефакторинг и просто использование этой тучи темплейтов печалит

А>А) Рефакторинг XSLT это нонсенс. XSLT функциональный язык, строится на шаблонах, нужно что-то поправить — переписал шаблон и все. Куда там можно влепить рефакторинг, к примеру "Extract method" или "Replace Data with Object"?

А если переименовать? Сделать find usages, ну и мало ли какие заморочки могут быть. С локализацией опять таки беда. Ну и самая большая беда это производительность! Что можете сказать по этому поводу?

А>Б) Oxygen oxygenxml.com редактор с поддержкой рефакторинга XSLT, правда таковой там сводится к двум операциям:http://www.oxygenxml.com/demo/XslRefactoring/XSLRefactoring.html
То есть помимо идеи мне нужно юзать еще один редактор?