Добрый день! Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами), сделанным на Grails? Я начал один доморощенный проект, и сталкиваюсь с проблемами, которые наверняка уже кто-то решал. Нужен хороший совет "с поля боя".
> Добрый день! > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами), > сделанным на Grails? > Я начал один доморощенный проект, и сталкиваюсь с проблемами, которые > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".
В-общем, первая проблема: У меня есть объект домена Pilot, у которого есть много ClassConfirmation. Связь один-ко-многим. Не устраивает поведение pilot show view. При нажатии на ссылку classConfirmation (одиниз экземпляров подчинённого класса) я перехожу на classConfirmation show view, откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"
Как лучше всего организовать такую функциональность?
> Привет. > Есть такие. > Задавай свои вопросы без стеснения :) Будем рады помочь.
> 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
> В-общем, первая проблема: > У меня есть объект домена 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? > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами, которые > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".
Мне бы хотелось, чтобы 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
> > В-общем, первая проблема: > > У меня есть объект домена Pilot, у которого есть много > > ClassConfirmation. Связь один-ко-многим. > > Не устраивает поведение pilot show view. > > При нажатии на ссылку classConfirmation (одиниз экземпляров > > подчинённого класса) я перехожу на classConfirmation show view, > > откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"
> > Как лучше всего организовать такую функциональность?
> > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote: > > > Привет. > > > Есть такие. > > > Задавай свои вопросы без стеснения :) Будем рады помочь.
> > > > Добрый день! > > > > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами), > > > > сделанным на Grails? > > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами, которые > > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".
ну тогда нужно "пробрасывать" в confirmation show view информацию откуда ты пришел. первое что приходит в голову это формировать уришку вида /pilot/show/123 или /confirmation/list в соответсвующих вьюшках и пробрасывать get параметром (backUri, например). формировать можно так: g.createLink controller: controller, action: action, id: id
если в голову придет что-то более изящное - сообщу :)
> Мне бы хотелось, чтобы 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
> > > В-общем, первая проблема: > > > У меня есть объект домена Pilot, у которого есть много > > > ClassConfirmation. Связь один-ко-многим. > > > Не устраивает поведение pilot show view. > > > При нажатии на ссылку classConfirmation (одиниз экземпляров > > > подчинённого класса) я перехожу на classConfirmation show view, > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"
> > > Как лучше всего организовать такую функциональность?
> > > On 7 янв, 22:44, vlad.kasyane...@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
> если в голову придет что-то более изящное - сообщу :)
> > Мне бы хотелось, чтобы 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
> > > > В-общем, первая проблема: > > > > У меня есть объект домена Pilot, у которого есть много > > > > ClassConfirmation. Связь один-ко-многим. > > > > Не устраивает поведение pilot show view. > > > > При нажатии на ссылку classConfirmation (одиниз экземпляров > > > > подчинённого класса) я перехожу на classConfirmation show view, > > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"
> > > > Как лучше всего организовать такую функциональность?
> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote: > > > > > Привет. > > > > > Есть такие. > > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.
> > > > > > Добрый день! > > > > > > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами), > > > > > > сделанным на Grails? > > > > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами, > > которые > > > > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".
Работаю с 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
>> если в голову придет что-то более изящное - сообщу :)
>> > Мне бы хотелось, чтобы 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
>> > > > В-общем, первая проблема: >> > > > У меня есть объект домена Pilot, у которого есть много >> > > > ClassConfirmation. Связь один-ко-многим. >> > > > Не устраивает поведение pilot show view. >> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров >> > > > подчинённого класса) я перехожу на classConfirmation show view, >> > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку "back"
>> > > > Как лучше всего организовать такую функциональность?
>> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote: >> > > > > Привет. >> > > > > Есть такие. >> > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.
>> > > > > > Добрый день! >> > > > > > Скажите, есть здесь кто-то, кто сейчас занимается проектом(ами), >> > > > > > сделанным на Grails? >> > > > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами, >> > которые >> > > > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".
Добрый день! За subflow спасибо - я посмотрю. Насчёт модели внутри экшена, покажу на примере. Я хочу в начальном состоянии manageFlow рендерить список объектов (list view).
Хотелось бы писать так: def manageFlow = { listState { action{ [pilotInstanceList:Pilot.list(params)] } render(view:'/pilot/list') } }
> Работаю с 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
> >> если в голову придет что-то более изящное - сообщу :)
> >> > Мне бы хотелось, чтобы 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
> >> > > > В-общем, первая проблема: > >> > > > У меня есть объект домена Pilot, у которого есть много > >> > > > ClassConfirmation. Связь один-ко-многим. > >> > > > Не устраивает поведение pilot show view. > >> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров > >> > > > подчинённого класса) я перехожу на classConfirmation show view, > >> > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку > "back"
> >> > > > Как лучше всего организовать такую функциональность?
> >> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote: > >> > > > > Привет. > >> > > > > Есть такие. > >> > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.
> >> > > > > > Добрый день! > >> > > > > > Скажите, есть здесь кто-то, кто сейчас занимается > проектом(ами), > >> > > > > > сделанным на Grails? > >> > > > > > Я начал один доморощенный проект, и сталкиваюсь с проблемами, > >> > которые > >> > > > > > наверняка уже кто-то решал. Нужен хороший совет "с поля боя".
А! Вот вы о чем :-) Изначально тоже это не особо понравилось, но потом привык. Я использую action'ы для начальной инициализации визарда и для определения следующего шага визарда если он, к примеру, зависит от введёных на предыдущем шаге данных. Советую обратить внимание на эти не задокументированные соглашения при использовании сабфловов: http://www.nabble.com/Webflow-subflow---novice-musings-td17425431.html
8 января 2009 г. 12:02 пользователь Sergey Bondarenko <ente...@gmail.com> написал:
> Добрый день! > За subflow спасибо - я посмотрю. Насчёт модели внутри экшена, покажу на > примере. > Я хочу в начальном состоянии manageFlow рендерить список объектов (list > view).
> Непонятно, почему нельзя в 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
>> >> если в голову придет что-то более изящное - сообщу :)
>> >> > Мне бы хотелось, чтобы 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
>> >> > > > В-общем, первая проблема: >> >> > > > У меня есть объект домена Pilot, у которого есть много >> >> > > > ClassConfirmation. Связь один-ко-многим. >> >> > > > Не устраивает поведение pilot show view. >> >> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров >> >> > > > подчинённого класса) я перехожу на classConfirmation show view, >> >> > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку >> >> > > > "back"
>> >> > > > Как лучше всего организовать такую функциональность?
>> >> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote: >> >> > > > > Привет. >> >> > > > > Есть такие. >> >> > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.
Спасибо за ссылки! Да, неочевидные соглашения в 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).
> > Непонятно, почему нельзя в action{} определить модель, и её использовать > в > > том же state для рендеринга.
> > 8 января 2009 г. 9:18 пользователь Bogdan Danilyuk <danilyuk.bo@ > 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
> >> >> если в голову придет что-то более изящное - сообщу :)
> >> >> > Мне бы хотелось, чтобы 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".
> >> >> > > Ну в общем случае используя тэг <g:link controller="pilot" > >> >> > > action="show" > >> >> > > id="${pilot.id}">Back to pilot</g:link> > >> >> > > pilot.id - написал условно. как ты его будешь доставать зависит > от > >> >> > > того > >> >> > > какая модель доступна на вьюшке classConfirmation. возможно в > твоем > >> >> > случае > >> >> > > это будет classConfirmation.pilot.id
> >> >> > > > В-общем, первая проблема: > >> >> > > > У меня есть объект домена Pilot, у которого есть много > >> >> > > > ClassConfirmation. Связь один-ко-многим. > >> >> > > > Не устраивает поведение pilot show view. > >> >> > > > При нажатии на ссылку classConfirmation (одиниз экземпляров > >> >> > > > подчинённого класса) я перехожу на classConfirmation show > view, > >> >> > > > откуда нету обратной ссылки на pilots show view. Хочется кнопку > >> >> > > > "back"
> >> >> > > > Как лучше всего организовать такую функциональность?
> >> >> > > > On 7 янв, 22:44, vlad.kasyane...@gmail.com wrote: > >> >> > > > > Привет. > >> >> > > > > Есть такие. > >> >> > > > > Задавай свои вопросы без стеснения :) Будем рады помочь.
Да, сталкивался... Поэтому каждый флов именуется по-разному, обидная штука! Человеко понятный урл можно сделать потом только урл мапингами. Там есть еще много некрасивостей... Например - теряются интерцепторы если положить объект во флов. Еще, кстати, под версией 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).
>> > Непонятно, почему нельзя в 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
>> >> >> если в голову придет что-то более изящное - сообщу :)
>> >> >> > Мне бы хотелось, чтобы 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".
>> >> >> > > Ну в общем случае используя тэг <g:link controller="pilot" >> >> >> > > action="show" >> >> >> > > id="${pilot.id}">Back to pilot</g:link> >> >> >> > > pilot.id - написал условно. как ты его будешь доставать зависит >> >> >> > > от >> >> >> > > того >> >> >> > > какая модель доступна на вьюшке classConfirmation. возможно в >> >> >> > > твоем >> >> >> > случае >> >> >> > > это будет classConfirmation.pilot.id
>> >> >> > > > В-общем, первая проблема: >> >> >> > > > У меня есть объект домена 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.bo@ > 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).
> >> > Непонятно, почему нельзя в 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
> >> >> >> если в голову придет что-то более изящное - сообщу :)
> >> >> >> > Мне бы хотелось, чтобы 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".
Прошу прощения, я Вас дезинформировал, то поведение которое я описал уже пофиксили (только что проверил). Вы скорее всего столкнулись с вот этим багом 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).
>> >> > Непонятно, почему нельзя в 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
>> >> >> >> если в голову придет что-то более изящное - сообщу :)
>> >> >> >> > Мне бы хотелось, чтобы 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".
С этим багом я уже столкнулся раньше, хотя и в 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.bo@ > 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'ы для начальной инициализации визарда и для > >> >> определения следующего шага визарда если он, к примеру, зависит от > >> >> введёных на предыдущем шаге данных. > >> >> Советую обратить внимание на эти не задокументированные соглашения > при > >> >> использовании сабфловов:
> >> >> >> Работаю с 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
> >> >> >> >> если в голову придет что-то более изящное - сообщу :)
> С этим багом я уже столкнулся раньше, хотя и в 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'ы для начальной инициализации визарда и для >> >> >> определения следующего шага визарда если он, к примеру, зависит от >> >> >> введёных на предыдущем шаге данных. >> >> >> Советую обратить внимание на эти не задокументированные соглашения >> >> >> при >> >> >> использовании сабфловов:
>> >> >> >> Работаю с 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 >> >> >> >> >> информацию >> >> >> >> >> откуда ты >> >> >> >> >> пришел. первое что приходит в голову
> В джире не нашел, но создал два флова в разных контролах и все заработало. > Точно помню что подобная проблема была. > Позже посмотрю повнимательней.
> 8 января 2009 г. 16:57 пользователь Sergey Bondarenko > <ente...@gmail.com> написал: > > С этим багом я уже столкнулся раньше, хотя и в JIRA не находил ещё. > Поэтому > > использую имена типа состояний во flow типа showAction, showState и т.п. > > При этом проблема одинаковых названий flow в разных control-ах остаётся. > > А где пофиксили тот баг? Интересно взглянуть.
> > 8 января 2009 г. 16:51 пользователь Bogdan Danilyuk <danilyuk.bo@ > 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
> >> >> >> А! Вот вы о чем :-) > >> >> >> Изначально тоже это не особо понравилось, но потом привык. > >> >> >> Я использую action'ы для начальной инициализации визарда и для > >> >> >> определения следующего шага визарда если он, к примеру, зависит от > >> >> >> введёных на предыдущем шаге данных. > >> >> >> Советую обратить внимание на эти не задокументированные соглашения > >> >> >> при > >> >> >> использовании сабфловов:
> >> >> >> > Непонятно, почему нельзя в action{} определить модель, и её > >> >> >> > использовать > >> >> >> > в > >> >> >> > том же state для рендеринга.
> >> >> >> >> Работаю с Grails Webflow уже достаточно долго. Очень удобная > >> >> >> >> штука > >> >> >> >> для > >> >> >> >> построения визардов. > >> >> >> >> Насчет передачи управления в другой контроллер. В Grails есть > >> >> >> >> понятие > >> >> >> >> subflow, Вы можете использовать в основном флове вложенные > фловы. > >> >> >> >> Это > >> >> >> >> позволяет вкладывать визарды один в один. Вопрос передачи > >> >> >> >> контроля в > >> >> >> >> другой контроллер отпадает - используется флов из другого > >> >> >> >> контроллера > >> >> >> >> как вложенный (например для редактирования какого либо > объекта). > >> >> >> >> Последнего "но" по поводу определения модели внутри экшена не > >> >> >> >> понял, > >> >> >> >> не могли бы Вы перефразировать?!
> >> >> >> >> 8 января 2009 г. 2:12 пользователь Sergey Bondarenko > >> >> >> >> <ente...@gmail.com> написал: > >> >> >> >> > Ага, ну вот, супер! Это тот способ, к которому я в > >> >> >> >> > конце-концов > >> >> >> >> > склоняюсь.
> >> >> >> >> > Ещё я пробовал таким образом - сделать это через Grails > >> >> >> >> > Webflow.
> >> >> >> >> > Теоретически эта штука как раз для этого предназначена. > >> >> >> >> > На практике получается ряд "вредных" ограничений, как > например > >> >> >> >> > - > >> >> >> >> > что > >> >> >> >> > делать, если управление передаётся в другой контроллер. > >> >> >> >> > Или как обрабатывать save подчинённого объекта, не передавая > >> >> >> >> > управление (flow) в его контроллер. > >> >> >> >> > Плюс то, что модель нельзя определить внутри action > какого-либо > >> >> >> >> > состояния, а можно
