Вышел Spring Framework 3.1 GA

[@kai]

Подскажите, в Spring MVC есть механизм генерации урлов? Что нибудь похожее на @@{Controller.action(var1, var2)} в Play Framework?

[@1nd1go]

Нет, такого там нет.
Есть стандартный c:url, или spring:url, но они к контроллеру не привязываются. Хотя IDE, типа Idea резолвит и можно перейти к коду контрлллера.

[@kirill89]

Не знаком с Play Framework, но в Spring есть аннотации для работы с URL.

@RequestMapping(value = "/edit", method = RequestMethod.GET)
public String edit(Model model, @RequestParam(value = "text", required = true) String text) {
  ...
}

[@kai]

Аннотации это хорошо, но как генерировать url-ы во view для контроллеров и их методов?

[@AlexanderYastrebov]

В jsp можно так:

<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 не щупал, если напишите что там хитрое выдумали, попробую сказать как это сделать в спринге.

[@kai]

Смотрите, есть у меня контроллер «Document» и у него есть метод «show», который я через аннотации привязываю к урлу /document/show/{id}/

Как мне во вьюшках генерировать этот урл по имени контроллера и метода? В Play это делается следующим тагом в View шаблоне:

@{ Document.show(12) } и на выходе я получу /document/show/12

И если я в аннотации поменяю урл, то он изменится во всех View. Можно ли делать подобное в Spring?

[@alexeygrigorev]

Насколько мне известно — нет, такой функции в Spring MVC пока нет и приходится изобретать свои костыли. С другой стороны, в Grails, который сделан на основе Spring MVC, такое есть. Возможно, это можно портировать.

[@AlexanderYastrebov]

Да, такой функциональности в спринге нет. Если очень хочется можно написать свою библиотеку тегов, взяв за основу что-то такое github.com/bazhenov/spring-url-builder

Лично я не вижу необходимости в такой фиче, поясню почему. Как часто вы меняете URL? Допустим часто. Но что происходит чаще — изменение path в URL или добавление каки-либо дополнительных query параметров? У меня такое ощущение, что параметры изменяются чаще чем путь. А в таком случае вам придетсе все-равно найти все точки формирования URL и прописать в них новый/измененный параметр. Таким образом возможности предлагаемого вами способа не превосходят (не сильно превосходят) возможностей встренного тега <spring:url> и не дадут ощутимого выйгрыша.

[@zim32]

Просто хардкодить что-либо это вообще не очень хорошая практика. В том числе и URL.

[@AlexanderYastrebov]

Может тогда вынесем url и из RequestMapping — @RequestMapping(value=UrlConstants.EDIT_DOCUMENT)?

[@zim32]

Но во View-то оно останется при таком подходе. О чем собственно kai и писал

[@zim32]

Можно конечно и во View вывести константу, но все же тогда запись вида @{ Document.show(12) } выглядит лаконичнее

[@AlexanderYastrebov]

Я хочу сказать что у вас при добавлении параметра все равно надо везде его дописать

[@kai]

У меня (в Play) в режиме разработки выведется няшное сообщение об ошибке во View, т.к. не будет найден метод с соответствующей сигнатурой. Что удобно и к этому привыкаешь.

[@AlexanderYastrebov]

Но увидите вы это сообщение только когда дернете УРЛ. Чтобы добавить параметр, все равно придется найти все места во вьюхах, где УРЛ формируется

[@kai]

Да, я понимаю. Но так проще искать проблемные места после изменений в коде. Ну и генерация урлов помогает, когда меняешь их в коде. Не нужно по шаблонам бегать.

[@kai]

1. На этапе разработки я частенько меняю URLы
2. При изменении сигнатуры метода в Play я получаю явную ошибку во View, т.к. при обработке шаблона не будет найден метод с необходимой сигнатурой.

Это удобно. Поэтому хочется понять, есть ли такая штука в Spring.

[@AlexanderYastrebov]

Я выше уже ответил, такого нет.

[@akakunin]

А мне как раз нравится Spring MVC — за то что он не прячет детали коммуникации (собственно сам протокол http, используемые урлы и передачу параметров) — а просто упрощает их обработку.
Объясню на примере — долго использовал JSF (с RichFaces) — там вообще все в шоколаде — пишешь #{controlled.callSomeMethod()} — и не паришься — как там это все передается, какие урлы регерятся, как параметры передаются, как они попадают в контроллер — вообщем все происходит автоматом.
Только когда у тебя страница вдруг начинает весить под 2 метра — потому что во всех урлах передается state, либо когда начинаются танцы с бубном, потому что надо SEO Friendly URL-ы, либо когда вдруг сильно упираешься в перфоманс…
SpringMVC — по сути дела практически голый JSP API — просто с набором вещей которые упрощают его использование — в итоге ты всегда контролируешь что и как работает.

[@jbaruch]

У SpringMVC (как и у Struts2, например) есть своя ниша — это сайты, для которых нужен этот контроль над request-response (например — полностью динамические страницы, без определенной стуктуры, аналог canvas-а).
Ваш негативный опыт с server-side components frameworks понятен, JSF отбивает желание работать с такими framework-ами раз и на всю жизнь. Но все таки, есть и хорошие server-side components frameworks, которые очень сильно облегчают жизнь, а не осложняют ее как JSF. Могу привести в пример Wicket и Vaadin.

[@norguhtar]

Не совсем понятно что вы имеете в виду.

[@jbaruch]

Как по мне, так одна из главных вкусностей это доведение до ума Java Config.

[@malexejev]

Полностью согласен.
Теперь дело за библиотеками-сателлитами (@Enable аннотации). Для MVC, транзакций, асинка, аспектов они уже есть.
Для Spring Security — еще нет. Это пока основной тормоз на пути прогресса, на мой взгляд.

[@jbaruch]

Так напишите, делов то! Они с радостью принимают патчи.

[@malexejev]

Ну, в принципе, я и так автор таска на эту тему в их жире и автор поста в форуме Spring Security, где идет обсуждение этого вопроса.
Я начинал эту инициативу с полгода назад, когда правильным способом считались еще @FeatureSpecification. Сейчас способ импементации устаканился и можно садиться и делать, но… во-первых мне лень, во-вторых это большая тяжелая фича, охватывающая почти весь функционал подсистемы. Пускай сами делают.

[@malexejev]

jira.springsource.org/browse/SPR-8517
Самая главная фича Servlets 3.0 в этот релиз не вошла, к сожалению.