Комментарии 26
Подскажите, в Spring MVC есть механизм генерации урлов? Что нибудь похожее на @@{Controller.action(var1, var2)} в Play Framework?
Не знаком с Play Framework, но в Spring есть аннотации для работы с URL.
@RequestMapping(value = "/edit", method = RequestMethod.GET)
public String edit(Model model, @RequestParam(value = "text", required = true) String text) {
...
}Аннотации это хорошо, но как генерировать url-ы во view для контроллеров и их методов?
В jsp можно так:
static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/tags/UrlTag.html
Скажите конкретней что вы имеете ввиду под «как генерировать url-ы во view для контроллеров и их методов», я вам отвечу. Play не щупал, если напишите что там хитрое выдумали, попробую сказать как это сделать в спринге.
<spring:url value="/url/path/{variableName}">
<spring:param name="variableName" value="more than JSTL c:url" />
</spring:url>
static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/tags/UrlTag.html
Скажите конкретней что вы имеете ввиду под «как генерировать url-ы во view для контроллеров и их методов», я вам отвечу. Play не щупал, если напишите что там хитрое выдумали, попробую сказать как это сделать в спринге.
Смотрите, есть у меня контроллер «Document» и у него есть метод «show», который я через аннотации привязываю к урлу /document/show/{id}/
Как мне во вьюшках генерировать этот урл по имени контроллера и метода? В Play это делается следующим тагом в View шаблоне:
@{ Document.show(12) } и на выходе я получу /document/show/12
И если я в аннотации поменяю урл, то он изменится во всех View. Можно ли делать подобное в Spring?
Как мне во вьюшках генерировать этот урл по имени контроллера и метода? В Play это делается следующим тагом в View шаблоне:
@{ Document.show(12) } и на выходе я получу /document/show/12
И если я в аннотации поменяю урл, то он изменится во всех View. Можно ли делать подобное в Spring?
Насколько мне известно — нет, такой функции в Spring MVC пока нет и приходится изобретать свои костыли. С другой стороны, в Grails, который сделан на основе Spring MVC, такое есть. Возможно, это можно портировать.
Да, такой функциональности в спринге нет. Если очень хочется можно написать свою библиотеку тегов, взяв за основу что-то такое github.com/bazhenov/spring-url-builder
Лично я не вижу необходимости в такой фиче, поясню почему. Как часто вы меняете URL? Допустим часто. Но что происходит чаще — изменение path в URL или добавление каки-либо дополнительных query параметров? У меня такое ощущение, что параметры изменяются чаще чем путь. А в таком случае вам придетсе все-равно найти все точки формирования URL и прописать в них новый/измененный параметр. Таким образом возможности предлагаемого вами способа не превосходят (не сильно превосходят) возможностей встренного тега <spring:url> и не дадут ощутимого выйгрыша.
Лично я не вижу необходимости в такой фиче, поясню почему. Как часто вы меняете URL? Допустим часто. Но что происходит чаще — изменение path в URL или добавление каки-либо дополнительных query параметров? У меня такое ощущение, что параметры изменяются чаще чем путь. А в таком случае вам придетсе все-равно найти все точки формирования URL и прописать в них новый/измененный параметр. Таким образом возможности предлагаемого вами способа не превосходят (не сильно превосходят) возможностей встренного тега <spring:url> и не дадут ощутимого выйгрыша.
Просто хардкодить что-либо это вообще не очень хорошая практика. В том числе и URL.
Может тогда вынесем url и из RequestMapping — @RequestMapping(value=UrlConstants.EDIT_DOCUMENT)?
Я хочу сказать что у вас при добавлении параметра все равно надо везде его дописать
У меня (в Play) в режиме разработки выведется няшное сообщение об ошибке во View, т.к. не будет найден метод с соответствующей сигнатурой. Что удобно и к этому привыкаешь.
1. На этапе разработки я частенько меняю URLы
2. При изменении сигнатуры метода в Play я получаю явную ошибку во View, т.к. при обработке шаблона не будет найден метод с необходимой сигнатурой.
Это удобно. Поэтому хочется понять, есть ли такая штука в Spring.
2. При изменении сигнатуры метода в Play я получаю явную ошибку во View, т.к. при обработке шаблона не будет найден метод с необходимой сигнатурой.
Это удобно. Поэтому хочется понять, есть ли такая штука в Spring.
А мне как раз нравится Spring MVC — за то что он не прячет детали коммуникации (собственно сам протокол http, используемые урлы и передачу параметров) — а просто упрощает их обработку.
Объясню на примере — долго использовал JSF (с RichFaces) — там вообще все в шоколаде — пишешь #{controlled.callSomeMethod()} — и не паришься — как там это все передается, какие урлы регерятся, как параметры передаются, как они попадают в контроллер — вообщем все происходит автоматом.
Только когда у тебя страница вдруг начинает весить под 2 метра — потому что во всех урлах передается state, либо когда начинаются танцы с бубном, потому что надо SEO Friendly URL-ы, либо когда вдруг сильно упираешься в перфоманс…
SpringMVC — по сути дела практически голый JSP API — просто с набором вещей которые упрощают его использование — в итоге ты всегда контролируешь что и как работает.
Объясню на примере — долго использовал JSF (с RichFaces) — там вообще все в шоколаде — пишешь #{controlled.callSomeMethod()} — и не паришься — как там это все передается, какие урлы регерятся, как параметры передаются, как они попадают в контроллер — вообщем все происходит автоматом.
Только когда у тебя страница вдруг начинает весить под 2 метра — потому что во всех урлах передается state, либо когда начинаются танцы с бубном, потому что надо SEO Friendly URL-ы, либо когда вдруг сильно упираешься в перфоманс…
SpringMVC — по сути дела практически голый JSP API — просто с набором вещей которые упрощают его использование — в итоге ты всегда контролируешь что и как работает.
У SpringMVC (как и у Struts2, например) есть своя ниша — это сайты, для которых нужен этот контроль над request-response (например — полностью динамические страницы, без определенной стуктуры, аналог canvas-а).
Ваш негативный опыт с server-side components frameworks понятен, JSF отбивает желание работать с такими framework-ами раз и на всю жизнь. Но все таки, есть и хорошие server-side components frameworks, которые очень сильно облегчают жизнь, а не осложняют ее как JSF. Могу привести в пример Wicket и Vaadin.
Ваш негативный опыт с server-side components frameworks понятен, JSF отбивает желание работать с такими framework-ами раз и на всю жизнь. Но все таки, есть и хорошие server-side components frameworks, которые очень сильно облегчают жизнь, а не осложняют ее как JSF. Могу привести в пример Wicket и Vaadin.
Не совсем понятно что вы имеете в виду.
Как по мне, так одна из главных вкусностей это доведение до ума Java Config.
Полностью согласен.
Теперь дело за библиотеками-сателлитами (@Enable аннотации). Для MVC, транзакций, асинка, аспектов они уже есть.
Для Spring Security — еще нет. Это пока основной тормоз на пути прогресса, на мой взгляд.
Теперь дело за библиотеками-сателлитами (@Enable аннотации). Для MVC, транзакций, асинка, аспектов они уже есть.
Для Spring Security — еще нет. Это пока основной тормоз на пути прогресса, на мой взгляд.
Так напишите, делов то! Они с радостью принимают патчи.
Ну, в принципе, я и так автор таска на эту тему в их жире и автор поста в форуме Spring Security, где идет обсуждение этого вопроса.
Я начинал эту инициативу с полгода назад, когда правильным способом считались еще @FeatureSpecification. Сейчас способ импементации устаканился и можно садиться и делать, но… во-первых мне лень, во-вторых это большая тяжелая фича, охватывающая почти весь функционал подсистемы. Пускай сами делают.
Я начинал эту инициативу с полгода назад, когда правильным способом считались еще @FeatureSpecification. Сейчас способ импементации устаканился и можно садиться и делать, но… во-первых мне лень, во-вторых это большая тяжелая фича, охватывающая почти весь функционал подсистемы. Пускай сами делают.
jira.springsource.org/browse/SPR-8517
Самая главная фича Servlets 3.0 в этот релиз не вошла, к сожалению.
Самая главная фича Servlets 3.0 в этот релиз не вошла, к сожалению.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел Spring Framework 3.1 GA