Здравствуйте, C0s, Вы писали:
C0s>высший пилотаж — корректная обработка двух одновременных ajax-запросов. т.е. проблема вообще не зависит от количества вкладок
Просьба пояснить на примере. Предположим у меня есть div, в который отображается информация для выбранного юзера (выбранный юзер является состоянием формы и хранится в сессии формы). Этот юзер выбирается в другом DIVе и выбранный юзер меняет состояние в сессии. Как мне сделать высший пилотаж, чтобы если пользователь выбрал 2 вкладки и поменял текущего пользователя во второй вкладке, чтобы это никак не отразилось на первой (допустим при рефреше)?
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Сериализуй нужные тебе данные и храни их в БД, если уж такие коллеги у тебя упорные. А между закладками получается можно передавать id записи. Хотя в данном случае получилась реализация сессии Но зато возможно к тебе приставать не будут
Это уж слишком извращенно, тем более снова получили сессию . Я думал о сериализации состояния и передачи этого сериализованного состояния c каждым URL. Это конечно упростит кое что, но не поможет полностью не обновлять родителя при клике на элементах дочерних DIVах.
Здравствуйте, elmal, Вы писали:
E>Это уж слишком извращенно, тем более снова получили сессию . Я думал о сериализации состояния и передачи этого сериализованного состояния c каждым URL. Это конечно упростит кое что, но не поможет полностью не обновлять родителя при клике на элементах дочерних DIVах.
Мне кажется ASP.NET что-то подобное делает. У них в hidden полях довольно подозрительный код.
Здравствуйте, elmal, Вы писали:
E>Просьба пояснить на примере. Предположим у меня есть div, в который отображается информация для выбранного юзера (выбранный юзер является состоянием формы и хранится в сессии формы). Этот юзер выбирается в другом DIVе и выбранный юзер меняет состояние в сессии. Как мне сделать высший пилотаж, чтобы если пользователь выбрал 2 вкладки и поменял текущего пользователя во второй вкладке, чтобы это никак не отразилось на первой (допустим при рефреше)?
Ты бы поток сознания упорядочил, а то "пользователь" поменял "текущего пользователя", сам себя тоесть. Если ты имеешь ввиду что юзер логиниться под одним аккаунтом, а потом в той же сессии под другим, то.
1) Нет ничего страшного если он после логина с другого аккаунта на обоих закладках убдет видеть один и тот же аккаунт, ибо нефиг.
2) Как вариант, вполне разумно было бы подчищать содержимое сессии перед логином и логаутом.
Я просто не верю что проекту сильно нужен финт ушами в виде 2х пользователей работающих в одной HTTP сессии.
Здравствуйте, elmal, Вы писали:
C0s>>высший пилотаж — корректная обработка двух одновременных ajax-запросов. т.е. проблема вообще не зависит от количества вкладок E>Просьба пояснить на примере. Предположим у меня есть div, в который отображается информация для выбранного юзера (выбранный юзер является состоянием формы и хранится в сессии формы). Этот юзер выбирается в другом DIVе и выбранный юзер меняет состояние в сессии. Как мне сделать высший пилотаж, чтобы если пользователь выбрал 2 вкладки и поменял текущего пользователя во второй вкладке, чтобы это никак не отразилось на первой (допустим при рефреше)?
если я правильно понимаю, то это решается тем, что у тебя в сессии столько бинов форм поиска-отображения юзера (в бине персистентным является только id текущего отображаемого пользователя, всё остальное — рендеринг-тайм), сколько реально было запросов на отображение этих форм (т.е. две закладки — две формы)
html каждой отрендеренной формы имеет свои уникальные urls для сабмита. уникальность достигается добавлением в url значений возрастающих с каждым запросом идентификаторов, и при сабмите (или ajax-запросу) именно по уникальному id определяется, в какой форме идёт активность. по факту отработанного запроса генерируются также новые уникальные urls, и обновляется внутренняя таблица соответствий id-форма.
тем самым будет достигнута цель развязки по первичным данным. потребуется ли доп. синхронизация на уровне обращения к БД за данными пользователя — зависит от нюансов устройства уровня обращения к данным. обычно это не требуется.
ps. изложенное воспринимай, пожалуйста, как идею — лучше, когда вся эта байда реализована за тебя фреймворком, чем самому это писать
Здравствуйте, elmal, Вы писали:
E>Кстати, если не изменяет мне память, паттерн MVC придумали именно для веб первоначально, он очень упрощает жизнь. Но без состояния контроллера как-то очень уж неудобно хранить это все на стороне view. Неужели все так мучаются?
Изменяет. MVC пришел из Smalltalk'a, который появился гораздо раньше WEB (да и сам MVC тоже, как мне кажется).
Здравствуйте, C0s, Вы писали:
C0s>ps. изложенное воспринимай, пожалуйста, как идею — лучше, когда вся эта байда реализована за тебя фреймворком, чем самому это писать
Итого — сессию разбиваем на подсессии, то есть считаем, что каждая вкладка — отдельная подсессия ? Что-то я сомневаюсь, что есть фреймворки, которые такое будут делать, скорее всего это самому придется писать, особенно когда ограничен выбором фреймворка.
Здравствуйте, Blazkowicz, Вы писали:
B>Ты бы поток сознания упорядочил, а то "пользователь" поменял "текущего пользователя", сам себя тоесть.
Виноват, путаница получилась. Уточняю. У меня есть страничка, содержащая несколько ajax div. В одном divе выбирается элемент, во втором и третьем отображается разная информация этого выбранного элемента. Выбранный элемент является состоянием формы и хранится в сессии для контроллера формы. Как мне сделать высший пилотаж, чтобы если пользователь выбрал 2 вкладки и поменял текущий элемент во второй вкладке, чтобы это никак не отразилось на первой (допустим при рефреше)?
Собственно мне уже на это ответили, решение конечно интересное, но как-то извратно получается.
Здравствуйте, elmal, Вы писали:
E>Итого — сессию разбиваем на подсессии, то есть считаем, что каждая вкладка — отдельная подсессия ?
не совсем так
описанный механизм в компонентной модели имеет стремление к тому, что каждому инстансу компонента (отдельного контрола или набора связанных в одну форму контролов) сопоставляется свой экземпляр модели данных. формирование уникальных urls реквестов — это всего лишь способ сопоставления тех инстансов компонентов, которые пользователь видит на экране, с соответствующими экземплярами данных внутри сессии.
кстати, в упрощённом подходе, при котором пользователю обеспечивается только одна закладка, описанный подход помогает сделать так, что в одной закладке, на которой пользователь успел нажать кнопку раньше, ему выдастся инфо по выбранному пользователю, а во второй, где он нажмёт кнопку позже, будет сказано, что url устарел
E>Что-то я сомневаюсь, что есть фреймворки, которые такое будут делать, скорее всего это самому придется писать, особенно когда ограничен выбором фреймворка.
посмотри на wicket.
и я вот еще не успел заценить zkoss, наверное, он тоже достоин внимания
Здравствуйте, C0s, Вы писали:
C0s>посмотри на wicket. C0s>и я вот еще не успел заценить zkoss, наверное, он тоже достоин внимания
По-моему zkoss не парится и сразу все состояние в сессию кладет.
В JSF то разделение было — session, request... А в zkoss вроде нет такого — например когда в http://www.zkoss.org/zkdemo/userguide/ сессия заканчивается, он выводит сообщение об ошибке и предлагает начать работу сначала
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Здравствуйте, C0s, Вы писали:
C0s>>посмотри на wicket. C0s>>и я вот еще не успел заценить zkoss, наверное, он тоже достоин внимания ДВ>По-моему zkoss не парится и сразу все состояние в сессию кладет. ДВ>В JSF то разделение было — session, request... А в zkoss вроде нет такого — например когда в http://www.zkoss.org/zkdemo/userguide/ сессия заканчивается, он выводит сообщение об ошибке и предлагает начать работу сначала
Хотя нет. Если с http://www.zkoss.org/zkdemo/userguide/ перейти на другую страницу и вернутся, предыдущее состояние теряется.
Здравствуйте, Дмитрий В, Вы писали:
ДВ>По-моему zkoss не парится и сразу все состояние в сессию кладет. ДВ>В JSF то разделение было — session, request... А в zkoss вроде нет такого — например когда в http://www.zkoss.org/zkdemo/userguide/ сессия заканчивается, он выводит сообщение об ошибке и предлагает начать работу сначала
речь шла не просто о сессии, а о грамотной обработке параллельных запросов в рамках одной сессии
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, Дмитрий В, Вы писали:
ДВ>>По-моему zkoss не парится и сразу все состояние в сессию кладет. ДВ>>В JSF то разделение было — session, request... А в zkoss вроде нет такого — например когда в http://www.zkoss.org/zkdemo/userguide/ сессия заканчивается, он выводит сообщение об ошибке и предлагает начать работу сначала
C0s>речь шла не просто о сессии, а о грамотной обработке параллельных запросов в рамках одной сессии
У zkoss ajax везде, в том числе и в закладках (чтобы грузить содержимое закладки при её открытии, а не при загрузки всего tabbedPane, надо отдельно настраивать). Поэтому при обновлении одной закладки другая можно ничего об этом не знать. И только когда всю страницу перегрузить, тогда будут видны изменения.
Здравствуйте, Дмитрий В, Вы писали:
C0s>>речь шла не просто о сессии, а о грамотной обработке параллельных запросов в рамках одной сессии ДВ>У zkoss ajax везде, в том числе и в закладках (чтобы грузить содержимое закладки при её открытии, а не при загрузки всего tabbedPane, надо отдельно настраивать). Поэтому при обновлении одной закладки другая можно ничего об этом не знать. И только когда всю страницу перегрузить, тогда будут видны изменения.
так вот и интересно понять, что там внутри да как, если на странице одновременно начать играться со всеми контролами (запросы пойдут параллельно)
Здравствуйте, Дмитрий В, Вы писали:
ДВ>У zkoss ajax везде, в том числе и в закладках (чтобы грузить содержимое закладки при её открытии, а не при загрузки всего tabbedPane, надо отдельно настраивать). Поэтому при обновлении одной закладки другая можно ничего об этом не знать. И только когда всю страницу перегрузить, тогда будут видны изменения.
Может я неправильно понял, но под закладками я понимал закладки браузера. То есть юзер берет и нажимает в браузере Ctrl + N или "открыть в новой вкладке" и получаем ту же страницу с той же сессией и соответственно с тем же состоянием (вначале). Это ... меня все правильно поняли, а то что-то всякие tabbed panel меня смущать стали ?
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Дмитрий В, Вы писали:
ДВ>>У zkoss ajax везде, в том числе и в закладках (чтобы грузить содержимое закладки при её открытии, а не при загрузки всего tabbedPane, надо отдельно настраивать). Поэтому при обновлении одной закладки другая можно ничего об этом не знать. И только когда всю страницу перегрузить, тогда будут видны изменения. E>Может я неправильно понял, но под закладками я понимал закладки браузера. То есть юзер берет и нажимает в браузере Ctrl + N или "открыть в новой вкладке" и получаем ту же страницу с той же сессией и соответственно с тем же состоянием (вначале). Это ... меня все правильно поняли, а то что-то всякие tabbed panel меня смущать стали ?
Ну если он запустит новый инстанс броузера, а не закладку откроет, то у него будет новая сессия, и он в ней будет жить
Не зря видимо в IE долго не хотели закладки делать, видимо из-за траблов с сессиями
Ну а в чем проблема — при выборе строки в таблице посылается ajax запрос с id выбранного объекта, на что возвращаются его данные и они отображаются. Зачем тут сессия?
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Ну если он запустит новый инстанс броузера, а не закладку откроет, то у него будет новая сессия, и он в ней будет жить
по ctrl+N новый инстанс, как ты его называешь, продолжал работать в той же сессии
ДВ>Не зря видимо в IE долго не хотели закладки делать, видимо из-за траблов с сессиями
причины, очевидно, другие
ДВ>Ну а в чем проблема — при выборе строки в таблице посылается ajax запрос с id выбранного объекта, на что возвращаются его данные и они отображаются. Зачем тут сессия?
проблема в том, что задач гораздо больше, чем "выбор строки в таблице".
любая сложная форма в момент редактирования данных запросто может "держать" сложное состояние, например, идентификаторы parent и reference-объектов (эти значения самому пользователю обычно не видны, а иногда ему и не полагается их видеть, а то ещё и поредактирует гад каким-нибудь web-инструментарием)
Но зато возможно к тебе приставать не будут
. Я думал о сериализации состояния и передачи этого сериализованного состояния c каждым URL. Это конечно упростит кое что, но не поможет полностью не обновлять родителя при клике на элементах дочерних DIVах.
