> Добрый день!
> Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами),
> сделанным на Grails?
> Я начал один доморощенный проект, и сталкиваюсь с проблемами, которые
> наверняка уже кто-то решал. Нужен хороший совет "с поля боя".

> Привет.
> Есть такие.
> Задавай свои вопросы без стеснения :) Будем рады помочь.

> On 7 янв, 22:14, Sergey Bondarenko <ente...@gmail.com> wrote:

> > Добрый день!
> > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами),
> > сделанным на Grails?
> > Я начал один доморощенный проект, и сталкиваюсь с проблемами, которые
> > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".

> Ты используешь скаффолднутые вьюшки?

> Ну в общем случае используя тэг <g:link controller="pilot" action="show"
> id="${pilot.id}">Back to pilot</g:link>
> pilot.id - написал условно. как ты его будешь доставать зависит от того
> какая модель доступна на вьюшке classConfirmation. возможно в твоем случае
> это будет classConfirmation.pilot.id

> 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

> > Здорово!

> > В-общем, первая проблема:
> > У меня есть объект домена Pilot, у которого есть много
> > ClassConfirmation. Связь один-ко-многим.
> > Не устраивает поведение pilot show view.
> > При нажатии на ссылку classConfirmation (одиниз экземпляров
> > подчинённого класса)  я перехожу на classConfirmation show view,
> > откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"

> > Как лучше всего организовать такую функциональность?

> > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote:
> > > Привет.
> > > Есть такие.
> > > Задавай свои вопросы без стеснения :) Будем рады помочь.

> > > On 7 янв, 22:14, Sergey Bondarenko <ente...@gmail.com> wrote:

> > > > Добрый день!
> > > > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами),
> > > > сделанным на Grails?
> > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами, которые
> > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".

> ну тогда нужно "пробрасывать" в confirmation show view информацию откуда ты
> пришел. первое что приходит в голову это формировать уришку вида
> /pilot/show/123 или /confirmation/list в соответсвующих вьюшках и
> пробрасывать get параметром (backUri, например). формировать можно так:
> g.createLink controller: controller, action: action, id: id

> если в голову придет что-то более изящное - сообщу :)

> 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

> > Да, использую скаффолднутые.

> > Мне бы хотелось, чтобы back работал по-разному для двух случаев:
> > 1. confirmation show view был вызван из pilot show view, тогда back
> > должен возвращать на pilot show view
> > 2. confirmation show view был вызван из confirmation list view, тогда
> > back должен возвращать на confirmation list view

> > Да, "Back to pilot" - здесь ты прав. Мне бы хотелось также, чтобы back
> > был информативным - было понятно, куда мы вернёмся.
> > Тоесть "Back to pilot"/"Back to confirmation list".

> > On 7 янв, 23:11, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com> wrote:
> > > Ты используешь скаффолднутые вьюшки?

> > > Ну в общем случае используя тэг <g:link controller="pilot" action="show"
> > > id="${pilot.id}">Back to pilot</g:link>
> > > pilot.id - написал условно. как ты его будешь доставать зависит от того
> > > какая модель доступна на вьюшке classConfirmation. возможно в твоем
> > случае
> > > это будет classConfirmation.pilot.id

> > > 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

> > > > Здорово!

> > > > В-общем, первая проблема:
> > > > У меня есть объект домена Pilot, у которого есть много
> > > > ClassConfirmation. Связь один-ко-многим.
> > > > Не устраивает поведение pilot show view.
> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров
> > > > подчинённого класса)  я перехожу на classConfirmation show view,
> > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"

> > > > Как лучше всего организовать такую функциональность?

> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote:
> > > > > Привет.
> > > > > Есть такие.
> > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.

> > > > > On 7 янв, 22:14, Sergey Bondarenko <ente...@gmail.com> wrote:

> > > > > > Добрый день!
> > > > > > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами),
> > > > > > сделанным на Grails?
> > > > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами,
> > которые
> > > > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".

> Ага, ну вот, супер!  Это тот способ, к которому я в конце-концов
> склоняюсь.

> Ещё я пробовал таким образом - сделать это через Grails Webflow.

> Теоретически эта штука как раз для этого предназначена.
> На практике получается ряд "вредных" ограничений, как например - что
> делать, если управление передаётся в другой контроллер.
> Или как обрабатывать save подчинённого объекта, не передавая
> управление (flow) в его контроллер.
> Плюс то, что модель нельзя определить внутри action какого-либо
> состояния, а можно только лишь параметры в обработке on("событие")
> {[параметры]}.

> Ты работал с Webflow? Может я чего-то не понимаю?

> On 7 янв, 23:40, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com> wrote:
>> ну тогда нужно "пробрасывать" в confirmation show view информацию откуда ты
>> пришел. первое что приходит в голову это формировать уришку вида
>> /pilot/show/123 или /confirmation/list в соответсвующих вьюшках и
>> пробрасывать get параметром (backUri, например). формировать можно так:
>> g.createLink controller: controller, action: action, id: id

>> если в голову придет что-то более изящное - сообщу :)

>> 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

>> > Да, использую скаффолднутые.

>> > Мне бы хотелось, чтобы back работал по-разному для двух случаев:
>> > 1. confirmation show view был вызван из pilot show view, тогда back
>> > должен возвращать на pilot show view
>> > 2. confirmation show view был вызван из confirmation list view, тогда
>> > back должен возвращать на confirmation list view

>> > Да, "Back to pilot" - здесь ты прав. Мне бы хотелось также, чтобы back
>> > был информативным - было понятно, куда мы вернёмся.
>> > Тоесть "Back to pilot"/"Back to confirmation list".

>> > On 7 янв, 23:11, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com> wrote:
>> > > Ты используешь скаффолднутые вьюшки?

>> > > Ну в общем случае используя тэг <g:link controller="pilot" action="show"
>> > > id="${pilot.id}">Back to pilot</g:link>
>> > > pilot.id - написал условно. как ты его будешь доставать зависит от того
>> > > какая модель доступна на вьюшке classConfirmation. возможно в твоем
>> > случае
>> > > это будет classConfirmation.pilot.id

>> > > 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

>> > > > Здорово!

>> > > > В-общем, первая проблема:
>> > > > У меня есть объект домена Pilot, у которого есть много
>> > > > ClassConfirmation. Связь один-ко-многим.
>> > > > Не устраивает поведение pilot show view.
>> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров
>> > > > подчинённого класса)  я перехожу на classConfirmation show view,
>> > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"

>> > > > Как лучше всего организовать такую функциональность?

>> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote:
>> > > > > Привет.
>> > > > > Есть такие.
>> > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.

>> > > > > On 7 янв, 22:14, Sergey Bondarenko <ente...@gmail.com> wrote:

>> > > > > > Добрый день!
>> > > > > > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами),
>> > > > > > сделанным на Grails?
>> > > > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами,
>> > которые
>> > > > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".

> Добрый день!
> За subflow спасибо - я посмотрю. Насчёт модели внутри экшена, покажу на
> примере.
> Я хочу в начальном состоянии manageFlow рендерить список объектов (list
> view).

> Хотелось бы писать так:
>     def manageFlow = {
>         listState {
>             action{
>                 [pilotInstanceList:Pilot.list(params)]
>             }
>             render(view:'/pilot/list')
>         }
>     }

> но так делать нельзя, и поэтому я пишу так:

>     def manageFlow = {
>         start {
>             action{
>                 [pilotInstanceList:Pilot.list(params)]
>             }
>             on('success').to 'listState'
>         }

>         listState {
>             render(view:'/pilot/list')
>         }
>     }

> Непонятно, почему нельзя в action{} определить модель, и её использовать в
> том же state для рендеринга.

> 8 января 2009 г. 9:18 пользователь Bogdan Danilyuk <danilyuk...@gmail.com>
> написал:

>> Здравствуйте.

>> Работаю с Grails Webflow уже достаточно долго. Очень удобная штука для
>> построения визардов.
>> Насчет передачи управления в другой контроллер. В Grails есть понятие
>> subflow, Вы можете использовать в основном флове вложенные фловы. Это
>> позволяет вкладывать визарды один в один. Вопрос передачи контроля в
>> другой контроллер отпадает - используется флов из другого контроллера
>> как вложенный (например для редактирования какого либо объекта).
>> Последнего "но" по поводу определения модели внутри экшена не понял,
>> не могли бы Вы перефразировать?!

>> 8 января 2009 г. 2:12 пользователь Sergey Bondarenko
>> <ente...@gmail.com> написал:
>> > Ага, ну вот, супер!  Это тот способ, к которому я в конце-концов
>> > склоняюсь.

>> > Ещё я пробовал таким образом - сделать это через Grails Webflow.

>> > Теоретически эта штука как раз для этого предназначена.
>> > На практике получается ряд "вредных" ограничений, как например - что
>> > делать, если управление передаётся в другой контроллер.
>> > Или как обрабатывать save подчинённого объекта, не передавая
>> > управление (flow) в его контроллер.
>> > Плюс то, что модель нельзя определить внутри action какого-либо
>> > состояния, а можно только лишь параметры в обработке on("событие")
>> > {[параметры]}.

>> > Ты работал с Webflow? Может я чего-то не понимаю?

>> > On 7 янв, 23:40, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com> wrote:
>> >> ну тогда нужно "пробрасывать" в confirmation show view информацию
>> >> откуда ты
>> >> пришел. первое что приходит в голову это формировать уришку вида
>> >> /pilot/show/123 или /confirmation/list в соответсвующих вьюшках и
>> >> пробрасывать get параметром (backUri, например). формировать можно так:
>> >> g.createLink controller: controller, action: action, id: id

>> >> если в голову придет что-то более изящное - сообщу :)

>> >> 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

>> >> > Да, использую скаффолднутые.

>> >> > Мне бы хотелось, чтобы back работал по-разному для двух случаев:
>> >> > 1. confirmation show view был вызван из pilot show view, тогда back
>> >> > должен возвращать на pilot show view
>> >> > 2. confirmation show view был вызван из confirmation list view, тогда
>> >> > back должен возвращать на confirmation list view

>> >> > Да, "Back to pilot" - здесь ты прав. Мне бы хотелось также, чтобы
>> >> > back
>> >> > был информативным - было понятно, куда мы вернёмся.
>> >> > Тоесть "Back to pilot"/"Back to confirmation list".

>> >> > On 7 янв, 23:11, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com> wrote:
>> >> > > Ты используешь скаффолднутые вьюшки?

>> >> > > Ну в общем случае используя тэг <g:link controller="pilot"
>> >> > > action="show"
>> >> > > id="${pilot.id}">Back to pilot</g:link>
>> >> > > pilot.id - написал условно. как ты его будешь доставать зависит от
>> >> > > того
>> >> > > какая модель доступна на вьюшке classConfirmation. возможно в твоем
>> >> > случае
>> >> > > это будет classConfirmation.pilot.id

>> >> > > 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

>> >> > > > Здорово!

>> >> > > > В-общем, первая проблема:
>> >> > > > У меня есть объект домена Pilot, у которого есть много
>> >> > > > ClassConfirmation. Связь один-ко-многим.
>> >> > > > Не устраивает поведение pilot show view.
>> >> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров
>> >> > > > подчинённого класса)  я перехожу на classConfirmation show view,
>> >> > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку
>> >> > > > "back"

>> >> > > > Как лучше всего организовать такую функциональность?

>> >> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote:
>> >> > > > > Привет.
>> >> > > > > Есть такие.
>> >> > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.

>> >> > > > > On 7 янв, 22:14, Sergey Bondarenko <ente...@gmail.com> wrote:

>> >> > > > > > Добрый день!
>> >> > > > > > Скажите, есть здесь кто-то, кто сейчас занимается
>> >> > > > > > проектом(ами),
>> >> > > > > > сделанным на Grails?
>> >> > > > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами,
>> >> > которые
>> >> > > > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".

> Спасибо за ссылки! Да, неочевидные соглашения в Grails Webflow есть местами.
>  А Вы никогда не сталкивались с тем, что Grails путает flows?
> К примеру, я описываю showFlow в классе StudentController -
> showState{render(view:'/student/show')}, и в классе CourseController - -
> showState{render(view:'/course/show')}
> Так вот когда я из course list view открываю course show view, на самом деле
> отображается student show view.

> Выглядит так, как будто Grails считает, что showState из CourseController -
> это showState из StudentController.
> Самое удивительное, что ссылка в броузере корректная:
> http://localhost:8080/pilots/course/show/1

> 8 января 2009 г. 12:19 пользователь Bogdan Danilyuk <danilyuk...@gmail.com>
> написал:

>> А! Вот вы о чем :-)
>> Изначально тоже это не особо понравилось, но потом привык.
>> Я использую action'ы для начальной инициализации визарда и для
>> определения следующего шага визарда если он, к примеру, зависит от
>> введёных на предыдущем шаге данных.
>> Советую обратить внимание на эти не задокументированные соглашения при
>> использовании сабфловов:
>> http://www.nabble.com/Webflow-subflow---novice-musings-td17425431.html

>> 8 января 2009 г. 12:02 пользователь Sergey Bondarenko
>> <ente...@gmail.com> написал:
>> > Добрый день!
>> > За subflow спасибо - я посмотрю. Насчёт модели внутри экшена, покажу на
>> > примере.
>> > Я хочу в начальном состоянии manageFlow рендерить список объектов (list
>> > view).

>> > Хотелось бы писать так:
>> >     def manageFlow = {
>> >         listState {
>> >             action{
>> >                 [pilotInstanceList:Pilot.list(params)]
>> >             }
>> >             render(view:'/pilot/list')
>> >         }
>> >     }

>> > но так делать нельзя, и поэтому я пишу так:

>> >     def manageFlow = {
>> >         start {
>> >             action{
>> >                 [pilotInstanceList:Pilot.list(params)]
>> >             }
>> >             on('success').to 'listState'
>> >         }

>> >         listState {
>> >             render(view:'/pilot/list')
>> >         }
>> >     }

>> > Непонятно, почему нельзя в action{} определить модель, и её использовать
>> > в
>> > том же state для рендеринга.

>> > 8 января 2009 г. 9:18 пользователь Bogdan Danilyuk
>> > <danilyuk...@gmail.com>
>> > написал:

>> >> Здравствуйте.

>> >> Работаю с Grails Webflow уже достаточно долго. Очень удобная штука для
>> >> построения визардов.
>> >> Насчет передачи управления в другой контроллер. В Grails есть понятие
>> >> subflow, Вы можете использовать в основном флове вложенные фловы. Это
>> >> позволяет вкладывать визарды один в один. Вопрос передачи контроля в
>> >> другой контроллер отпадает - используется флов из другого контроллера
>> >> как вложенный (например для редактирования какого либо объекта).
>> >> Последнего "но" по поводу определения модели внутри экшена не понял,
>> >> не могли бы Вы перефразировать?!

>> >> 8 января 2009 г. 2:12 пользователь Sergey Bondarenko
>> >> <ente...@gmail.com> написал:
>> >> > Ага, ну вот, супер!  Это тот способ, к которому я в конце-концов
>> >> > склоняюсь.

>> >> > Ещё я пробовал таким образом - сделать это через Grails Webflow.

>> >> > Теоретически эта штука как раз для этого предназначена.
>> >> > На практике получается ряд "вредных" ограничений, как например - что
>> >> > делать, если управление передаётся в другой контроллер.
>> >> > Или как обрабатывать save подчинённого объекта, не передавая
>> >> > управление (flow) в его контроллер.
>> >> > Плюс то, что модель нельзя определить внутри action какого-либо
>> >> > состояния, а можно только лишь параметры в обработке on("событие")
>> >> > {[параметры]}.

>> >> > Ты работал с Webflow? Может я чего-то не понимаю?

>> >> > On 7 янв, 23:40, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com> wrote:
>> >> >> ну тогда нужно "пробрасывать" в confirmation show view информацию
>> >> >> откуда ты
>> >> >> пришел. первое что приходит в голову это формировать уришку вида
>> >> >> /pilot/show/123 или /confirmation/list в соответсвующих вьюшках и
>> >> >> пробрасывать get параметром (backUri, например). формировать можно
>> >> >> так:
>> >> >> g.createLink controller: controller, action: action, id: id

>> >> >> если в голову придет что-то более изящное - сообщу :)

>> >> >> 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

>> >> >> > Да, использую скаффолднутые.

>> >> >> > Мне бы хотелось, чтобы back работал по-разному для двух случаев:
>> >> >> > 1. confirmation show view был вызван из pilot show view, тогда
>> >> >> > back
>> >> >> > должен возвращать на pilot show view
>> >> >> > 2. confirmation show view был вызван из confirmation list view,
>> >> >> > тогда
>> >> >> > back должен возвращать на confirmation list view

>> >> >> > Да, "Back to pilot" - здесь ты прав. Мне бы хотелось также, чтобы
>> >> >> > back
>> >> >> > был информативным - было понятно, куда мы вернёмся.
>> >> >> > Тоесть "Back to pilot"/"Back to confirmation list".

>> >> >> > On 7 янв, 23:11, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com>
>> >> >> > wrote:
>> >> >> > > Ты используешь скаффолднутые вьюшки?

>> >> >> > > Ну в общем случае используя тэг <g:link controller="pilot"
>> >> >> > > action="show"
>> >> >> > > id="${pilot.id}">Back to pilot</g:link>
>> >> >> > > pilot.id - написал условно. как ты его будешь доставать зависит
>> >> >> > > от
>> >> >> > > того
>> >> >> > > какая модель доступна на вьюшке classConfirmation. возможно в
>> >> >> > > твоем
>> >> >> > случае
>> >> >> > > это будет classConfirmation.pilot.id

>> >> >> > > 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

>> >> >> > > > Здорово!

>> >> >> > > > В-общем, первая проблема:
>> >> >> > > > У меня есть объект домена Pilot, у которого есть много
>> >> >> > > > ClassConfirmation. Связь один-ко-многим.
>> >> >> > > > Не устраивает поведение pilot show view.
>> >> >> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров
>> >> >> > > > подчинённого класса)  я перехожу на classConfirmation show
>> >> >> > > > view,
>> >> >> > > > откуда нету обратной ссылки на pilots show view. Хочется
>> >> >> > > > кнопку
>> >> >> > > > "back"

>> >> >> > > > Как лучше всего организовать такую функциональность?

>> >> >> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote:
>> >> >> > > > > Привет.
>> >> >> > > > > Есть такие.
>> >> >> > > > > Задавай свои вопросы без

> Ууу, мне не человеко-понятный url нужен, я переопределяю show flow для обоих
> контроллеров. Тоесть, мне нужно изменить работу show view.
> Поэтому не получится называть их разными именами.

> А откуда вообще такое ограничение? Мне кажется, оно нарушает принципы
> изолированности, что ли. И принцип least surprise тоже.
> Очень странно видеть в url явно указанный контроллер, при этом на страничке
> - результаты flow из неизвестно какого другого контроллера.

> 8 января 2009 г. 16:05 пользователь Bogdan Danilyuk <danilyuk...@gmail.com>
> написал:

>> Да, сталкивался...
>> Поэтому каждый флов именуется по-разному, обидная штука! Человеко
>> понятный урл можно сделать потом только урл мапингами.
>> Там есть еще много некрасивостей... Например - теряются интерцепторы
>> если положить объект во флов.
>> Еще, кстати, под версией 1.0.4 не получилось использовать как сабфлов,
>> флов объявленный в другом классе. Воркэраунд пока не нашел. Как найду
>> - поделюсь.

>> 8 января 2009 г. 15:46 пользователь Sergey Bondarenko
>> <ente...@gmail.com> написал:
>> > Спасибо за ссылки! Да, неочевидные соглашения в Grails Webflow есть
>> > местами.
>> >  А Вы никогда не сталкивались с тем, что Grails путает flows?
>> > К примеру, я описываю showFlow в классе StudentController -
>> > showState{render(view:'/student/show')}, и в классе CourseController - -
>> > showState{render(view:'/course/show')}
>> > Так вот когда я из course list view открываю course show view, на самом
>> > деле
>> > отображается student show view.

>> > Выглядит так, как будто Grails считает, что showState из
>> > CourseController -
>> > это showState из StudentController.
>> > Самое удивительное, что ссылка в броузере корректная:
>> > http://localhost:8080/pilots/course/show/1

>> > 8 января 2009 г. 12:19 пользователь Bogdan Danilyuk
>> > <danilyuk...@gmail.com>
>> > написал:

>> >> А! Вот вы о чем :-)
>> >> Изначально тоже это не особо понравилось, но потом привык.
>> >> Я использую action'ы для начальной инициализации визарда и для
>> >> определения следующего шага визарда если он, к примеру, зависит от
>> >> введёных на предыдущем шаге данных.
>> >> Советую обратить внимание на эти не задокументированные соглашения при
>> >> использовании сабфловов:
>> >> http://www.nabble.com/Webflow-subflow---novice-musings-td17425431.html

>> >> 8 января 2009 г. 12:02 пользователь Sergey Bondarenko
>> >> <ente...@gmail.com> написал:
>> >> > Добрый день!
>> >> > За subflow спасибо - я посмотрю. Насчёт модели внутри экшена, покажу
>> >> > на
>> >> > примере.
>> >> > Я хочу в начальном состоянии manageFlow рендерить список объектов
>> >> > (list
>> >> > view).

>> >> > Хотелось бы писать так:
>> >> >     def manageFlow = {
>> >> >         listState {
>> >> >             action{
>> >> >                 [pilotInstanceList:Pilot.list(params)]
>> >> >             }
>> >> >             render(view:'/pilot/list')
>> >> >         }
>> >> >     }

>> >> > но так делать нельзя, и поэтому я пишу так:

>> >> >     def manageFlow = {
>> >> >         start {
>> >> >             action{
>> >> >                 [pilotInstanceList:Pilot.list(params)]
>> >> >             }
>> >> >             on('success').to 'listState'
>> >> >         }

>> >> >         listState {
>> >> >             render(view:'/pilot/list')
>> >> >         }
>> >> >     }

>> >> > Непонятно, почему нельзя в action{} определить модель, и её
>> >> > использовать
>> >> > в
>> >> > том же state для рендеринга.

>> >> > 8 января 2009 г. 9:18 пользователь Bogdan Danilyuk
>> >> > <danilyuk...@gmail.com>
>> >> > написал:

>> >> >> Здравствуйте.

>> >> >> Работаю с Grails Webflow уже достаточно долго. Очень удобная штука
>> >> >> для
>> >> >> построения визардов.
>> >> >> Насчет передачи управления в другой контроллер. В Grails есть
>> >> >> понятие
>> >> >> subflow, Вы можете использовать в основном флове вложенные фловы.
>> >> >> Это
>> >> >> позволяет вкладывать визарды один в один. Вопрос передачи контроля в
>> >> >> другой контроллер отпадает - используется флов из другого
>> >> >> контроллера
>> >> >> как вложенный (например для редактирования какого либо объекта).
>> >> >> Последнего "но" по поводу определения модели внутри экшена не понял,
>> >> >> не могли бы Вы перефразировать?!

>> >> >> 8 января 2009 г. 2:12 пользователь Sergey Bondarenko
>> >> >> <ente...@gmail.com> написал:
>> >> >> > Ага, ну вот, супер!  Это тот способ, к которому я в конце-концов
>> >> >> > склоняюсь.

>> >> >> > Ещё я пробовал таким образом - сделать это через Grails Webflow.

>> >> >> > Теоретически эта штука как раз для этого предназначена.
>> >> >> > На практике получается ряд "вредных" ограничений, как например -
>> >> >> > что
>> >> >> > делать, если управление передаётся в другой контроллер.
>> >> >> > Или как обрабатывать save подчинённого объекта, не передавая
>> >> >> > управление (flow) в его контроллер.
>> >> >> > Плюс то, что модель нельзя определить внутри action какого-либо
>> >> >> > состояния, а можно только лишь параметры в обработке on("событие")
>> >> >> > {[параметры]}.

>> >> >> > Ты работал с Webflow? Может я чего-то не понимаю?

>> >> >> > On 7 янв, 23:40, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com>
>> >> >> > wrote:
>> >> >> >> ну тогда нужно "пробрасывать" в confirmation show view информацию
>> >> >> >> откуда ты
>> >> >> >> пришел. первое что приходит в голову это формировать уришку вида
>> >> >> >> /pilot/show/123 или /confirmation/list в соответсвующих вьюшках и
>> >> >> >> пробрасывать get параметром (backUri, например). формировать
>> >> >> >> можно
>> >> >> >> так:
>> >> >> >> g.createLink controller: controller, action: action, id: id

>> >> >> >> если в голову придет что-то более изящное - сообщу :)

>> >> >> >> 2009/1/7 Sergey Bondarenko <ente...@gmail.com>

>> >> >> >> > Да, использую скаффолднутые.

>> >> >> >> > Мне бы хотелось, чтобы back работал по-разному для двух
>> >> >> >> > случаев:
>> >> >> >> > 1. confirmation show view был вызван из pilot show view, тогда
>> >> >> >> > back
>> >> >> >> > должен возвращать на pilot show view
>> >> >> >> > 2. confirmation show view был вызван из confirmation list view,
>> >> >> >> > тогда
>> >> >> >> > back должен возвращать на confirmation list view

>> >> >> >> > Да, "Back to pilot" - здесь ты прав. Мне бы хотелось также,
>> >> >> >> > чтобы
>> >> >> >> > back
>> >> >> >> > был информативным - было понятно, куда мы вернёмся.
>> >> >> >> > Тоесть "Back to pilot"/"Back to confirmation list".

>> >> >> >> > On 7

> С этим багом я уже столкнулся раньше, хотя и в JIRA не находил ещё. Поэтому
> использую имена типа состояний во flow типа showAction, showState и т.п.
> При этом проблема одинаковых названий flow в разных control-ах остаётся.
> А где пофиксили тот баг? Интересно взглянуть.

> 8 января 2009 г. 16:51 пользователь Bogdan Danilyuk <danilyuk...@gmail.com>
> написал:

>> Прошу прощения, я Вас дезинформировал, то поведение которое я описал
>> уже пофиксили (только что проверил).
>> Вы скорее всего столкнулись с вот этим багом
>> http://jira.codehaus.org/browse/GRAILS-3254

>> 8 января 2009 г. 16:19 пользователь Sergey Bondarenko
>> <ente...@gmail.com> написал:
>> > Ууу, мне не человеко-понятный url нужен, я переопределяю show flow для
>> > обоих
>> > контроллеров. Тоесть, мне нужно изменить работу show view.
>> > Поэтому не получится называть их разными именами.

>> > А откуда вообще такое ограничение? Мне кажется, оно нарушает принципы
>> > изолированности, что ли. И принцип least surprise тоже.
>> > Очень странно видеть в url явно указанный контроллер, при этом на
>> > страничке
>> > - результаты flow из неизвестно какого другого контроллера.

>> > 8 января 2009 г. 16:05 пользователь Bogdan Danilyuk
>> > <danilyuk...@gmail.com>
>> > написал:

>> >> Да, сталкивался...
>> >> Поэтому каждый флов именуется по-разному, обидная штука! Человеко
>> >> понятный урл можно сделать потом только урл мапингами.
>> >> Там есть еще много некрасивостей... Например - теряются интерцепторы
>> >> если положить объект во флов.
>> >> Еще, кстати, под версией 1.0.4 не получилось использовать как сабфлов,
>> >> флов объявленный в другом классе. Воркэраунд пока не нашел. Как найду
>> >> - поделюсь.

>> >> 8 января 2009 г. 15:46 пользователь Sergey Bondarenko
>> >> <ente...@gmail.com> написал:
>> >> > Спасибо за ссылки! Да, неочевидные соглашения в Grails Webflow есть
>> >> > местами.
>> >> >  А Вы никогда не сталкивались с тем, что Grails путает flows?
>> >> > К примеру, я описываю showFlow в классе StudentController -
>> >> > showState{render(view:'/student/show')}, и в классе CourseController
>> >> > - -
>> >> > showState{render(view:'/course/show')}
>> >> > Так вот когда я из course list view открываю course show view, на
>> >> > самом
>> >> > деле
>> >> > отображается student show view.

>> >> > Выглядит так, как будто Grails считает, что showState из
>> >> > CourseController -
>> >> > это showState из StudentController.
>> >> > Самое удивительное, что ссылка в броузере корректная:
>> >> > http://localhost:8080/pilots/course/show/1

>> >> > 8 января 2009 г. 12:19 пользователь Bogdan Danilyuk
>> >> > <danilyuk...@gmail.com>
>> >> > написал:

>> >> >> А! Вот вы о чем :-)
>> >> >> Изначально тоже это не особо понравилось, но потом привык.
>> >> >> Я использую action'ы для начальной инициализации визарда и для
>> >> >> определения следующего шага визарда если он, к примеру, зависит от
>> >> >> введёных на предыдущем шаге данных.
>> >> >> Советую обратить внимание на эти не задокументированные соглашения
>> >> >> при
>> >> >> использовании сабфловов:

>> >> >> http://www.nabble.com/Webflow-subflow---novice-musings-td17425431.html

>> >> >> 8 января 2009 г. 12:02 пользователь Sergey Bondarenko
>> >> >> <ente...@gmail.com> написал:
>> >> >> > Добрый день!
>> >> >> > За subflow спасибо - я посмотрю. Насчёт модели внутри экшена,
>> >> >> > покажу
>> >> >> > на
>> >> >> > примере.
>> >> >> > Я хочу в начальном состоянии manageFlow рендерить список объектов
>> >> >> > (list
>> >> >> > view).

>> >> >> > Хотелось бы писать так:
>> >> >> >     def manageFlow = {
>> >> >> >         listState {
>> >> >> >             action{
>> >> >> >                 [pilotInstanceList:Pilot.list(params)]
>> >> >> >             }
>> >> >> >             render(view:'/pilot/list')
>> >> >> >         }
>> >> >> >     }

>> >> >> > но так делать нельзя, и поэтому я пишу так:

>> >> >> >     def manageFlow = {
>> >> >> >         start {
>> >> >> >             action{
>> >> >> >                 [pilotInstanceList:Pilot.list(params)]
>> >> >> >             }
>> >> >> >             on('success').to 'listState'
>> >> >> >         }

>> >> >> >         listState {
>> >> >> >             render(view:'/pilot/list')
>> >> >> >         }
>> >> >> >     }

>> >> >> > Непонятно, почему нельзя в action{} определить модель, и её
>> >> >> > использовать
>> >> >> > в
>> >> >> > том же state для рендеринга.

>> >> >> > 8 января 2009 г. 9:18 пользователь Bogdan Danilyuk
>> >> >> > <danilyuk...@gmail.com>
>> >> >> > написал:

>> >> >> >> Здравствуйте.

>> >> >> >> Работаю с Grails Webflow уже достаточно долго. Очень удобная
>> >> >> >> штука
>> >> >> >> для
>> >> >> >> построения визардов.
>> >> >> >> Насчет передачи управления в другой контроллер. В Grails есть
>> >> >> >> понятие
>> >> >> >> subflow, Вы можете использовать в основном флове вложенные фловы.
>> >> >> >> Это
>> >> >> >> позволяет вкладывать визарды один в один. Вопрос передачи
>> >> >> >> контроля в
>> >> >> >> другой контроллер отпадает - используется флов из другого
>> >> >> >> контроллера
>> >> >> >> как вложенный (например для редактирования какого либо объекта).
>> >> >> >> Последнего "но" по поводу определения модели внутри экшена не
>> >> >> >> понял,
>> >> >> >> не могли бы Вы перефразировать?!

>> >> >> >> 8 января 2009 г. 2:12 пользователь Sergey Bondarenko
>> >> >> >> <ente...@gmail.com> написал:
>> >> >> >> > Ага, ну вот, супер!  Это тот способ, к которому я в
>> >> >> >> > конце-концов
>> >> >> >> > склоняюсь.

>> >> >> >> > Ещё я пробовал таким образом - сделать это через Grails
>> >> >> >> > Webflow.

>> >> >> >> > Теоретически эта штука как раз для этого предназначена.
>> >> >> >> > На практике получается ряд "вредных" ограничений, как например
>> >> >> >> > -
>> >> >> >> > что
>> >> >> >> > делать, если управление передаётся в другой контроллер.
>> >> >> >> > Или как обрабатывать save подчинённого объекта, не передавая
>> >> >> >> > управление (flow) в его контроллер.
>> >> >> >> > Плюс то, что модель нельзя определить внутри action какого-либо
>> >> >> >> > состояния, а можно только лишь параметры в обработке
>> >> >> >> > on("событие")
>> >> >> >> > {[параметры]}.

>> >> >> >> > Ты работал с Webflow? Может я чего-то не понимаю?

>> >> >> >> > On 7 янв, 23:40, "Vlad Kasyanenko" <vlad.kasyane...@gmail.com>
>> >> >> >> > wrote:
>> >> >> >> >> ну тогда нужно "пробрасывать" в confirmation show view
>> >> >> >> >> информацию
>> >> >> >> >> откуда ты
>> >> >> >> >> пришел. первое что приходит в голову