У меня встала довольно-таки нестандартная задача. Есть страница, которая генерируется скриптом при нажатии на кнопку. Генерируется она в том же окне (или в одном из фреймов, что можно сделать при необходимости), так как ее генерация на сервере просто не имеет смысла по поставленное задаче.
Проблема состоит в том, что нужно сделать так, чтобы пользователь видел ее как другую страницу, т.е. в адресной строке браузера после нажатия на кнопку должен отображаться другой УРЛ (точнее другие параметры). Пользователь при необходимости должен иметь возможность скопировать этот УРЛ. Если он попытается открыть его, откроется та же страница, на которой находится кнопка, и ее обработчик запустится автоматически, так что пользователь будет видеть то же содержимое, которое отображалось, когда он копировал УРЛ.
Естественно, что если задать windows.location, то страница просто будет перезагружена. При этом будут потеряны данные, сгенерированные скриптом и находящиеся в контексте текущего окна. Сохранить их в "пирожках" тоже не удасться, так как они могут весить очень много.
Вот така вот проблема. У кого-нибудь есть идеи по ее решению?
Может быть, просто его плохо сформулировали? Я минут 10 пытался разобраться, о чем же идет речь
Как вариант: передавать на новую страницу (с новым URI) постом флажок, при отсутствии которого она будет редиректать обратно на первую (со старым URI) с еще одним флажком, который в свою очередь будет заставлять эту первую страницу авто-сабмитать форму и переходить снова на вторую страницу, которую пользователь и запрашивал.
Здравствуйте, Aggtaa, Вы писали:
A>Может быть, просто его плохо сформулировали? Я минут 10 пытался разобраться, о чем же идет речь
A>Как вариант: передавать на новую страницу (с новым URI) постом флажок, при отсутствии которого она будет редиректать обратно на первую (со старым URI) с еще одним флажком, который в свою очередь будет заставлять эту первую страницу авто-сабмитать форму и переходить снова на вторую страницу, которую пользователь и запрашивал.
Большое спасибо за ответ. Да, видимо я изъяснился совсем неясно. И хотя ваш ответ для меня показался не более ясным, чем мой вопрос, по крайней мере у меня исчезло чувство, что меня просто игнорируют
Вообще это немного не подходит. Речь идет о том, чтобы просто изменить текст в адресной строке без перезагрузки страницы. Т.е. фактически никакого обращения к серверу не было, а просто выполнился скрипт, а юзер уже видит в адресной строке другой УРЛ. Вот и все, вчем состоит задача.
Тут в чисто из любопытства может возникнуть вопрос: к чему такие извращения? А к тому, что в памяти висят данные, собранные жаваскриптом, а сбрасывать их нельзя. Отсюда может последовать предложение сохранить данные в куки, перейти по другому URL, а после перехода на другую страницу скриптом их от туда же и вытянуть. Но здесь возникает проблема, потому что данные настолько объемные, что они не вмещаются в куки. Ну и третий вопрос, который может возникнуть, — зачем вообще нужно, чтобы адресаня строка менялась? А затем, что пользователь нажимает на кнопку на странице, и скрипт генерирует данные и выводит их и при этом не обращается к серверу, а пользователь должен иметь прямой доступ к этой автогенерируемой на клиентской стороне странице, т.е. после генерирования и вывода данных он может захотеть скопировать УРЛ, а через некоторое время снова открыть страницу по этому УРЛ, и если он копировал УРЛ после генерации вывода, то и при открытии должен уже сразу видеть эту информацию.
Блин. опять я все закрутил... Я просто не знаю как это еще можно объяснить. Мне просто нельзя перезагружать страницу при нажатии на ссылку, просто генерируется вывод и пишется в окно. А юзер должен думать, что открылась новая страница, и если он сохраняет ссылку, то именно на эту сгенерированную страницу, а не на ту, которая была до нажатии ссылки. Что именно должно быть в УРЛ, это уже не проблема. Главное подменить УРЛ в адресной строке так, чтобы сама страница не перезагрузилась, и жаваскриптовые переменные не сбросились.
Сразу оговорюсь: подменить адрес в интерфейсе браузера без перезагрузки страницы невозможно. Покрайней мере, в большинстве из них, в т.ч. в IE.
С какой целью необходимо отказываться от перезагрузки страницы? Если из опасений потерять собранные динамическим скриптом данные, то ведь ничто не мешает передать их через сессию или post-запрос на новый адрес. Если это действительно необходимо, то данные для второй страницы (той, на которую пользователь попадает после нажатия на кнопку и URI которой он впоследствии вводит в браузере) можно запросить с сервера заранее, а затем без дополнительных запросов сформировать ее на клиенте путем document.write()
Второй вопрос: если данные, собираемые скриптом воспроизводимы (скрипт при одинаковых условиях выдает одинаковые данные) — а я исхожу из того, что есть вариант сохранять их в куках — то почему вторая страница не может запросить эти данные у страницы с динамическим скриптом? Способов для решения этого вопроса множество: FRAME, IFRAME, Window.Open или даже банальный циклический редирект, который я уже предложил.
Третий вопрос. Если данные все же воспроизводимы, то почему нельзя поместить один и тот-же динамический скрипт на обе эти страницы? А контекст работы для этого скрипта сохранять в куках (если он, конечно, меньше по размеру..)
Здравствуйте, Lonely Mazaretsky, Вы писали:
LM>Большое спасибо за ответ. Да, видимо я изъяснился совсем неясно. И хотя ваш ответ для меня показался не более ясным, чем мой вопрос, по крайней мере у меня исчезло чувство, что меня просто игнорируют
LM>[]
Не, отсутствие ответов часто означает, что мыслей о положительном решении проблемы нет, а отрицательно отвечать уверенности не достает. По крайней мере в твоем случае я смолчал по этой причине.
Все-таки рискну выразится категорично. Соответствие содержимого адресной строки браузера контенту является частью, во-первых, безопасности (по этой причине тебе никто никогда не даст менять адресную строку из JavaScript, а то этой фичей тут же воспользуются умельцы подделывать коммерческие сайты), а во-вторых, юзабилити (все привыкли, что новый адрес — новый запрос к серверу, и нефиг путаницу наводить).
С другой стороны, нынешние сайты больше похожи на windows-приложения. Ты же не станешь запускать winword.exe /cfgdlg, чтобы сразу после запуска он открывал диалог настроек. С этой точки зрения можно рассматривать URL как имя программы, и реализовывать закладки как часть интерфейса программы, как именно — дело десятое (в любом случае все будет завязано на идентификации юзера через куки). Например, поддержка XSLT на клиентах, как аннонсировалось кажется самим W3C, позволяет изменять порядок сортировки строк таблицы без повторных обращений к серверу.
Разумеется, такой подход до некоторой степени может напрягать юзеров своей непривычностью. Скажем, адресные строки, показывающие отдельные сообщения или ветки форума на RSDN, мне пришлось выучить. Но если упереться рогом в "концептуальное единство", можно сделать сайт, вообще не показывающий внутренних URL, у которого, скажем, в качестве одной из менюшек будет список пользовательских закладок.
Только зачем? Извращение это все. Есть каноны, и мм надо следовать, пусть даже с некоторой потерей производительности. Иначе не только юзеры, но и ты сам будешь чувствовать раздражение от того, что твоим сайтом неудобно пользоваться, потому что он "не такой, как все". Чистое юзабилити. Это раздражение уже заставило меня переделать два сайта, слишком злоупотреблявших динамической генерацией страниц (кстати, довольно долгой).
Отдельное спасиб Вам, Дм.Григорьев, за довольно-таки интересные высказывания
Мне очень понравилась ваша мысль про закладки. Это действительно выход. Ведь вполне можно организовать удобную функцию добавления закладок, а даже возможность скопировать закладку в виде УРЛ.
Конечно современные сайты со своей динамичностью все больше завоевывают право называть себя интернет-приложениями. Однако, как не крути, практически на каждом сайте есть информация, которая теоретически может стать объектом для отправления в Favorites, даже если она меняется со временем. Это уже скорее похоже на ссылки на объекты, а не на страницы. И это вообще касается не только сайтов. К примеру favorites в MSDN мне сильно облегчили жизнь Теми же фаворитес можно назвать и кустомизированный тулбар в любимой среде разработки. Единственная проблема в том, что интернет похож на паутину только потому, что существует URI. Если сделать на сайте свою систему Favorites, то она будет работать только в пределах этого сайта. И я не вижу способа управлять такими действиями юзера, как копирование URL, являющегося на самом деле просто адресом сайта, а не того, что он видит в данную минуту, или добавлением в стандартные Favorites. Это на самом деле грустно.
Конечно же мне не раз приходила в голову такая мысль: "Нет, это неправильно. Если делать все по-своему, это будет неудобно и несовместимо. Нельзя пытаться перепрыгнуть время. Нужно пользоваться стандартными средствами и подходами, только в этом случае система будет юзабильной". Но с другой стороны меня огорчает, что пользователю прийдется ждать перезагрузку страницы, когда она вообще не требуется, потому что все данные уже собраны.
Так что я теперь просто в растерянности по поводу того, что делать и как дальше жить
Re: Управление содержимым адресной строки
От:
Аноним
Дата:
28.05.04 09:16
Оценка:
Здравствуйте, Lonely Mazaretsky, Вы писали:
LM>Привет, народ!
LM>Проблема состоит в том, что нужно сделать так, чтобы пользователь видел ее как другую страницу, т.е. в адресной строке браузера после нажатия на кнопку должен отображаться другой УРЛ (точнее другие параметры). Пользователь при необходимости должен иметь возможность скопировать этот УРЛ. Если он попытается открыть его, откроется та же страница, на которой находится кнопка, и ее обработчик запустится автоматически, так что пользователь будет видеть то же содержимое, которое отображалось, когда он копировал УРЛ.
а если посмотреть в сторону фреймов? адрес будет всегда один, а искомая страница юудет открываться в дочернем окне?
Hello, "Lonely Mazaretsky" > > > Тут в чисто из любопытства может возникнуть вопрос: к чему такие извращения? А к тому, что в памяти висят данные, собранные жаваскриптом, а сбрасывать их нельзя. Отсюда может последовать предложение сохранить данные в куки, перейти по другому URL, а после перехода на другую страницу скриптом их от туда же и вытянуть. Но здесь возникает проблема, потому что данные настолько объемные, что они не вмещаются в куки.
В IE есть такая штука, как userData behavior — можно сохранить до 640k данных на домен. На сколько много данных собирается в javascript?
Posted via RSDN NNTP Server 1.9 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>В IE есть такая штука, как userData behavior — можно сохранить до 640k данных на домен. На сколько много данных собирается в javascript?
Данных может быть несколько метров, но может быть хватит и 640к. Только вот нужно, чтобы это работало не только в IE
Для обеспечения понимания собеседниками, не рекомендуется использовать слишком длинные предложения, поскольку первичный буфер парсера у человека ограничен, и при его превышении контекст приходится сбрасывать в долговременную память, и при наличии сложноподчиненных предложений производительность разбора радикально снижается, так что лучше ограничиться десятью-пятнадцатью словами на предложение, иначе есть риск, что никто просто не дочитает вопрос до конца в связи с переполнением буфера.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Lonely Mazaretsky, Вы писали:
S>Для обеспечения понимания собеседниками, не рекомендуется использовать слишком длинные предложения, поскольку первичный буфер парсера у человека ограничен, и при его превышении контекст приходится сбрасывать в долговременную память, и при наличии сложноподчиненных предложений производительность разбора радикально снижается, так что лучше ограничиться десятью-пятнадцатью словами на предложение, иначе есть риск, что никто просто не дочитает вопрос до конца в связи с переполнением буфера.
Большое спасибо за совет! Я обязательно постараюсь следовать ему.
Здравствуйте, Lonely Mazaretsky, Вы писали:
LM>Привет, народ!
LM>У меня встала довольно-таки нестандартная задача. Есть страница, которая генерируется скриптом при нажатии на кнопку. Генерируется она в том же окне (или в одном из фреймов, что можно сделать при необходимости), так как ее генерация на сервере просто не имеет смысла по поставленное задаче.
LM>Проблема состоит в том, что нужно сделать так, чтобы пользователь видел ее как другую страницу, т.е. в адресной строке браузера после нажатия на кнопку должен отображаться другой УРЛ (точнее другие параметры). Пользователь при необходимости должен иметь возможность скопировать этот УРЛ. Если он попытается открыть его, откроется та же страница, на которой находится кнопка, и ее обработчик запустится автоматически, так что пользователь будет видеть то же содержимое, которое отображалось, когда он копировал УРЛ.
LM>Естественно, что если задать windows.location, то страница просто будет перезагружена. При этом будут потеряны данные, сгенерированные скриптом и находящиеся в контексте текущего окна. Сохранить их в "пирожках" тоже не удасться, так как они могут весить очень много.
LM>Вот така вот проблема. У кого-нибудь есть идеи по ее решению?
Здравствуйте, Lonely Mazaretsky, Вы писали: LM>У меня встала довольно-таки нестандартная задача...
гм.. вот это загадка века.
Строку ввода адреса браузера тебе изменить никто не даст.
А можно поитересоваться: какого рода данные? Что за запросы, страницы, хостинг, наконец? Просто если нет возможности сделать дело одним способом, можно не опускать руки и не начиначть жаловаться на судьбу, а избрать более радикальные методы решения проблемы, php или perl например.
Выше идущее высказывание о php теряет смысл при использовании бесплатного хостинга
Здравствуйте, sh0ck_file, Вы писали:
_>гм.. вот это загадка века. _>Строку ввода адреса браузера тебе изменить никто не даст. _>А можно поитересоваться: какого рода данные? Что за запросы, страницы, хостинг, наконец? Просто если нет возможности сделать дело одним способом, можно не опускать руки и не начиначть жаловаться на судьбу, а избрать более радикальные методы решения проблемы, php или perl например. _>Выше идущее высказывание о php теряет смысл при использовании бесплатного хостинга
Позвольте с Вами не согласиться, sh0ck_file. Содержимым адресной строки можно управлять без особого труда. Для этого есть window.location (или document.URL, что, на сколько я знаю, является синонимом). Проблема лишь в том, что при изменении адреса страница перезагружается.
А руки никто не опускал Поиск решений продолжается.
Вы предложили использовать PHP или Perl.
Есть некоторая страница с формой. Назавем ее стр1. При нажатии кнопки (ссылки) на ней данные формы обрабатываются и открывается другая страница: стр2. Страница стр2 формируется полностью из данных, полученных после обработки других данных, введенных пользователем на странице стр1. Генерация этих данных происходит довольно долго (порядка нескольких секунд), и они имеют большой объем. Таким образом если на сайте несколько человек нажмет сабмит на стр1, то он уже будет перегружен, а пользователям прийдется долго ждать.
Сама форма небольшая, ее очень удобно передавать через GET. Таки образом можно всегда сделать закладку на стр2, послать ссылку другому пользователю сайта и т.д. Это очень важно, и при оптимизации нельзя потерять эту возможность.
Итак, дабы юзеры не стояли в очереди за страницей стр2, было решено перенести генерацию стр2 на клиента. В общем все просто: юзер кликает сабмит, и вместо отправки формы на сервер она обрабатывается прямо ни клиенте и формируется новая страница посредством DHTML. Все замечательно, если не считать того, что при таком варианте невозможно сослаться на стр2, поскольку ее просто не существует в статическом виде, и не существует кода на сервере, который ее сгенерировал бы, и она даже не имеет своего URL.
Первым решением, пришедшим в голову, было такое:
Пусть стр1 имеет следующий урл: http://www.site.com/str1.html (Здесь не имеет знаения, какое именно расширение: html или PHP, поскольку рассматриваемые нами действия производятся исключительно на клиенте).
Допустим, что после нажатия кнопки нам удалось добавить параметры к этому урл не вызвав перезагрузку страницы: http://www.site.com/str1.html?parameters.
Теперь мы добавляем на эту страницу скрипт, который при загрузке документа проверяет URL, и если он содержит параметры, то они подставляются в форму, и нажатие кнопки происходит автоматически. Таким образом мы восстанавливаем возможность ссылаться на стр2, которая по сути теперь является обработанной скриптом страницей стр1.
Однако встает другая проблема. Дело в том, что такие формочки обрабатываются одна за одной. Весь раздел на них основан. И сбоку есть колонка, которая отображает некоторые статистические данные, для составления которых нужны результаты обработки каждой формы. (Эти данные имеют смысл только при последовательной обработке формы, и они не нужны, когда пользователь открывает страницу с результатами по ссылке). Они накапливаются, складываются и отображаются. Когда форма обрабатывается на сервере, то и статистические данные формируются на сервере. Если же форма обрабатывается на клиенте без отсылки серверу, то данные остается хранить только на клиенте. А проблема в том, что когда юзер нажимает на сабмит и я меняю урл, добавляя в него параметры, страница автоматом перезагружается, и все накопленные данные теряются. Т.е. без обращения к серверу все равно не получается. Страница перезагружается, скрипт обнаруживает параметры в урле, подставляет их в форму и обрабатывает, а статистика теряется. Для формирования же этой статистики необходимы все результаты обработки каждой формы в исходном виде. Потому сбрасывать их в куки перед изменением URL удается только некоторое время.
Я долго искал способы где-то их сохранить, что-то мне предлагали здесь на форуме, но это было только для IE. В итоге я нашел только одно место, куда можно сохранять достаточно большой объем информации: window.name. Здесь мне удавалось сохранить данные исчисляемые мегабайтами, и они сохранялись после перехода с одной страницы на другую как в IE, так и в Mazilla.
В общем выход вроде как найден, но честно говоря мне совсем не нравится использовать свойство name объекта window для хранения посторонних данных. Чувствует мое сердце, что это может вылезти боком.
В общем, пока в разумьях. Рад буду услышать еще какие-нибудь советы.
Здравствуйте, Lonely Mazaretsky, Вы писали:
LM>Я долго искал способы где-то их сохранить, что-то мне предлагали здесь на форуме, но это было только для IE. В итоге я нашел только одно место, куда можно сохранять достаточно большой объем информации: window.name. Здесь мне удавалось сохранить данные исчисляемые мегабайтами, и они сохранялись после перехода с одной страницы на другую как в IE, так и в Mazilla.
А каков объем этих данных? Действительно ли весь он используется на стр2? Или часть его впоследствии будет передаваться на сервер для статистики (или чего-то еще)?
Здравствуйте, Aggtaa, Вы писали:
A>А каков объем этих данных? Действительно ли весь он используется на стр2? Или часть его впоследствии будет передаваться на сервер для статистики (или чего-то еще)?
На стр2 эти данные просто отображаются. Но результаты обработки каждой такой формы (т.е. то, что отображается на страницах стр2) нужны для составления статистики. И хотелось бы их уже не передавать на сервер, так как на каждого пользователя они могут достигать нескольких мегабайт (в зависимости от длительности сессии).
Погоди, давай разберемся.
1. То, что показывается пользователю, однозначно определяется пользовательским вводом. Так?
2. Ты хочешь сделать так, чтобы при обработке пользовательского ввода не происходило обращения к серверу.
3. При этом ты хочешь, чтобы вся информация о пользовательском вводе хранилась в URL, чтобы пользователь мог поставить закладку. Так?
4. Пусть адрес страницы у нас http://somesite/page.html Если ты будешь добавлять параметры, введенные пользователем, через ?, то браузер будет перегружать страницу, и придется все перегенерить заново. Я правильно понимаю, что это и есть проблема? Я не понял насчет потери статистики — ты же собираешься ее как-то восполнять при обращении по закладке, не так ли?
5. Попробуй поиграть со ссылками типа http://somesite/page.html#EncodedparametersString
Дело в том, что то, что после шарпа, с одной стороны не является адресом страницы, а потому не влияет на кэширование респонсов и не вызывает перезагрузки при смене в location. C другой стороны, оно хранится как часть закладки.
По идее, твоему скрипту должно быть по барабану, что декодировать — query или hash.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
