Вычитал, что Struts это уже плохо, а JSF и другие (Tapestry, Wicked) web framework-и основанные на компонентной архитектуре лучше. Собственно, хотелось бы прочитать где-нибудь ликбез, в котором описывается, что такое компоненты и чем они лучше того-же Struts c его MVC + паттерн команда? Насколько я понимаю, архитектура JSF это – MVC, причем View основан на компонентах, так что-же это за звери такие — компоненты?
Здравствуйте, Аноним, Вы писали:
А>Вычитал, что Struts это уже плохо, а JSF и другие (Tapestry, Wicked) web framework-и основанные на компонентной архитектуре лучше. Собственно, хотелось бы прочитать где-нибудь ликбез, в котором описывается, что такое компоненты и чем они лучше того-же Struts c его MVC + паттерн команда? Насколько я понимаю, архитектура JSF это – MVC, причем View основан на компонентах, так что-же это за звери такие — компоненты?
В стратсе приходится постоянно копипастить, да и в JSF этого копипаста будет немало.
В Struts тоже компоненты можно выделять — в слое View (JSP) с помощью тегов JSP. кода javascript, CSS. И в коде контроллера тоже можно выделять (с помощью функций и классов).
Другой вопрос в том, что стандарт JSP не подразумевает какой нибудь связи между компонентами контроллера и представления. В принципе можно самому реализовать эту связь, но JSF предлагает реализованный функционал, это удобнее конечно, но мне не особо нравится, потому что код представления (HTML) генериться тупо с помощью конкатенации строк и подставления на нужное место параметров — если бы на этом месте был XSLT, цены бы ему не было. Да и разработка своих компонент мягко говоря нетривиальна. Но зато мы получаем некоторое более менее законченное решение, пусть и ограниченное в функционале.
JSF и другие (Tapestry, Wicked) более приближен к ООП, чем struts, а ООП вообще проще понимается, чем request/response, но от request/response все равно никуда не уйти
ДВ>В стратсе приходится постоянно копипастить, да и в JSF этого копипаста будет немало. ДВ>В Struts тоже компоненты можно выделять — в слое View (JSP) с помощью тегов JSP. кода javascript, CSS. И в коде контроллера тоже можно выделять (с помощью функций и классов).
Если я правильно понимаю, один из минусов стратса, это наличие экшена, причем одного на всю страницу, по большому счету, все экшены представляют из себя нечто ужасное, даже при граммотном рефакторинге. В JSF же, каждый компонент живет своей жизнью и если проводить аналогию со стратсом, то каждый компонент может иметь неограниченное число отдельных, никак несвязанных экшенов — некий бин, из которого беруться данные, валидатор, конвертер, обработчики различных событий, обработчик навигации и .т.д.
Так-же в JSF более продвинутый жизненный цикл обработи запросов, который в версии 1.2 совместили с жизненым циклом JSP.
ДВ>Другой вопрос в том, что стандарт JSP не подразумевает какой нибудь связи между компонентами контроллера и представления. В принципе можно самому реализовать эту связь, но JSF предлагает реализованный функционал, это удобнее конечно, но мне не особо нравится, потому что код представления (HTML) генериться тупо с помощью конкатенации строк и подставления на нужное место параметров
в стратсе все точно также
ДВ>- если бы на этом месте был XSLT, цены бы ему не было.
вопервых, в большинстве фреймворков идет преобразование java -> html, вы предлагаете java->xml->html, тут вопрос, а оно надо?
вовторых, если оно (java->xml->html либо другая экзотика) все-таки надо, то JSF предоставляет стандартное решение — Render Kit. К примеру, в ADF Faces стандартно идут 3-и рендер кита, html, wap, tenlnet. Суть в том, что не JSP страница не обработка событий никак не меняются, в Стратсе как мне кажется с этим совсем худо, если нужен другой view, то менять нужно практически все.
Ну и не забываем про Facelets, которые просто чудно дополняют JSF.
Да и разработка своих компонент мягко говоря нетривиальна.
Здравствуйте, Аноним, Вы писали:
А>Если я правильно понимаю, один из минусов стратса, это наличие экшена, причем одного на всю страницу, по большому счету, все экшены представляют из себя нечто ужасное, даже при граммотном рефакторинге.
По-моему это основная ошибка тех кот пишет на Struts. Разве там нельзя несколько Action на одну страницу назначить?
ДВ>>- если бы на этом месте был XSLT, цены бы ему не было. А>вопервых, в большинстве фреймворков идет преобразование java -> html, вы предлагаете java->xml->html, тут вопрос, а оно надо? А>вовторых, если оно (java->xml->html либо другая экзотика) все-таки надо, то JSF предоставляет стандартное решение — Render Kit. К примеру, в ADF Faces стандартно идут 3-и рендер кита, html, wap, tenlnet. Суть в том, что не JSP страница не обработка событий никак не меняются, в Стратсе как мне кажется с этим совсем худо, если нужен другой view, то менять нужно практически все. А>Ну и не забываем про Facelets, которые просто чудно дополняют JSF.
+1 При упоминании XSLT для веб разработки мне плохо становится. Никак не могу понять чем он так хорош.
А> Да и разработка своих компонент мягко говоря нетривиальна. А>согласен, благо их сейчас много развелось.
Это основной плюс. Можно найти всяких rich виджетов и быстро накидать их на страницы для простого решения. Зато шаг влево шаг вправо оборачивается триками и воркэраундами.
Здравствуйте, Аноним, Вы писали:
А>вопервых, в большинстве фреймворков идет преобразование java -> html, вы предлагаете java->xml->html, тут вопрос, а оно надо? А>вовторых, если оно (java->xml->html либо другая экзотика) все-таки надо, то JSF предоставляет стандартное решение — Render Kit. К примеру, в ADF Faces стандартно идут 3-и рендер кита, html, wap, tenlnet. Суть в том, что не JSP страница не обработка событий никак не меняются, в Стратсе как мне кажется с этим совсем худо, если нужен другой view, то менять нужно практически все. А>Ну и не забываем про Facelets, которые просто чудно дополняют JSF.
А>согласен, благо их сейчас много развелось.
У меня к сожалению нет большого коммерческого опыта разработки на JSF, но первые впечатления после работы с ними где-то между — "во круто то как" и "ну что за гИмор"
Ну оно и понятно — пока сидишь в рамках стандартных компонент и архитектуры, будет все просто круто, а захочется чуть дальше — и все, получили приключений на свою пятую точку.
Кстати некоторые компоненты, которые заявлены мало того что рабочими так еще кроссброузерными, оказывается вообще частично работающими. Приходится опять все писать на html и javascript, это вообще отдельная песня — заставлять работать вместе javascript компоненты и JSF компоненты (оно несложно, но очень некрасиво)
А>вы предлагаете java->xml->html, тут вопрос, а оно надо?
если оно не надо, то значит не надо. XSLT сам по себе не тривиален в изучении, зато предлагает очень мощный механизм генерации html. Конечно в процессе рендеринга надо java в xml перегонять, но этого можно избежать если постоянно выделять КОМПОНЕНТЫ (в том числе и в xslt), о которых вы говорите. один раз выделил компонент, вынес изменяющуюся часть в java класс, а дальше просто его используешь, и не занимаешься копипастом. Появляется новый use-case — подправил его, либо наследника создал.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Аноним, Вы писали:
А>>Если я правильно понимаю, один из минусов стратса, это наличие экшена, причем одного на всю страницу, по большому счету, все экшены представляют из себя нечто ужасное, даже при граммотном рефакторинге. B>По-моему это основная ошибка тех кот пишет на Struts. Разве там нельзя несколько Action на одну страницу назначить?
ДВ>>>- если бы на этом месте был XSLT, цены бы ему не было. А>>вопервых, в большинстве фреймворков идет преобразование java -> html, вы предлагаете java->xml->html, тут вопрос, а оно надо? А>>вовторых, если оно (java->xml->html либо другая экзотика) все-таки надо, то JSF предоставляет стандартное решение — Render Kit. К примеру, в ADF Faces стандартно идут 3-и рендер кита, html, wap, tenlnet. Суть в том, что не JSP страница не обработка событий никак не меняются, в Стратсе как мне кажется с этим совсем худо, если нужен другой view, то менять нужно практически все. А>>Ну и не забываем про Facelets, которые просто чудно дополняют JSF. B>+1 При упоминании XSLT для веб разработки мне плохо становится. Никак не могу понять чем он так хорош.
Я сам его боюсь, когда вижу здоровенные xslt файлы в которых без дебаггера и бутылки водки не разберешься . Но я тут такую шнягу придумал — для рендеринга компонент использовать XSLT — прежний механизм, но вынести его в JSP тег — то есть просто в JSP странице пишем <xmlcomp name="name1" /> — и в этом месте JSP страницы генерится нужный компонент. То есть что можно выносим в xslt, а что не имеет смысла пишем стандартно с помощью JSP/tiles
Здравствуйте, Аноним, Вы писали:
А>вопервых, в большинстве фреймворков идет преобразование java -> html, вы предлагаете java->xml->html, тут вопрос, а оно надо? А>вовторых, если оно (java->xml->html либо другая экзотика) все-таки надо, то JSF предоставляет стандартное решение — Render Kit. К примеру, в ADF Faces стандартно идут 3-и рендер кита, html, wap, tenlnet. Суть в том, что не JSP страница не обработка событий никак не меняются, в Стратсе как мне кажется с этим совсем худо, если нужен другой view, то менять нужно практически все. А>Ну и не забываем про Facelets, которые просто чудно дополняют JSF.
Кстати об ADF — они впервые появились на swing, целью этих компонент также было упрощение работы с БД. Но все равно разработчики стремились писать своюи классы/компоненты, которые нужны именно для их нужд.
А>Если я правильно понимаю, один из минусов стратса, это наличие экшена, причем одного на всю страницу, по большому счету, все экшены представляют из себя нечто ужасное, даже при граммотном рефакторинге.
если я правильно понимаю, экшен это контроллер (который C из MVC), не думаю, что он может быть минусом.
что там ужасного тоже не знаю, хотя в том единственном проекте (стратс используется в CMS Atleap) они были действительно ужасны , но это имхо просто от того, что разработчик их ужасно написал.
в вебе пользователь имхо воздействует на систему с помощью урлов (включая параметры) — вбивает их в строку браузера, кликает линки, кнопки, которые генерируют урлы;
контроллер собственно обрабатывает реакцию на воздействие: дергает модель и выбирает вью как ответ(все так, как и должно быть в MVC), что вполне должно укладываться в десяток строк
часто (в том числе в атлипе) в контроллерах присутствует куча бизнес логики, кода, который должен быть где-то в модели, и рефакторингом тут все замечательно можно решить
заодно, поделюсь своим видением (сразу скажу, что возможно я просто хреново знаю JSF),
по JSF я прочитал одну книжку в рамках программы обучения в компании, и должен был по итогам обучения написать небольшое тестовое приложение — типа работа со справочником одной сущности — list view create update
в рамках работы над тестовым заданием, понял что я конкретно не догоняю чего-то,
без того MVC которое предлагает стратс и спринг (о том что JSF это тоже MVC я вот только тут узнал) я не понимаю воркфлоу работы приложения, если добавить стратс или спринг и использовать JSF исключительно как вью-технологию, то нафик мне тогде вообще JSF, простейшими JSP-шками значительно быстрее и проще
во-первых, я считаю что воздействие пользователя на систему — это реквест по урлу, а не клик мышки или клавы, соответственно после запроса на урл воркфлоу приложения должен попадать в контроллер (джава-класс), где передаем реакцию модели, достаем вью. В JSF я не нашел как это делать, нашел что при заходе на урл мы попадаем сразу в jsp — там у нас накиданы компоненты, далее кликаем по компоненту и уже срабатывают обработчики, выбираются дальнейшие пути.
В результате моего непонимания часть логики я пытался переносить в конструкторы бинов, находящихся в реквест-скопе и типа будут подниматься при заходе на урл, мне становилось все хуже и хуже. Наверное именно в этом и отличие: с системой взаимодействие идет через урлы, а не через общение с компонентами (в вебе урлы есть, а компонентов нет)
во-вторых, (я уже озвучивал эту мысль, правда COs сказал что это только со мной так ),
я считаю что нельзя привносить парадигму GUI (накидал компонентов на формочку, прописал обработчики на эвенты и тд) в веб, где парадигма основана (как где-то в этой ветке было правильно указано) на реквест-респонс (там, правда, то, что я называю парадигмой GUI названо ООП зачем-то). мне кажется в этом случае многое напоминает костыль или выходит из под контроля разработчика.
в-третьих, за то, что делает JSF с хтмл уже можно имхо от него отказываться. Задача стоит — сгенерировать респонс — текст-html, текст-javascript, текст-css, т.е некоторый набор текста. Что такое в этом случае компонент? Мне непонятно. Понятно мне, что можно инклюдить тэгами части jsp-шек, называя их не компонентами, а набором текста, такая "компонентность" мне по душе.
з.ы. моему текущему понимаю хорошей вью-технологии на сегодня больше всего соответствует велосити — выходит чистый понятный хтмл, с необходимой функциональностью лишенной логики вью-технологии.
Здравствуйте, dolor, Вы писали:
А>>Если я правильно понимаю, один из минусов стратса, это наличие экшена, причем одного на всю страницу, по большому счету, все экшены представляют из себя нечто ужасное, даже при граммотном рефакторинге.
D>если я правильно понимаю, экшен это контроллер (который C из MVC), не думаю, что он может быть минусом.
Меня тут недавно убедили во обратном, дав ссылку на Struts MVC. Некогда искать тот топик.
Action не считается контроллером. Он не выполняет многих его функций. Не так давно я уже писал здесь
что Struts Action вообще не самая лучшая сущность для web. Хотя Struts 2 вроде с POJO лучше работает.
D>во-вторых, (я уже озвучивал эту мысль, правда COs сказал что это только со мной так ),
C0s D>я считаю что нельзя привносить парадигму GUI (накидал компонентов на формочку, прописал обработчики на эвенты и тд) в веб, где парадигма основана (как где-то в этой ветке было правильно указано) на реквест-респонс (там, правда, то, что я называю парадигмой GUI названо ООП зачем-то). мне кажется в этом случае многое напоминает костыль или выходит из под контроля разработчика.
Эвенты, может быть зачастую и да. Но почему ты отрицаешь реюзабельные компоненты. На макорсах Velocity ты их не напишешь.
Здравствуйте, Blazkowicz, Вы писали:
B>Меня тут недавно убедили во обратном, дав ссылку на Struts MVC. Некогда искать тот топик.
жалко. я не смог найти
ну видимо я как-то не так понимаю контроллер,
правда говорил я не конкретно о стратс, а о контроллерах как общем моменте реализаций mvc спринга и стратс
D>>во-вторых, (я уже озвучивал эту мысль, правда COs сказал что это только со мной так ), B>C0s
сорри
B>Но почему ты отрицаешь реюзабельные компоненты.
я не столько о компонентах, сколько о навязываемом воркфлоу приложения,
что такая компонентность JSF дает такого, чего не дает jsp include?
B>На макорсах Velocity ты их не напишешь.
на велосити можно инклюдить друг в друга шаблоны?
B>>Но почему ты отрицаешь реюзабельные компоненты. D>я не столько о компонентах, сколько о навязываемом воркфлоу приложения, D>что такая компонентность JSF дает такого, чего не дает jsp include?
Возможноть оформлять их в виде отдельной библиотеки (jar), например.
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
Re[4]: Что такое компоненты в JSF?
От:
Аноним
Дата:
18.05.07 05:57
Оценка:
Здравствуйте, dolor, Вы писали:
А>>Если я правильно понимаю, один из минусов стратса, это наличие экшена, причем одного на всю страницу, по большому счету, все экшены представляют из себя нечто ужасное, даже при граммотном рефакторинге.
D>если я правильно понимаю, экшен это контроллер (который C из MVC), не думаю, что он может быть минусом.
Вы неправильно понимаете. Архитектура Struts это — MVC + паттерн команда, собственно action это и есть команда. А контролер это сервлет, который принимает абсолютно все запросы. В задачу контролера входит: получить запрос, на его основании определить, какой ActionForm создавать, создать его и забить данными, затем определить, какой нужно вызвать action и собственно вызвать его. Это минимальные действия производимые контролером. А action(команда) уже отвечает за обработку конкретной формы.
А>Вы неправильно понимаете. Архитектура Struts это — MVC + паттерн команда, собственно action это и есть команда. А контролер это сервлет, который принимает абсолютно все запросы. В задачу контролера входит: получить запрос, на его основании определить, какой ActionForm создавать, создать его и забить данными, затем определить, какой нужно вызвать action и собственно вызвать его. Это минимальные действия производимые контролером. А action(команда) уже отвечает за обработку конкретной формы.
фасадный сервлет, который в соответствии с маппингом (урл — класс, создание формы все-таки вторично и вспомогательно, ее может совсем не быть) вызывает нужный экшен, очень скрыт от глаз разработчика, его можно совсем не рассматривать, является лишь частью C из MVC,
а другой частью являются именно экшены, которые, как следует из описания MVC, обрабатывают воздействия пользователей на модель и выбирают вью
(экшен все таки за обработку урла отвечает, а не формы)
итого, стратсовский экшен — это C из MVC, реализованный паттерном команда (к слову, реализованная плохо ), совсем не исключающие друг друга вещи
Re[6]: Что такое компоненты в JSF?
От:
Аноним
Дата:
29.05.07 13:16
Оценка:
Здравствуйте, dolor, Вы писали:
А>>Вы неправильно понимаете. Архитектура Struts это — MVC + паттерн команда, собственно action это и есть команда. А контролер это сервлет, который принимает абсолютно все запросы. В задачу контролера входит: получить запрос, на его основании определить, какой ActionForm создавать, создать его и забить данными, затем определить, какой нужно вызвать action и собственно вызвать его. Это минимальные действия производимые контролером. А action(команда) уже отвечает за обработку конкретной формы.
D>фасадный сервлет, который в соответствии с маппингом (урл — класс, создание формы все-таки вторично и вспомогательно, ее может совсем не быть) вызывает нужный экшен, очень скрыт от глаз разработчика, его можно совсем не рассматривать, является лишь частью C из MVC,
D>а другой частью являются именно экшены, которые, как следует из описания MVC, обрабатывают воздействия пользователей на модель и выбирают вью
D>(экшен все таки за обработку урла отвечает, а не формы)
D>итого, стратсовский экшен — это C из MVC, реализованный паттерном команда (к слову, реализованная плохо ), совсем не исключающие друг друга вещи
там написано, что action это все таки больше Модель, т.к. имеет непосредсвенное отношение к бизнес логике. Action в той статье зовется Model Wrapper.
И насколько я понял, патерн команда не имеет никаког отношения к экшену, команда это ActionServlet, вот чего пишут — With Struts, the Controller is a command design pattern implemented as a servlet. Т.е. между ActionServlet и Action отношение use, а не агрегация. Поэтому нельзя сказать, что action это часть контролера.
Здравствуйте, Blazkowicz, Вы писали:
D>>если я правильно понимаю, экшен это контроллер (который C из MVC), не думаю, что он может быть минусом. B>Меня тут недавно убедили во обратном, дав ссылку на Struts MVC. Некогда искать тот топик. B>Action не считается контроллером. Он не выполняет многих его функций. Не так давно я уже писал здесь
что Struts Action вообще не самая лучшая сущность для web. Хотя Struts 2 вроде с POJO лучше работает.
В struts 2 (от первого стратса осталось только название) в доке написано, что роль контроллера выполняет сервлет:
The implementation used a pattern from Smalltalk known as the
model-view-controller pattern – or more recently known as the
front controller, or in Sun parlance Model 2.
In this pattern the servlet is the controller, providing a
centralized point of control for all client page requests. It maps
the request URL to a unit of work know as an action. The
action’s job was to perform specific functionality for a given
URL by accessing the HTTP session, HTTP request and form
parameter, calling business services, and then mapping the
response into a model, whose form is a plain old java object.
Finally, the action returned a result, which was mapped (via
configuration files) to a JSP to render as the view.
Action это обычный POJO (на форму кстати сколько угодно Actions вешается вообще без проблем) и он без проблем может обращаться к контексту сервлета через статические методы класса ActionContext. Соответственно контроллер без проблем можно реализовать полноценный, если есть желание и необходимость.
А вообще, Struts 2 мне очень понравился, внимания этот фреймворк точно достоин, гораздо лучше и проще Spring MVC ИМХО, не говоря уже о первом Struts. Правда при использовании AJAX наверно найдутся лучшие альтернативы, Struts 2 вроде бы проектировался без его поддержки, и это заметно.
Здравствуйте, dolor, Вы писали:
D>во-вторых, (я уже озвучивал эту мысль, правда COs сказал что это только со мной так ), D>я считаю что нельзя привносить парадигму GUI (накидал компонентов на формочку, прописал обработчики на эвенты и тд) в веб, где парадигма основана (как где-то в этой ветке было правильно указано) на реквест-респонс (там, правда, то, что я называю парадигмой GUI названо ООП зачем-то). мне кажется в этом случае многое напоминает костыль или выходит из под контроля разработчика.
А зачем всегда контролировать низкоуровневое взаимодействие событий пользователя и ответом сервера? Если абстрагироваться от деталей, то любое приложение представляет собой некоторую систему, которая как либо реагирует на действия пользователя. Если приближаться к деталям, то конечно вылезают различные подробности типа request/response, можно вообще опуститься на уровень HTML, или вообще TCP и сокетов. Но конечно намного удобнее использовать некоторый API, который рассчитан на некоторый use-case, и пока мы сидим в этом use-case мы можем концентрироваться на более абстрагированных деталях, тратя время на определение того, что надо делать, а не как это надо делать. И этот API должен предоставлять некоторый механизм, который в случае чего позволил бы все таки работать с более низким уровнем, например для написания своих компонент на use-case, изначально не заложенный в архитектуре.
Возможно для сайтов событийно ориентированнся архитектура будет слишком крута и не нужна (там ведь обычно только отображение некоторой информации, считай почти одни некоторые отчеты о состоянии системы), но для какого нибудь back-office будут повышенные требования к реакции системы на действия пользователя. RIA и фсе такое. А если использовать Ajax, то мало того что написание приложения нетривиально, так еще поддержка вообще мало радости принесет.
Возможно тебе как разработчику пока пофиг, что конкретно ты успеешь выполнить за определенный промежуток времени, но по-моему в интересах любого менеджера внедрять технологии, которые повысят скорость/качество разработки и поддержки.
Здравствуйте, elmal, Вы писали:
D>>>если я правильно понимаю, экшен это контроллер (который C из MVC), не думаю, что он может быть минусом. B>>Меня тут недавно убедили во обратном, дав ссылку на Struts MVC. Некогда искать тот топик. B>>Action не считается контроллером. Он не выполняет многих его функций. Не так давно я уже писал здесь
что Struts Action вообще не самая лучшая сущность для web. Хотя Struts 2 вроде с POJO лучше работает. E>В struts 2 (от первого стратса осталось только название) в доке написано, что роль контроллера выполняет сервлет:
И что?
E>Action это обычный POJO
Когда Action наследует какой-то класс, он уже перестает быть POJO
Можно пример кода? Я сколько вижу везде Action — наследник чего-либо.
E>(на форму кстати сколько угодно Actions вешается вообще без проблем) и он без проблем может обращаться к контексту сервлета через статические методы класса ActionContext. Соответственно контроллер без проблем можно реализовать полноценный, если есть желание и необходимость.
Ничего не понятно. Зачем реализовывать контролер если в Struts 2 он вроде бы и не нужен?
Здравствуйте, Blazkowicz, Вы писали:
B>Можно пример кода? Я сколько вижу везде Action — наследник чего-либо.
Пожалуйста — пример из книги Starting Struts2:
public class MyAction {
private MyService myService;
public void setService( MyService service ) {
myService = service;
}
public String execute() {
…
}
}
Если это не POJO, то я Билл Гейтс . В данном случае execute — это метод, который выполняется по умолчанию. Но его может и не быть, тогда в декларации Action (в XML) придется прописать еще и метод, который вызывать. Также Action должен возвратить строку результата, который должен быть String (или специальный объект, не помню щас названия). Все требования к Action, больше ничего нет.
B>Ничего не понятно. Зачем реализовывать контролер если в Struts 2 он вроде бы и не нужен?
Контроллер есть, но он выполняет специфические задачи. Вызывает Interceptors, мапит URL на свойства объекта Action. Поддерживает http сессию. Но этот конроллер как-бы скрыт, а Action сам по себе состояние хранить не может, потому не может считаться контроллером в классическом понимании. А в struts 2 мы работаем явно с Model, View и Action. Action можно рассматривать как урезанный контроллер, и если потребуются полноценный, то придется в Action добавлять вызовы ActionContext для доступа к сервлету.
Re: Что такое компоненты в JSF?
От:
Аноним
Дата:
30.05.07 11:39
Оценка:
Задался таким вопросом, чем являются ManagetBeans в JSF с точки зрения MVC?
Здравствуйте, elmal, Вы писали:
B>>Можно пример кода? Я сколько вижу везде Action — наследник чего-либо. E>Пожалуйста — пример из книги Starting Struts2:
Спасибо, выходин на сайте у них ещё древние примеры.
B>>Ничего не понятно. Зачем реализовывать контролер если в Struts 2 он вроде бы и не нужен? E>Контроллер есть, но он выполняет специфические задачи. Вызывает Interceptors, мапит URL на свойства объекта Action. Поддерживает http сессию. Но этот конроллер как-бы скрыт,
Вроде обычные задачи контроллера.
E>а Action сам по себе состояние хранить не может, потому не может считаться контроллером в классическом понимании.
Контроллер "в классическом понимании" должен хранить состояние?
E>А в struts 2 мы работаем явно с Model, View и Action. Action можно рассматривать как урезанный контроллер, и если потребуются полноценный, то придется в Action добавлять вызовы ActionContext для доступа к сервлету.
Вообще-то Action реализует бизнес-логику и посему относится к модели.
(оно несложно, но очень некрасиво)
