Статті · 29 липня 2008, 8:46 2220

Замечательный Wicket

💡 Усі статті, обговорення, новини про Java — в одному місці. Приєднуйтесь до Java спільноти!

Все гениальное просто

Год назад я работал в Циклуме над веб проектом. Проект состоял из сотен HTML страниц. Хотя мы использовали Spring MVC, не было ощущения что с GUI все в порядке, знаете почему? Потому что использование одного компонента на разных JSP страницах не совсем так элегантно как хотелось бы. Это проблема касается не только Spring MVC, это проблема для workflow фреймворков, то есть не компонентных фреймворков. Если вы хотите использовать компонент на многих страницах, вам нужно:

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

В таком случае есть смысл отказаться от workflow фреймворка и использовать компонентный фреймворк.

Я начал исследование компонентных фреймворков для Java. Первым кандидатом был JSF. После прочтения книги у меня создалось впечатление что JSF слишком сложен для использования. Несмотря на это, я скачал свежую версию ICEFaces и попробовал написать простое «Hello World» приложение с кнопкой и сообщением. Я потратил два часа на конфигурацию и шесть часов чтобы убрать эксепшен. Не помню точно что это была за ошибка, что-то про invalid JSF context.

Я решил что такой фреймворк мне не нужен. Разработка GUI не самая сложная часть нашей работы, соответственно фреймворк тоже должен быть попроще. Написание своих custom компонентов для JSF является настоящим кошмаром. Нужно написать три или четыре класса на один компонент. Тому есть объективные причины. JSF спроектировали чтобы можно было поддерживать разные рендереры. Например, можно перейти с HTML на WML изменив одну строку в конфиг файле. Но я думаю что WML исчезнет через пару лет, потому что количество мобилок которые отображают HTML растет с каждым годом. Я решил что не могу тратить свое драгоценное время на изучение JSF.

Итак, я сказал решительное «Нет» JSF. Альтернативами были Tapestry and Wicket. Я скачал Wicket и начал изучать документацию. Я был в хорошем смысле удивлен простотой этого фреймворка. Конфигурация предельно проста — нужно только добавит сервлет Wicket’а в web.xml.

Еще одна вещь которая мне нравится в Wicket, это разделение java кода и HTML кода, другими словами separation of concerns. Представьте что вы используете JSP и у вас есть команда состоящая из программистов и веб дизайнера. Обычно веб дизайнер работает с прототипом приложения в виде статических HTML страниц. Если нужно изменить HTML код, веб дизайнер меняет свой прототип и отсылает измнененные файлы программисту. Программист находит JSP, которые нужно изменить в соответствии с прототипом, и изменяет их. Я думаю что этот подход абсолютно неправильный. Если вы используете Wicket, забудьте про этот неправильный подход к правке HTML кода. Просто дайте дизайнеру изменить HTML, вот и все. Участие программиста для правки HTML кода не требуется, и я считаю что это отлично!

Если вы знакомы со Swing, освоить Wicket будет очень просто. Панель Wicket похожа на JPanel, а кнопка в Wicket совсем как JButton. Если нужно обработать HTTP запрос из формы, просто добавляете event listener к кнопке, совсем как в Swing.

Wicket интегрируется с Spring, поддерживает i18n, security. Если бы я сейчас начинал новый веб проект, то выбрал бы Wicket.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Теми: Java, фреймворк

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

anonymous 20.09.2010 22:48

Жаль тема уже не актуальна.Могу добавить только одно — начало книги Wicket in Action совершенно точно отражает суть вещей. JSF очень хорош для быстрого старта, особенно в купе с JBoss Seam. Но потом начинаются проблемы. Проблемы в основном из-за ограничения выразительных способностей платформы. Более того в архитектуру и спецификацию JSF заложены такие противоречия что просто делают генерализацию интерфейса неразрешимой задачей (за разумные деньги). Пример — JSF хорошо описывает жизненный цикл запроса. При этом жизненные циклы выражений в аттрибутах тэгов не специфицированы (хотел бы я посмотреть на reveng спеку — это какой бред получился бы, смотрите код JSF RI 1.2). Это приводит например к тому (особенно в куче с Facelets) что дизайнеры даже не понимают почему какое-то вырожение вычисляется как null, когда оно же на другой странице возвращает валидный объект. Это — самая простая из проблем с которыми постоянно сталкиваются JSF-centric разработчики.Мы за месяц переписали интерфейс на Wicket (который делали-делали на JSF полтора года). Это говорит о многом.Что я бы пожелал Антону Наумову — бог в помощь.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Речь у автора не про освоить, а про написать «Hello World» приложение с кнопкой и сообщением, за полчаса реально.Веб фреймворк должен легко использоваться программистом среднего уровня, но после надлежащего обучения работы с ним.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Cомневаюсь что можно освоить JSF за полчаса. Веб фреймворк должен легко использоваться программистом среднего уровня. Людей которые способны использовать emacs не так уж много.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Сильно сомневаюсь что можно освоить JSF за полчаса:)

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Скажу немного в защиту JSF, а то автор привел совсем детскую отмазку, почему его не нужно использовать. Программирование не всегда интуитивно, то, на что автор потратил драгоценные 6 часов времени, можно было освоить за полчаса, но прочитав и освоив документацию по JSF (jee tutorial), а не пытаться попасть пальцем в небо. Есть две категории инструментов: 1) технически сложный инструмент, который прост в обращении, но сложен в освоении (например emacs) 2) низкоэффективный, но интуитивно-понятный инструмент (например notepad) В исключительных случаях инструмент бывает интуитивным и эффективным одновременно. Пока в программировании я таких не заметил.Так вот JSF принадлежит к первой категории, для того, что бы его использовать нужно понимать и разделять философию этой технологии, заложенную авторами. Тогда создавать GUI используя JSF (+facelets) будет легко и приятно. Уместно вспомнить Пола Грехема, что инвестируя время в более сложную технологию, получаете конкуретное преимущество, поскольку можете выполнять технически более сложные задачи.

Відповісти

Підтримати

RUruskyi 20.09.2010 22:48

Використовуємо на проекті Wicket, Spring MVC, Hibernate, JAXB. З першого погляду Wicket справді простіший за той же Struts.Єдине, що мені не подобається — це іноді беззмістовні треки з помилками.Наприклад, одного разу я не вклав тег wicket: Container в div тег в розмітці і отримав такий stackTrace, що чорт голову зверне. І також тонка настройка є непростою. Тому в нас на проекті Wicket використовується для адміністративної частини web-аплікації.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Что не нравится в Wicket, то это то что очень уж активно использует сессию

Я решил выяснить сколько же памяти требует Wicket для хранения состояния своих компонент на сервере.Один из разработчиков Wicket сообщает что у него в одной сессии хранится от 15 KB до 100 KB данных Wicket.Тоесть если будут работать одновременно 10 000 пользователей то требуется 1 GB оперативной памяти для Wicket.Оригинал статьи тут.Начиная с версии 1.3 состояние компонент может храниться в кэше на файловой системе.Кроме этого, есть возможность управлять хранением данных в сессии с помощью detachable models

Відповісти

Підтримати

Ivan Luzyanin Lead Software Developer в EPAM 20.09.2010 22:48

Дополнительно в «копилку» Wicket хотел бы добавить то что HTML темплейты для Wicket не содержат логики. Ни капли! Только форматирование. Это моя самая любимая фича которая по настоящему разделяет представление от бизнес логики.Что не нравится в Wicket, то это то что очень уж активно использует сессию. Поэтому если нужна высокая производительность лучше взглянуть в сторону Tapestry.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Так, а чему там улыбаться, что «вы всё еще кипятите»? Заодно скажите, а правильные отступы тоже не всегда лучше?

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Я вообще нигде не говорил что мало кода это лучше.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Вообще то мне GWT нравится больше Wicket из компонентных. А еще на яве есть два занятных веб фрэймворка: Echo и wingS

Wicket отличается от перечисленных Вами фреймворков потому что его набор компонент в основном состоит из чистого HTML, а, GWT, Echo и Wings основаны на javascript’овых компонентах которые отрисовываются через операции с DOM страницы в браузере,. Поэтому, если предполагается что HTML Ваших компонент будет индексирован поисковиком и вы не хотите полагаться на javascript и ajax, то лучше использовать Wicket или Tapestry.

Відповісти

Підтримати

Yaroslav Nosa 20.09.2010 22:48

если кто-нибудь разделяет мой восторг насчет Wicket, напишите, пожалуйста, комментарий. Буду знать что не зря писал статью

Вообще то мне GWT нравится больше Wicket из компонентных. А еще на яве есть два занятных веб фрэймворка: Echo и wingS — последний вообще забавный, в точности копирует обьектную модель swing. А вообще.NET круче всех: -) К Товарисчам Ненависникам ЯвыНа JVM продвигается Groovy, который впитал в себя лучшее из явы и Питона, и при этом абсолютно безпроблемно с ней взаимодействует. Также есть там неплохой MVC — Grails. Я это к тому, что не надо так сгоряча — мол Ява это фигня, а Питон круче всех. Не Питоном единым.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

sum ([x.cost for x in order_items])

sum (x.cost for x in order_items) Два символа было лишних!

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Почему много?

Вот бы узнать!

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

Потому что много более чем [x.name for x in companies] илиsum ([x.cost for x in order_items]) но это не все то за что мы любим питон, есть еще ламбда функции и прочие полезные вещи, делающую работу с кодом более приятную, а код понятным.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Почему много?:)

Відповісти

Підтримати

anonymous 20.09.2010 22:48

>> 73, да это много кода.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

В следующей версии ActionScript будет “нечто среднее”: http://moock.org/lectures/newI.../

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

Опа! уже даже в Adobe Flex есть map, хоть и специфический.Сергей, кстати зачем флексу строгая типизация, это ж реально головняк в данном случае, или без этого никак?

Відповісти

Підтримати

anonymous 20.09.2010 22:48

А «у нас» так. Много кода?:) — Посчитать сумму заказа

var total : Number = 0;cart.forEach(function(order : Order, index : int, array : Array) : String {total += order.cost;})

— Вывести путь в иерархии

Тут зависит от модели иерархии, но в итоге будет чем-то похоже на следующий пример.

— Преобразовать массив данных одной структуры в другую (например массив имен из массива компаний)

var companyNames : String = companies.map(function(company : Company, index : int, array : Array) : String {return company.name;}).join(", ");

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

2mguОтлично, делается, даже в одну строчку (кстати по моему если вставить n то будут проблемы с выводом: () но вот я понимаю что тут происходит спустя 10−15 секунд и мне еще надо проверить себя нет ли там ошибок случайных, и если такого кода много то страница становится нечитабельной, а код неподдерживаемымКстати подобные манипуляции вне вью тоже нетривиальны, строчек 5 набежит, а все оттого что не хотят расширять синтаксис явы и вводить новые элементы.Без этого манипуляции с коллекциями о которых мы говорим здесь всегда будут порождать много не совсем понятного кода, а такие манипуляции сплошь и рядом встречаются в разработке клиентских приложений. — Посчитать сумму заказа — Вывести путь в иерархии — Преобразовать массив данных одной структуры в другую (например массив имен из массива компаний) и т. д. Лично я много писал такого кода во всех проектах на Java, C#, ничего сложного, просто много его и я всегда не понимал почему все должно быть так непросто и неестественно.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Упс, почти спам вышел, исправьте пжлст на http://pastebin.com/

Відповісти

Підтримати

anonymous 20.09.2010 22:48

вот только не знаю, как запостить пример сюда

http://pastebin.com/

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2mickolka, поживем — увидим.:)

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

Антон, я ж не говорил что COBOL-программисты на кладбище, ребята очень много зарабатывают и будут еще лет 10, а потом заслуженная пенсия. Просто проводя аналогии с COBOL, писать новые веб проекты на яве (о чем в принципе этот пост и есть) мне кажется менее эффективно чем изучить более продуктивные платформы, причем даже в среднесрочной перспективе.Но все же давайте вернемся к конструктиву и предложим код на Java решающий во view layer задачку предложеную в #61, а именно аналог $ {«, ».join [x.name for x in companies if x.name is not None]} Все мы знаем, что такого рода мелочей очень много в веб разработке, независимо от фреймворка и инструмент должен решать такие задачи эффективно.Ну или посмотрите пример #2 здесь http://blog.smartweb.com.ua/20... это другой пример того насколько синтаксис языка может усложнять жизнь веб разработчику.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Не хочу нудить, но «индустриальную» это англицизм, по-русски «промышленную».

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2mickolka, не сочту. потому что у меня стойкое ощущение, что посты #43 и #63 написаны двумя разными людьми. программирование безусловно развивается. и постепенно, вместе с растущим числом технологий и языков, обретает определенную индустриальную зрелость. уже на сегодняшнем рынке есть место и PHP, и Java, и С++, и Pyton и... COBOL. Вы спрашивали, где теперь COBOL-программисты? могу ответить — они в Штатах в большинстве своем, и там человек со знанием COBOL имеет очень большую рыночную стоимость, в том числе и в силу своей редкости.

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

Антон, мне кажется была довольно конструктивная и аргументированная дискуссия по поводу того, что хорошо и плохо в яве как платформе для веб разработки. И если кому-то интересно я бы ее продолжил, потому что знание — сила. Программирование развивается, даже мейнстримная (промышленная) его часть.Машинный код -> Процедурное программирование -> ООП ->? Что будет дальше загадка, но это явно будет что-то с возможностями функционального программирования, и возможно это дальше постепенно наступает.Не сочтите за проповедь.

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2mickolka, я уже говорил Вам, но повторю снова. Вы нашли себя в Pyton? это замечательно, Вам нравиться работать на Pyton, без тестирования и тестеров — это замечательно. я с огромным интересом слежу за деятельностью Вашей компании, очень признателен за посты в блог и возьму из Вашего опыта и опыта Вашей команды самое лучшее для себя. у меня есть друг, который нашел себя в Ruby, масса знакомых програмистов PHP. дизайнеры, верстальщики, тестеры, системщики — несть им числа. когда работа приносит человеку удовольствие, удовлетворение личных амбиций, реализацию творческой составляющей его личности — это мегаздорово и однознозначно есть добро. я нашел себя в Java. очень давно, в 1998 году, когда написал первые несколько примитивных апплетов на лабораторной. и до сих о выборе своем не жалею. и пока будут люди, которые заказывают проекты на Java под Web, я буду писать на Java под Web. хотя идеальный для меня проект не имеет User Interface. и не стоит пытаться меня агитировать, обращать в другую веру, открывать мне глаза — мне нравится писать на Java в том числе и под Web. и мне очень не нравятся пассажи, характерные для Свидетелей Иеговы, я не собираюсь призывать Вас отказаться от лже-религии Pyton и вернуться в лоно истинной церкви Java. того же жду и от Вас. спасибо.

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

2 mguя немного знаком с возможностями jstl:), но я имел в виду немного другое, просто неправильно выразился, сорри.Имелось в виду соединить через запятую стринговые проперти объектовкод на том же питоне в mako следующий$ {«, ».join [x.name for x in companies]} или тоже самое, но для случая когда имя определено$ {«, ».join [x.name for x in companies if x.name is not None]} В яве просто нет механизмов сделать это в 1−2 строки читабельно, из-за этого возникают проблемы, потому что когда сделать что-то сложно, разработчики ищут предлоги чтобы этого не делать, возникают кривые интерфейсы.2Антон, я достаточно хорошо отношусь к Java, просто не нужно ее использовать для веб разработки, и писал я на ней долгое время с удовольствием, и не ради денег, а просто по незнанию: (.

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Щетинин Сергей, ну чтож, должен сказать, что Вы меня убедили. во всяком случае до тех пор, пока я не получу реальный пример того, что универсальная архитектура возможна (в том случае, если она вообще возможна), буду считать Вашу позицию наиболее правильной. спасибо за дискуссию:) 2Сергей Григорьев, 2mgu, джентельмены, не мечите бисер. молодой человек мне знаком по блогу его компании. он просто люто ненавидит Java. вероятно такое случается, когда очень долго себя приходится заставлять писать на языке, который тебе не нравиться только потому, что тут «заработать можно больше». как по мне, так язык не виноват, но каждый выбирает для себя.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

в предыдущем комменте побился код для jstl: core примера. должен быть

${string}${status.last?'':','}

Відповісти

Підтримати

anonymous 20.09.2010 22:48

to mickolka #57попался, архытэктор:)

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

Потому что не умеете пользоваться стандартными библиотеками (тот же jstl functions):

${ fn:join(strings, ",") }

если хочется оставаться в рамках core jstl:

${string}${status.last?'':','}

что не очень элегантно, но к вопросу о расширяемости — элементарно мапится все что нужно своей tld и получается код во вьюхе:

${ myTagLibPrefix:myKuelFunction( param1 , param2 ) }

50 таблиц, 200 — 300 вьюшек

Меряться колличеством таблиц и вьюшек — дело неблагодарное. У нас сейчас на проекте 1500 jsp, не считая tag files. И что это говорит? Ничего. Это как в LoC гоняться, или velocity в стори пойнтс наперегонки:)

у нас до сих пор нет «сложной» логики, что мы делаем не так?

Если у вас нет сложной логики, то ее нет, и не было бы в любой другой нормальной среде. Потому что логика — это не инфраструктура (которая может варьировать), но в любом случае все завивит от компетенотности людей, а не платформы.В Яве действительно много граблей, некоторые из них достаточно долгоживущи, но этого добра везде есть, и чинится постепенно. А крики об ущербности — это все больше от скудоумия. Профи работают. На джаве, C#, питоне или руби или еще чем, и делятся открытиями и достижениями.

Потому что так не принято господами консультантами?

Это нас никак с SAPовцами попутали;)

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

Сергей, а что делать с JSP, Velocity и иже с ними? Это же нереальный костыль прикрытый separations of concerns, авторам JSP Tags надо руки оторвать за такую расширяемость, почему я не могу в яве писать примитивную логику нормальным образом во вью, например соединить список строк через запятую? Потому что так не принято господами консультантами? Или потому что на XML особо не попрограммируешь? > Если за слоем представления есть сложная логика, то строго типизированный язык себя оправдываетМиф рожденный для того чтобы сделать возможной бангалорить разработку ПО. Именно строго типизированные языки делают логику сложной, нашему проекту пол-года, 50 таблиц, 200 — 300 вьюшек (типов веб страниц), интеграция с внешним полнотекстовым поиском, и у нас до сих пор нет «сложной» логики, что мы делаем не так? Более того, у нас даже нет юнит тестов, как и вообще тестеров на проекте, и так можно жить, ошибок после 3-х месяцев эксплуатации меньше чем в прошлом проекте где и первое и второе было в изобилии.А по поводу миксов, да есть возможность, но кто это использует? И насколько оправдано заставлять людей знать 2 языка, да и чего ради если в 99% случаев можно обходиться одним, более эффективным.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Я разделяю мнение что писать и править MVC контроллеры и шаблоны на скриптовых языках быстрее и удобнее, пока система не превышает какой-то уровень сложности. Если за слоем представления есть сложная логика, то строго типизированный язык себя оправдывает. Уже сейчас Spring дает возможность писать MVC контроллеры на скриптовых языках, например на Groovy, Jython, JRuby. Можно сочетать скриптовые языки на уровне view и мощь java на уровне business logic.

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

>> 48Я почему-то думаю что приблизительно так думали COBOL-разработчики 10−15 лет назад, и где они теперь? У явы есть своя ниша, довольно большая, но это не веб иначе получатся проекты типа https://www.tender.me.gov.ua/E.../ где все странички генерятся постом, ибо фреймворк.Почему-то мне кажется что такого фреймворка в php/ruby/java не найдете, потому что их писали не академики, любители uml и конференций, а люди которые делают веб проекты каждый день.Может Викет и хорош, я не знаю, но сомневаюсь ибо ява плоха как язык для веба где удобство манипуляции данными важнее строгой типизации.Не буду хвастаться, ибо реально немного сожалею за потраченное время, но мой опыт явы — 6 лет, из которых 3 года архитектором, 2 года в крупном проекте, сейчас пишу на python + pylons выходит проще, качественнее и быстрее, быстрее раза в 3−4. Но денег за яву можно получать больше:)

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Errata: имеет значение [не] только

Відповісти

Підтримати

anonymous 20.09.2010 22:48

мы говорим об автоматически генерируемом коде?

Нет, о написанном вручную.

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

Именно это я назвал трансляцией программы из UML.Дело в том, что UML задает некий набор примитивов и способы их компоновки, а у отдельного языка этот набор и всё остальное может отличаться. Положим C++ и Java достаточно похожи чтобы между ними не нужно было делать различия, но с другими языками всё может уже быть сильно иначе. Опять же — почти на чем угодно можно писать как будто это Java, но идиоматические решения в других языках обычно совсем другие. Это можно проигнорировать при разработке архитектуры, но это будет ошибкой. Повторюсь, но похоже вы считаете что идиомы UML это какой-то общий базис. Это базис близкий к базису C++, Java и может еще нескольких языков, но не более того. Про Erlang я упомянул. А вот еще в чистых функциональных языках не может быть побочных эффектов, вы думаете это никак не влияет на архитектуру? С ними диаграммы состояний скажем вообще не самый удачный инструмент. И это имеет значение только для крайних случаев, с банальным Python такая же история.

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Щетинин Сергей, мы говорим об автоматически генерируемом коде? я использую UML для иллюстрации архитектурных решений, код генерировать мне не кажется правильным. мне почему-то кажется, что построенная правильно диаграмма последовательностей может быть реализована на любом языке программирования. разумеется не одинаково, но весьма близко к абстракции, которую изображает диаграмма. я конечно могу ошибаться, но мне пока кажется именно так. если нет, то не могли бы Вы объяснить почему? опять-таки, вопрос лишь в том, на каком уровне абстракции мы находитмся. я согласен, что если мы имеем полный пакет архитектурной документации, диаграммы нижнего уровня абстракции действительно гораздо лучше строить с учетом языка реализации, но уровнем абстракции выше — и уже нет никакой разницы. я опять ошибаюсь?

Відповісти

Підтримати

anonymous 20.09.2010 22:48

>> 44 Сергей Григорьев

:)

Я думаю там просто запятая пропущена: «Викет это, JSF, Стратс или СпрингМВЦ — чем дольше вы ими пользуетесь...»

Відповісти

Підтримати

anonymous 20.09.2010 22:48

2Anton Naumov, дело не в именно Эрланге, я же сказал что привожу пример для крайней очевидности. Архитектура системы зависит от языка реализации. Если вы думаете что диаграммы состояний это какой-то универсальный инструмент, выражающий саму ткань реальности, то это заблуждение. Код построенный по UML всегда будет трансляцией программы на UML в код этого языка. В таком смысле конечно можно сказать что нет разницы во что мы его транслируем. Но UML это просто визуальный язык программирования; неравномощный совокупности остальных языков и даже любому из них в отдельности. Точно также «алгоритмика и архитектура», она в отрыве от реальности является чем-то другим чем на практике. Знаете такое, «в теории нет разницы между теорией и практикой, на практике она есть».©

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2mickolka, юноша, Вы похоже те времена не застали, но как-то довелось моему другу разбирать web-проект, который был написан на... Oracle RDBMS.Output., а Вы говорите Ruby:)

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2mgu, да, молодые люди пытаются открыть нам глаза. столько конфигов, столько фрэймворков и может с-пол-пинка не заработать. нет, это ужасно — 8 лет меня уже имеют консультанты, а я и не подозревал. думал, что сею разумное, доброе, вечное... какое разочарование меня постигло, пойду убью себя об ПХП...

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Андрей, с ноября прошлого года по 26 апреля сего года не было ни единого разрыва. иначе говоря за уже 3 года использования JSF ни разу «кучу xml, бесконечно генерящих Exception» получить не удалось. что я делаю не так? может быть дело в руках? у меня вообще ни разу не получилось генерить Exception из XML, научитЕ? 2Щетинин Сергей, простите, я не специалист по Erlang, но диаграммы последовательностей и состояний сильно изменятся? с принципиальной точки зрения? т.е. возможно, я не знаю. в таком случае Вы правы и мое высказывание стоит откорректировать: не важно будет это Java, PHP, C++, Delphi, Object Pascal и т.п.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

to Сергей Григорьев #45 Так викет же в web.xml прописывается? Значит — энтерпрайз. А эти сердитые молодые люди не разрешают нашей прелести жить нигде кроме мерзких мобильных:)

Відповісти

Підтримати

anonymous 20.09.2010 22:48

энтерпрайз ява это миф

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

Відповісти

Підтримати

anonymous 20.09.2010 22:48

. Викет это JSF

:)

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

Господа адвокаты явы, признайте вы наконец что энтерпрайз ява это миф, не спорьте по поводу того чье кунг фу круче, по сути все рано или поздно упрется в язык, а он не совсем предназначен для веба. Викет это JSF, Стратс или СпрингМВЦ, чем дольше вы ими пользуетесь — тем больше будет ваше разочарование когда вы попробуете python, rubby или даже php.Вас всех имеют (за неплохое вознаграждение) консультанты, придумавшие этот миф и построившие целую индустрию, как и меня впрочем имели. Да на яве можно делать проекты, но всегда ли нужно?

Відповісти

Підтримати

anonymous 20.09.2010 22:48

На данный момент я уже около года использую JSF, в свое время год проработал на ASP.NET, так вот это небо и земля.JSF 1.1 лично мне не нравится, при добавлении всяких RichFaces это все превращается в неуправляемую кучу xml, бесконечно генерящих Exception.Spring MVC и Struts на меня произвели более лучшее впечатление.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

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

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Щетинин Сергей, возможно я не совсем ясно выразился — на уровне блок-схемы алгоритма или UML диаграмм совершенно все-равно, какой именно язык реализации выбран. единственное влияние языка реализации на UML-модель — это диаграмма классов, там важно будет язык объектно-ориентированным, процедурным, функциональным, etc. в остальном отличие Java от PHP не принципиально. разве не так? вот собственно об этом я и говорил. иными словами уровень паттернов и блок-схем языконезависим.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

различия между языками теряются совершенно.

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

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2mgu, слив засчитан? дело в том, что я прекрасно знаю как именно пишутся кастом-компоненты для JSF. там много классов, это правда., но логики там совсем чуть. если речь идет о JSF + Facelets компоненте, то и классов там всего два. если о стандартном то еще класс тэга. по большому счету от EJB 2.х не сильно отличается. другое дело, что основная причина использования JSF и основное преимущество как-раз и состоит в том, что компоненты писать не нужно. есть достаточно богатые функционалом Component Suites. это совершенно не означает, что JSF есть серебрянной пулей — вовсе нет., но я категорически не согласен с постулатом: на изучение фреймворка нужно потратить больше 4 часов, поэтому фреймворк в топку. по итогу имеет #33 и #36, люди не хотят думать. более того, считают тех, кто все-таки хочет, маргиналами и чудаками. сразу оговорюсь для апологетов Pyton & PHP, дело не в языке разработки и не в Java-снобизме, дело именно в умении и желании думать, учиться, изучать новое, не отступать перед трудностями, а трудности бывают в любом языке, программирование это прежде всего алгоритмика и архитектура, а уже потом реализация. и тут различия между языками теряются совершенно.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

to mickolka#36, #33вот спасибо! А мы-то и не знали! И на PHP никогда проектов не имели;)

Відповісти

Підтримати

Микола Палієнко CEO в VCHASNO GROUP 20.09.2010 22:48

Ребята не страдайте фигней под названием веб проекты на яве, не повоторяйте ошибок. Жизнь коротка, чтобы портить ее. Python Ruby и PHP — единственные нормальные средства для веба.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

to Anton Naumovнаша песня хороша, начинай сначала:) Оставайтесь при своем мнении. Отвечу кратко: надо.

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2mgu, спасибо, теория мне известна и я могу сам сформулировать необходимые и достаточные условия для создания компонента. теперь внимание вопрос за-чем? какой еще компонент может быть необходим, кроме тех, что есть в стандарном набоpе и, к примеру, ICEfaces? p.s. я — это я. OpenID почему-то не работает.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

мда, бугуга. Вижу только склоки ява-чуваков =) а как де товарищи из Python/Ruby, PHP в конце концов? что-то не особо) Видно боятся лезть к энтрепрайз гуру.p.s. А вообще, Ява для разработки конкретно веб сайтов и их GUI — редкая херня, тот же PHP в разы продуктивней с точки зрения времени получения конечного результата.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

to Anton Naumov стандартные компоненты могут не подходят, когда отображаемый объект достаточно сложен и отображение его сложно (речь не идет о разметке, это мелочи) и использовать нужно этот объект во множестве мест, т.е. он сам явно компонент. Наверное, можно сколотить его из множества (достаточно большого) более простых, но будет ли это в результате проще в поддержке и создании, чем написание своего?

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Еще как сделаете сайт на Wicket, добавьте его в список: http://cwiki.apache.org/WICKET..., пока не очень впечатляет.

Да, список не большой. Но сайты — симпотные.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Ну почти: Error: there is no attribute "wicket: id“

Попробуйте указать неймспейс для wicket< html xmlns= “www.w3.org/1999/xhtml” xmlns: wicket= “wicket.sourceforge.net/” можете использовать XHTML

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 20.09.2010 22:48

Еще как сделаете сайт на Wicket, добавьте его в список: http://cwiki.apache.org/WICKET/sites-using-wicket.html, пока не очень впечатляет.

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 20.09.2010 22:48

Шаблоны представляют собой валидный HTML

Ну почти: Error: there is no attribute «wicket: id»

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Хм, разделение HTML и Java кода — что-то необычное?

В случае Wicket на уровне GUI вообще нет никакого языка шаблонов. Шаблоны представляют собой валидный HTML.Поэтому есть полное разделение логики отображения от шаблона. В случае JSP шаблон (я имею ввиду JSP страницу) может содержать логику отображения в виде скриплетов или JSTL тегов типа или. Поэтому если сравнивать Wicket c JSP, то в Wicket логика отображения и шаблон более четко разделены чем в JSP.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Я не изучал вопрос других шаблонов кроме HTML. В доке написано что поддерживается Velocity, живой пример можно посмотреть здесь.

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 20.09.2010 22:48

Еще одна вещь которая мне нравится в Wicket, это разделение java кода и HTML кода

Хм, разделение HTML и Java кода — что-то необычное? А насколько приятно работать с HTML в Wicket относительно других систем шаблонов? Еще я когда-то участвовал в проекте, где JSP файлы генерировались с UML, а дизайнер в основном работал с CSS:)

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Сергей Григорьев, да однозначно не зря. если я выступаю в защиту JSF, то во-первых, не против Wicket, во-вторых, работа проделана. и статья очень интересная. спасибо второй раз.

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Сергей Григорьев, готовые куски дизайна?, но позвольте, кто мешает собрать их из элементарных частей? компонент — это дерево, это таблица, это лайот... опять-таки если не устраивает рендеринг компонентов, можно разбить каждый на еще более элементарные части...

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Если кто-нибудь разделяет мой восторг насчет Wicket, напишите, пожалуйста, комментарий. Буду знать что не зря писал статью:)

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Den, не хотите грубить — не грубите. хотите окончить дискуссию — воля Ваша. я только не совсем понял мысль. поясните пожалуйста, если не затруднит, два момента: 1) о чем Вам говорит сложность фреймворка? 2) в чем именно проявляется моя не зрелость? а регалиями и опытом мерятся я не хочу, у меня профайл опубликован — заходите, читайте. и это тоже ни о чем не говорит, можно иметь 10+ лет опыта и городить чушь. потому с нетерпением жду ответа.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Custom компоненты нужны если заказчик предъявляет требования к дизайну, другими словами веб дизайнер сидит в оффисе заказчика в Дании и рисует HTML. Шаг влево шаг вправо от прототипа GUI — три года строгого расстрела:)

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Догоните Python, например.

Нас не догонят!!!

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 20.09.2010 22:48

2Den: я думаю больше всего подошли бы среднего размера статьи-обзоры, например, описывающие какой-то отдельный интересный подход или инструмент (на использовании которых автор съел не одну собаку), без углубления в дебри (но со ссылками на них). Статьи, интересные для широкого круга разработчиков, способные вызвать здоровую и содержательную дискуссию.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

2Сергей Волошин: Какие именно статьи интересуют?

Відповісти

Підтримати

anonymous 20.09.2010 22:48

2Anton Naumov: вообще эти рассуждения — признак незрелости.

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 20.09.2010 22:48

Я вижу здесь имеется целая Java тусовка, предлагаю участникам потратить 50% сил на споры и холиворы, а остальные 50% — на написание познавательных и полезных статей на developers.org.ua.Пора заполнить хоть часть белых пятен. Догоните Python, например.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

2Anton Naumov: ваши рассуждения конечно офигительно-логичные.Не хочу нагрубить и на этом остановимся, но в J2EE я уже 5 лет и работаю как J2EE Team Lead, и знаю очень... очень... много, в т.ч. того, что касается view layer — это хоть о чем-то, но говорит.

Відповісти

Підтримати

Bogdan Frankovskyi Sr. Software Engineer 20.09.2010 22:48

Этакий django на джаве

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Сергей Григорьев, ну причем здесь WML? Вы не видите другой возможности для RenderKit? как насчет XML или SVG?, но оставим RenderKit, он ни при чем. ответьте мне на вопрос зачем Вам кастом-компоненты? чего не делают уже существующие?

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Я думаю что не стоит усложнять без необходимости. Чем сложнее фреймворк, тем больше времени тратим на его изучение и на разработку. Мне очень нравится книга Better, Faster, Lighter java, там есть глава о простоте.Создатели JSF решили отделить компонентную модель от рендереров, поэтому при создании нового компонента нужно написать клас компонент и класс для рендерера. Если мое приложение всегда рисует HTML и других вариантов (WML) не планируем, то зачем эти навороты?

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

2Den, Java вообще сложный язык, а С/С++ еще сложнее. может быть Вам в ПХП? так там тоже не просто. программирование вообще довольно сложнО по сути своей. лень не может быть оправданием НЕ использования чего бы то нибыло.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

To Anton Naumov: сложность фреймворка о многом говорит. jsf, увы, сложен

Відповісти

Підтримати

anonymous 20.09.2010 22:48

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

Відповісти

Підтримати

anonymous 20.09.2010 22:48

На сайте Wicket есть примеры которые работают online http://www.wicketstuff.org/wicket13. Там же и код можно посмотреть.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Хотелось бы, чтобы писали на родном, а то перевод слишком ухо режет:)

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Да хоть с китайского, про «разделение java кода и HTML кода» заявляет каждый второй фреймворк, тот же самый Tapestry.В общем тема совсем не раскрыта, хоть бы сниппет с кнопочкой добавили в статью.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Я сначала написал на английском для своего блога, потом перевел.

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 20.09.2010 22:48

2Андрей Церкус: так и есть.

Відповісти

Підтримати

anonymous 20.09.2010 22:48

Такое впечатление, что это переведенная статья. Или изначально писалась на английском.

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 20.09.2010 22:48

сложность фреймворка еще ни о чем не говорит. HtmlButton в JSF очень похожа на JButton, а HtmlPanelGrid — на JPanel, если нужно обработать HTTP запрос формы, просто добавляете event listener к кнопке. написание custom components к JSF имеет смысл только в том случае, если Вы разрабатываете свою библиотеку. как правило component suite лидеров рынка (ICEfaces, RichFaces, etc) содержат 90% компонентов, необходимых в реальной жизни. если взять в руки Facelets, то уже не нужно никаких JSP и точно так же как в Wicket можно разделить работу по созданию интерфейса.а в целом не плохая статья. пишите еще:)

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись