Пытаюсь все-таки, понять, как правильно проектировать приложения с использованием Struts 2 (не путать со Struts 1). Хотелось бы научиться делать с его помощью достаточно сложный GUI, причем очень хотелось бы, чтобы спроектированно это все было правильно (сложные формы разделять на компоненты (подформы), которые ничего не знают о родителях и соседних компонентах, максимально повторно использовать код, обеспечить возможность быстро значительно поменять интерфейс), и при этом не тормозило. Использовать еще желательно AJAX. Как все это делать в обычном не веб программировании основываясь на событиях я знаю, хотелось бы научиться делать тоже самое в веб программировании. А пока обобщенно программировать не получается, а если получается, то это все страшно тормозит и явно оказывается извратным решением.
Ответа нет, тогда небольшая корректировка вопроса (copy-paste из моего вопроса для форума веб программирование):
Хотелось бы спросить, правда ли, что в веб программировании не рекомендуется хранить state формы внутри http сессии? Каждая ссылка должна быть самодостаточной? Обуславливают это тем, что пользователь может открыть в браузере новую вкладку в рамках той же сессии и в результате при использовании состояний то, что пользователь наделает во второй вкладке повлияет на первую, что баг.
И собственно вопрос знакомых со Struts 2.
Вопрос возник по следующей причине. Пишется приложение с использованием Struts 2. Соответственно есть модель, есть view, вместо контроллера выступает action. Этот Action не содержит никакого состояния, перед его вызовом view (JSP) устанавливает ему все необходимые поля. Я бы для хранения состояния использовал http сессию, в этом случае бы получился нормальный controller. Допустимо ли так писать приложения (мне один более опытный разработчик говорит, что я огребу проблем при таком подходе, но не может объяснить почему)? А при нетривиальном GUI (используется AJAX и формочки могут содержать подформочки, не знающие ничего о родителях) без использовании состояний (состояния передаю в s:url копируя значения текущего своего action в вызываемый action) разработка у меня очень сильно затруднена (да и много деталей нужно помнить), хотя бы по причине непривычности и пока мне трудно использовать ООП для уменьшения сложности (хотя от меня требуют еще и про ООП забыть в веб программировании)).
Мне собственно в упрек ставят, что я пытаюсь перенести на веб программирование приемы из обычного программирования а я не могу пока понять (небольшой опыт разработки веб приложений есть, но без всяких фреймворков, опыт обычного построения gui вроде нормально переносился и на веб gui).
Неужели разница между обычным и веб программированием такая большая?
PS. На данный момент склоняюсь к дизайну, построенному на notyfy/listenTopics и состояниях. Дочерним элементам от родителей передается topic который следует кидать при определенном действии, и в момент какого-то действия (например клика) на элементе может вызываться notifyTopic. В результате родитель и связанные формочки будут при необходимости перерисовываться.
E>Хотелось бы спросить, правда ли, что в веб программировании не рекомендуется хранить state формы внутри http сессии? Каждая ссылка должна быть самодостаточной? Обуславливают это тем, что пользователь может открыть в браузере новую вкладку в рамках той же сессии и в результате при использовании состояний то, что пользователь наделает во второй вкладке повлияет на первую, что баг.
лично я согласен с этим, точнее сказать — каждый цикл request-response должен быть самодостаточным, то что используется внутри этого цикла, например, между несколькими форвардами, должно храниться в контексте реквеста (объект формы кажется вполне сюда входит), те данные которые используются между нескольими циклами request-response одной сессии должны храниться в контексте сессии (кредентиалс юзера например), те, которые используются между несколькими сессиями — хранятся в контексте приложения, ну и т.д.
и помойму, если не следовать такой логике можно получать странности при каждом удобном случае
Здравствуйте, elmal, Вы писали:
E>Ответа нет, тогда небольшая корректировка вопроса (copy-paste из моего вопроса для форума веб программирование):
E>Хотелось бы спросить, правда ли, что в веб программировании не рекомендуется хранить state формы внутри http сессии? Каждая ссылка должна быть самодостаточной? Обуславливают это тем, что пользователь может открыть в браузере новую вкладку в рамках той же сессии и в результате при использовании состояний то, что пользователь наделает во второй вкладке повлияет на первую, что баг.
E>И собственно вопрос знакомых со Struts 2. E>Вопрос возник по следующей причине. Пишется приложение с использованием Struts 2. Соответственно есть модель, есть view, вместо контроллера выступает action. Этот Action не содержит никакого состояния, перед его вызовом view (JSP) устанавливает ему все необходимые поля. Я бы для хранения состояния использовал http сессию, в этом случае бы получился нормальный controller. Допустимо ли так писать приложения (мне один более опытный разработчик говорит, что я огребу проблем при таком подходе, но не может объяснить почему)? А при нетривиальном GUI (используется AJAX и формочки могут содержать подформочки, не знающие ничего о родителях) без использовании состояний (состояния передаю в s:url копируя значения текущего своего action в вызываемый action) разработка у меня очень сильно затруднена (да и много деталей нужно помнить), хотя бы по причине непривычности и пока мне трудно использовать ООП для уменьшения сложности (хотя от меня требуют еще и про ООП забыть в веб программировании)).
Посмотри на http://www.zkoss.org/ , может легче станет, поверишь в то, что и в вебе бывают нормальные фремворки.
Конечно обычно абстракция реализуется с помощью некоторых допущений, поэтому чем больше веб приближается к ООП, тем больше возможностей теряется.
Конечно правильно все писать с помощью Struts/JSP/servlers, но в такой работе нужна хорошая дрессировка, чтобы генерить тонны кода и не париться (что лично мне затруднительно)
После работы с GUI тяжело смотреть на request/response в вебе, но веб это не гуй, тут правила игры другие.
Надо понимать, что HTML не придумывался для серьезных приложений, если б его авторы увидели, что сейчас делают с помощью HTML, они бы хорошо подумали над его стандартом, чтобы разработчикам не пришлось так извращаться
У меня тоже ломка была, я плюнул и свой фреймворк написал. В принципе ничо так получился, можно компоненты выделять благодаря XSLT. Списочные формы, формы редактирования динамически генерятся по аннотациям у POJO классов. Все бы хорошо, правда никакого Ajax. Как представил сколько писать чтобы все динамически было, плюнул — в http://www.zkoss.org/ уже все придумано за нас.
ДВ>Конечно обычно абстракция реализуется с помощью некоторых допущений, поэтому чем больше веб приближается к ООП, тем больше возможностей теряется.
поясните пожалуйста, в чем сакральный смысл так мешать понятия ООП и веб-разработки?
можно для веб-разработки использовать ООП языки и соответственно всю прелесть ООП,
также можно использовать процедурные приемы без прелестей ООП, но зато с прелестями процедурного подхода,
но вот то что вы пишете, лично мне не очень понятно
Публичные ресурсы должны быть самодостаточны. Приватные не обязательно — система аунтификации просто туда не пустит без нужного состояний.
Ну и незабываем, что отсутсвие состояния это тоже состояние и система должна адекватно на это реагировать.
Здравствуйте, elmal, Вы писали:
E>Ответа нет, тогда небольшая корректировка вопроса (copy-paste из моего вопроса для форума веб программирование):
E>Хотелось бы спросить, правда ли, что в веб программировании не рекомендуется хранить state формы внутри http сессии? Каждая ссылка должна быть самодостаточной? Обуславливают это тем, что пользователь может открыть в браузере новую вкладку в рамках той же сессии и в результате при использовании состояний то, что пользователь наделает во второй вкладке повлияет на первую, что баг.
Невижу тут собстно никакого бага. Сделаешь чтобы был баг — будет баг. Сделаешь чтобы не было бага — его не будет. Состояние все равно во многих приложениях необходимо и от этого ты никуда не денешься.
Одна из причин минимизировать использование HTTP сессии на серверной стороне это забота о будущей кластеризации. На вскидку я знаю 3 способа сохранить состояние пользователя.
1) Держать данные о состоянии клиента у самого клиента. Это можеть быть URL, либо скрытые поля.
2) Держать состояние в БД.
3) Держать состояние в памяти сервера приолжений. То что обычно и называют HTTP сессией.
Так вот в случае если состояние реализовано третим вариантом кластеризация будет проблематичной, из-за того что большое количество данных нужно будет синхронизировать между серверами. Что будет давать дополнительную нагрузку на весь кластер.
ДВ>>Конечно обычно абстракция реализуется с помощью некоторых допущений, поэтому чем больше веб приближается к ООП, тем больше возможностей теряется.
D>поясните пожалуйста, в чем сакральный смысл так мешать понятия ООП и веб-разработки? D>можно для веб-разработки использовать ООП языки и соответственно всю прелесть ООП, D>также можно использовать процедурные приемы без прелестей ООП, но зато с прелестями процедурного подхода, D>но вот то что вы пишете, лично мне не очень понятно
Еще Ашманов писал, что программисты стремятся к обобщению, то есть разделять код на изменяемую часть и неизменяемую, компоненты выделять и пр.. Потому что когда есть компонент, ты используешь уже оттестированный и расчитанный на некоторый use-case функционал — время экономится, да и в будущем проблем меньше
Blazkowicz wrote: > Так вот в случае если состояние реализовано третим вариантом > кластеризация будет проблематичной, из-за того что большое количество > данных нужно будет синхронизировать между серверами. Что будет давать > дополнительную нагрузку на весь кластер.
По опыту — это эффективнее БД. Даже JBoss Cache работает быстрее БД
(особенно, если БД тоже для надежности кластеризована).
А хранение всего на клиенте не всегда возможно по соображениям безопасности.
Здравствуйте, Blazkowicz, Вы писали:
B> На вскидку я знаю 3 способа сохранить состояние пользователя. B>1) Держать данные о состоянии клиента у самого клиента. Это можеть быть URL, либо скрытые поля.
Собственно сейчас так и делаю. Только не получается никак это красиво обернуть. Вложенному AJAX DIV приходится все равно знать о родителе, чтобы хранить и не потерять его состояние. Универсально написать не получается, приходится делать copy-paste. И без оборачивания приходится быть крайне внимательным, приходится постоянно помнить о своем состоянии и состоянии родителя, чтобы не потерять состояния и не попутать. Да и приходится при нажатии на элемент дочернего AJAX DIV полностью перерисовывать родителя, если требуется, чтобы результат отразился на соседнем DIVе или даже на нескольких DIVах, что негативно отражается на скорости выполнения.
Кстати, если не изменяет мне память, паттерн MVC придумали именно для веб первоначально, он очень упрощает жизнь. Но без состояния контроллера как-то очень уж неудобно хранить это все на стороне view. Неужели все так мучаются?
ДВ>Еще Ашманов писал, что программисты стремятся к обобщению, то есть разделять код на изменяемую часть и неизменяемую, компоненты выделять и пр.. Потому что когда есть компонент, ты используешь уже оттестированный и расчитанный на некоторый use-case функционал — время экономится, да и в будущем проблем меньше
т.е если я для веб-приложения создал ряд лэйеров, доменную модель со всяческими классами, которые правильно друг друга используют — это не ООП,
а если я допустим в дельфи перенес кнопочку на форму, т.е заюзал написанный кем-то компонент — то это ООП, так?
помойму компоненты — это компоненты, а ООП все-таки более широкое понятие, и заменять их друг другом — не круто
Здравствуйте, dolor, Вы писали:
ДВ>>Еще Ашманов писал, что программисты стремятся к обобщению, то есть разделять код на изменяемую часть и неизменяемую, компоненты выделять и пр.. Потому что когда есть компонент, ты используешь уже оттестированный и расчитанный на некоторый use-case функционал — время экономится, да и в будущем проблем меньше
D>т.е если я для веб-приложения создал ряд лэйеров, доменную модель со всяческими классами, которые правильно друг друга используют — это не ООП, D>а если я допустим в дельфи перенес кнопочку на форму, т.е заюзал написанный кем-то компонент — то это ООП, так?
D>помойму компоненты — это компоненты, а ООП все-таки более широкое понятие, и заменять их друг другом — не круто
ООП это ООП. А кнопка в Делфях это кнопка. Ты лучше эту кнопку из делфей сравни с кнопкой в HTML
Правда я уже не понимаю о чем мы спорим. Я никому ничего не пытаюсь доказать и навязать, и я не утверждал, что что-то круто, а что-то отстойно. Я просто сказал о своих предпочтениях.
Здравствуйте, elmal, Вы писали:
E>Хотелось бы спросить, правда ли, что в веб программировании не рекомендуется хранить state формы внутри http сессии? Каждая ссылка должна быть самодостаточной? Обуславливают это тем, что пользователь может открыть в браузере новую вкладку в рамках той же сессии и в результате при использовании состояний то, что пользователь наделает во второй вкладке повлияет на первую, что баг.
нет, не правда.
по целому ряду причин, некоторые из которых уже здесь упомянули (секурность, простота и, как следствие, надёжность программ)
могу добавить еще, что, скажем, в wicket реализовано также хранение состояния предыдущих экранов, так что если пользователь несколько раз нажмет кнопку "Back", то ему можно предоставить корректную поддержку продолжения работы по другому пути
как может появиться баг, если ты заранее знаешь о том, что пользователь может работать в одной сессии параллельно с нескольких вкладок? только, если ты проигнорируешь это знание
Здравствуйте, C0s, Вы писали:
C0s>как может появиться баг, если ты заранее знаешь о том, что пользователь может работать в одной сессии параллельно с нескольких вкладок? только, если ты проигнорируешь это знание
А даже если не проигнорирую — что мне делать с этим знанием? Я же пользователю не могу запретить открывать новые вкладки? Только одним способом вроде — не хранить состояния на сервере. Либо описывать в документации, что не надо открывать другие вкладки, если что изменяется на одной автоматом изменит другую .
Здравствуйте, Cyberax, Вы писали:
C>Blazkowicz wrote: >> Так вот в случае если состояние реализовано третим вариантом >> кластеризация будет проблематичной, из-за того что большое количество >> данных нужно будет синхронизировать между серверами. Что будет давать >> дополнительную нагрузку на весь кластер.
C>По опыту — это эффективнее БД. Даже JBoss Cache работает быстрее БД C>(особенно, если БД тоже для надежности кластеризована).
синхронизировать не обязательно.
обычно же применяются sticky-sessions, т.е. пользовательская сессия обслуживается одним и тем же контейнером.
sticky-сессия сохраняется в БД только для failover, и уж точно нет никакой необходимости синхронизировать каждое изменение состояния сессии по факту обработки каждого риквеста со всеми нодами кластера — мы же исходим их того, что вероятность сбоя очень мала? потом, если сбой таки произойдет, то сессия должна быть восстановлена лишь в том контейнере, который подхватит обслуживание пользователя, всем остальным контейнерам в кластере должно оставаться глубоко по барабану до этой сессии
Здравствуйте, Cyberax, Вы писали:
C>По опыту — это эффективнее БД. Даже JBoss Cache работает быстрее БД C>(особенно, если БД тоже для надежности кластеризована).
Обоснование есть какое-то? Как-то не могу понять откуда такой опыт.
C>А хранение всего на клиенте не всегда возможно по соображениям безопасности.
Я вообще-то не хотел сказать что надо зацикливатся на базе или клиентской сессии. Конечно же рулит комбинация из всех подходов.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, C0s, Вы писали:
C0s>>как может появиться баг, если ты заранее знаешь о том, что пользователь может работать в одной сессии параллельно с нескольких вкладок? только, если ты проигнорируешь это знание E>А даже если не проигнорирую — что мне делать с этим знанием? Я же пользователю не могу запретить открывать новые вкладки? Только одним способом вроде — не хранить состояния на сервере. Либо описывать в документации, что не надо открывать другие вкладки, если что изменяется на одной автоматом изменит другую .
Сериализуй нужные тебе данные и храни их в БД, если уж такие коллеги у тебя упорные. А между закладками получается можно передавать id записи. Хотя в данном случае получилась реализация сессии Но зато возможно к тебе приставать не будут
Здравствуйте, elmal, Вы писали:
C0s>>как может появиться баг, если ты заранее знаешь о том, что пользователь может работать в одной сессии параллельно с нескольких вкладок? только, если ты проигнорируешь это знание
E>А даже если не проигнорирую — что мне делать с этим знанием?
учесть это в серверной логике обработки, в т.ч. синхронизируя доступ к совместным объектам
E>Я же пользователю не могу запретить открывать новые вкладки?
высший пилотаж — корректная обработка двух одновременных ajax-запросов. т.е. проблема вообще не зависит от количества вкладок
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Сериализуй нужные тебе данные и храни их в БД, если уж такие коллеги у тебя упорные. А между закладками получается можно передавать id записи. Хотя в данном случае получилась реализация сессии Но зато возможно к тебе приставать не будут
имхо не стоит давать советов делать кустарные велосипеды.
поддержка сессий уже реализована лучше, чем можно сляпать у себя на коленке
(что лично мне затруднительно)
