Всем привет.
У нас тут намечается проект с жесткими требованиями по масштабируемости и производительности. Теорию этого дела я себе более-менее представляю, хочу обсудить с коллегами некоторые практические аспекты.
Итак, к делу.
Сайт состоит из большого количества страниц, значительную часть которых составляет тяжеловесная статическая навигация. Что неприятно — так это то, что части страниц все-таки динамические, что мешает правильному кэшированию (а именно оно в вебе ключ к производительности).
В связи с этим у меня возникает идея построить шаблон страницы примерно так:
+<IFRAME>-------------------------+
| верхняя навигация, логотип и пр.|
+</IFRAME>------------------------+
+<IFRAME>---+ Вот тут - динамичный
| левое меню| контент.
| |
| |
| |
| |
| |
| |
+</IFRAME>--+
+<IFRAME>-------------------------+
| Футер: копирайт, адми мыло и пр.|
+</IFRAME>------------------------+
Т.е. выкинуть всю статику нафиг в ифреймы. По идее, это очень сильно сократит объем основных страниц, и позволит максимально использовать кэш браузера и проксей.
Однако подобная техника, сколько мне известно, не очень распространена.
Теперь, собственно, вопросы:
— есть ли какие-либо контраргументы? (может быть, IFRAME плохо cross-browser compatible?)
— есть ли опыт применения?
— любые комментарии привествуются
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Теперь, собственно, вопросы: S>- есть ли какие-либо контраргументы? (может быть, IFRAME плохо cross-browser compatible?)
Новые версии браузеров его вполне понимают. А вот со старыми он действительно, плохо совместим.
Если вы делаете Интранет-систему, то пофиг, конечно. Иначе придется выписывать требования к браузерам. Навскидку не скажу.
S>- есть ли опыт применения?
Да, мы его широко применяем. В-основном, для двух различных целей:
1) Сделать часть страницы редактируемой без перезагрузки основной страницы. Например, страница представляет собой систему Master-Detail, и при переходе по Master-ссылкам в основной странице обновляется только "подвал" с редактируемыми деталями в IFRAME. Очень удобно также прятать туда всякие тяжеловесные контролы, которые бы тормозили основную загрузку — например, DevExpress ASPxGrid. Минусы — у IFrame проблемы с вертикальным ресайзом, приходится делать его либо фиксированной высоты, либо хитро верстать в таблицу, либо использовать скрипты для ресайза.
2) Сделать часть страницы динамической без перезагрузки. Например, вставить в контент таблицу с результатами поиска или Tree-контрол, который динамически достраивает ветку при клике на "плюсик". Здесь применяется невидимый IFRAME размерами 1x1 пиксел, в который по мере необходимости грузится адрес нужной .aspx с параметром и полученный InnerHTML вставляется в нужное место. Фактически, такой доморощенный запрос к серверу без перезагрузки.
У этого подхода тоже есть минусы (IFRAME гадит в историю браузера и т.д.). Но в целом работает. Сейчас бы я применил другой способ: XmlHTTP или динамический рендеринг тэга <SCRIPT src="page.aspx?param=blablabla">. Недавно в форуме Dotnet.Web, кажется, пролетала интереснейшая ссылка. Gollum подскажет.
[... skipped ...]
R>У этого подхода тоже есть минусы (IFRAME гадит в историю браузера и т.д.). Но в целом работает. Сейчас бы я применил другой способ: XmlHTTP или динамический рендеринг тэга <SCRIPT src="page.aspx?param=blablabla">. Недавно в форуме Dotnet.Web, кажется, пролетала интереснейшая ссылка. Gollum подскажет.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, retalik, Вы писали:
O>[... skipped ...]
R>>У этого подхода тоже есть минусы (IFRAME гадит в историю браузера и т.д.). Но в целом работает. Сейчас бы я применил другой способ: XmlHTTP или динамический рендеринг тэга <SCRIPT src="page.aspx?param=blablabla">. Недавно в форуме Dotnet.Web, кажется, пролетала интереснейшая ссылка. Gollum подскажет.
O>Я не Gollum, но... Набла №41: JSHttpRequest: динамическая подкачка данных без перезагрузки страницы
Уникальность техники, описанной на той странице, в том, что не используется XMLHTTP и IFRAME для загрузки контента без post-back. Используется для этого тег <script> — на самом деле, описан достаточно остроумный и переносимый метод.
Здравствуйте, Oyster, Вы писали:
O>Уникальность техники, описанной на той странице, в том, что не используется XMLHTTP и IFRAME для загрузки контента без post-back. Используется для этого тег <script> — на самом деле, описан достаточно остроумный и переносимый метод.
Здравствуйте, mogadanez, Вы писали:
M>Здравствуйте, Oyster, Вы писали:
O>>Уникальность техники, описанной на той странице, в том, что не используется XMLHTTP и IFRAME для загрузки контента без post-back. Используется для этого тег <script> — на самом деле, описан достаточно остроумный и переносимый метод.
M>как появится посмотримс...
Идея в том, что в страничку динамически добавляется тег <script src="page.aspx?param1=value1&...">. Соответствующая page генерирует валидный JavaScript, в котором вызывается некая callback-функция клиента с параметрами респонса.
O>>[офф] O>>А не открывается страница, видимо, из-за того, что Москва частично сидит без электричества. O>>[/офф]
M>да..да.. а Питер тут причем
Цитата с той ссылки:
Почему не работают многие сайты
ММТС 9 осталась без электричества, как сообщили сотрудники станции корреспонденту NEWSru.com пока по неизвестных для них причинам. Поскольку через М9 проходит более 80% российского Интернет-трафика, и многие московские провайдеры устанавливают на М9 свое телекоммуникационное оборудование, большинство популярных Интернет-ресурсов будут недоступны, пока на станции не будут решены проблемы с электричеством.
Поэтому не работают многие проекты.
Также через М9 проходит большинство международных телекоммуникационных каналов, соединяющих Россию с миром, могут возникнуть проблемы с доступом из России к зарубежным Интернет-ресурсам и с международной телефонной связью.
Здравствуйте, mogadanez, Вы писали:
O>>[офф] O>>А не открывается страница, видимо, из-за того, что Москва частично сидит без электричества. O>>[/офф]
M>да..да.. а Питер тут причем
Спасибо, джентльмены. Но тут есть некоторая тонкость: я предполагаю использовать iframe как раз для статики, а не для динамики.
Сейчас я объясню почему.
Дело в том, что типичная страница современного сайта представляет собой этакий орешек, в котором очень толстая скорлупа статического контента обрамляет маахонькое зернышко динамического контента. Давайте рассмотрим клинический случай: у нас есть меню на 48 килобайт, всякие печки-рамочки, и унутре тока одна динамическая фишечка "текущее время сервера = 24.05.2005 17:00".
Итак, из всего текста страницы меняются ровно 16 байт. Поскольку они устаревают мгновенно, для корректного результата мы вынуждены выставлять страничке немедленный expiration. При нажатии F5 КПД равен, соответственно, 16/48000. Или примерно 0.03%. Маловато.
Что полезного мы можем сделать для нашей державы, т.е. сайта? Мы можем перенести текущее время сервера в маахонький iframe, задав ему отдельный src. Таким образом, мы развалили запрос на два. Первому, размером все в те же 48K, мы честно выставляем expiration в never, а второму, соответственно, в immediate. Теперь при нажатии F5 браузер не станет перезакачивать статику, что очень позитивно повлияет как на его эмоциональное состояние, так и на масштабируемость нашего сервера. Более того, при нажатии Ctrl+F5 сервер сможет обойтись отправкой 302 Not Modified, чтобы указать браузеру на его же кэш.
КПД = почти 100%.
Но надо сказать, что нам очень повезло с SRC этого внутреннего IFRAME. Потому, что он случайно оказался совершенно одинаковым для всех запросов.
Добавим толику интереса: пусть у нас теперь будут две странички. http://somesite.com/catalog/cars.coolsp и http://somesite.com/catalog/homes.coolsp
Эти странички отличаются только тем, что у одной в середине список из двух машынок, а у другой — список из двух домиков. Вокруг по прежнему 48к статики.
С точки зрения браузера, эти странички никак не связаны между собой. Поэтому ему придется делать отдельные запросы для их получения. КПД падает до 50%.
Если мы вынесем внутреннюю часть в IFRAME, то никакого результата не будет. Поскольку для браузера http://somesite.com/catalog/cars.coolsp и http://somesite.com/catalog/homes.coolsp — по прежнему разные документы. Равно как и http://somesite.com/catalog.coolsp?section=cars супротив http://somesite.com/catalog.coolsp?section=homes
Но фреймы суть великое зло, как минимум с точки зрения юзабилити. Поэтому хочется вместо них использовать IFRAME, чтобы создать впечатление полноценной страницы с плоской структурой.
Вот у меня и возникают вопросы относительно кроссбраузерной совместимости.
Облегчения:
— эти ифреймы скорее всего будут иметь фиксированные размеры
— эти ифреймы будут иметь статический SRC, никаких подгрузок контента с его последующим анализом [пока] не предполагается
З.Ы. еще один вопрос: а meta refresh ифреймы хорошо поддерживают? А то там есть одно место, где хочется сделать еще и автоматический релоад.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>как появится посмотримс...
O>Идея в том, что в страничку динамически добавляется тег <script src="page.aspx?param1=value1&...">. Соответствующая page генерирует валидный JavaScript, в котором вызывается некая callback-функция клиента с параметрами респонса.
Я такой фигней пользуюсь, например, здесь для генерации контента страницы.
Главный плюс — то, что после перехода по всем страницам они кэшируются и в итоге открываются моментально (как минимум, в Файрфоксе)
И он же — главный минус. Иногда браузер даже не запрашивает, а не изменился ли контент...
И еще минус. Говорят, что такой способ приводит к утечкам памяти в эксплорере
... << RSDN@Home 1.1.4 beta 7 rev. 447>> ... <<Winamp is playing "Elvis vs Jxl — A LITTLE LESS CONVERSATION — elvis vs jxl">> ..
[... skipped ...]
M>И еще минус. Говорят, что такой способ приводит к утечкам памяти в эксплорере
Насколько я знаю, IE "течёт" только в случае циклических ссылок, в которых учавствуют как объекты DOM, так и объекты JS. Вроде как фишка в том, что для объектов DOM и JavaScript используются разные GC, и в случае такой циклической ссылки объекты, учавствующие в ней, никогда не собираются. Known bug ещё с IE 4.
M>>И еще минус. Говорят, что такой способ приводит к утечкам памяти в эксплорере
O>Насколько я знаю, IE "течёт" только в случае циклических ссылок, в которых учавствуют как объекты DOM, так и объекты JS. Вроде как фишка в том, что для объектов DOM и JavaScript используются разные GC, и в случае такой циклической ссылки объекты, учавствующие в ней, никогда не собираются. Known bug ещё с IE 4.
Хмм... У меня подгружающийся JS заполняет некий объект в JS, которому потом говорит "фас" и тот начинает манипулировать ДОМом. В общем, надо переползать на XHTTP
... << RSDN@Home 1.1.4 beta 7 rev. 447>> ... <<Winamp is playing "The Verve — Bitter Sweet Symphony">> ...
S>Вот у меня и возникают вопросы относительно кроссбраузерной совместимости. S>Облегчения: S>- эти ифреймы скорее всего будут иметь фиксированные размеры S>- эти ифреймы будут иметь статический SRC, никаких подгрузок контента с его последующим анализом [пока] не предполагается
IFrame работает сам по себе на всех браузерах, но событие OnReadyStateChange(или как то так) позволяющее отслеживать его состояние есть только в IE
если это не нужно
— то проблем быть не должно, все будет работать на всех браузерах.
есть опыт использования iframe для всяких динамических выпадающих диалогов(типа datePicker), причем сам iframe создается динамически — работает везде
если надо, то есть всякие ухищрения, дающие почти такой же результат.
S>З.Ы. еще один вопрос: а meta refresh ифреймы хорошо поддерживают? А то там есть одно место, где хочется сделать еще и автоматический релоад.
Да.
единственное что может стать немного сложнее — это скрипты, если они должны работать с разными фреймами.
Здравствуйте, Mamut, Вы писали:
M>>>И еще минус. Говорят, что такой способ приводит к утечкам памяти в эксплорере
O>>Насколько я знаю, IE "течёт" только в случае циклических ссылок, в которых учавствуют как объекты DOM, так и объекты JS. Вроде как фишка в том, что для объектов DOM и JavaScript используются разные GC, и в случае такой циклической ссылки объекты, учавствующие в ней, никогда не собираются. Known bug ещё с IE 4.
M>Хмм... У меня подгружающийся JS заполняет некий объект в JS, которому потом говорит "фас" и тот начинает манипулировать ДОМом. В общем, надо переползать на XHTTP
Одно дело манипулировать, и совсем другое — создавать cyclic reference. Если ты манипулируешь DOM-ом — это ок, но если ты, например, посадишь обработчик на onclick, который в своём теле ссылается на этот же элемент — тогда труба. Вот пример того, как делать memory leak в IE :
<html>
<head>
<script>
function create_div()
{
var x = document.createElement("div");
x.innerText = 123;
// Тут создаётся замыкание - функция содержит ссылку на x,
// x содержит ссылку на функцию - итого memory leak
x.onclick = function() { alert("Clicked!"); };
document.body.appendChild(x);
}
function create()
{
for (var i = 0; i < 1000; ++i) {
create_div();
}
}
</script>
</head>
<body onload="create()">
</body>
</html>
Здравствуйте, Sinclair, Вы писали:
S>Всем привет. S>У нас тут намечается проект с жесткими требованиями по масштабируемости и производительности. Теорию этого дела я себе более-менее представляю, хочу обсудить с коллегами некоторые практические аспекты. S>Итак, к делу.
S>Т.е. выкинуть всю статику нафиг в ифреймы. По идее, это очень сильно сократит объем основных страниц, и позволит максимально использовать кэш браузера и проксей.
Хм, мы поступили наоборот — выкинули в IFRAME-ы динамику. Т.е. вся навигация висит в главном окне, а кнутри него сидит IFrame такого вида:
fr_load() подгружает соджержимое первой страницы внутрь iframe. Все изменения, которые могут происходить в главной странице (например, поменять отображение названия раздела или любые другие параметры вне фрэйма), делаются JavaScript-ом, приходящим внутри фрэйма.
Вся навигация перенаправляется таргетами внутрь врэйма.
Кстати, указанная технология хорошо подходит для закрытой системы (не публичной), поскольку сложнее подставлять под поисковики и делать полную печать страницы средствами браузера. Зато всё летает.
S>Однако подобная техника, сколько мне известно, не очень распространена.
Не очень распространена на очень публичных сайтах. По причине вышеуказанной...
S>Теперь, собственно, вопросы: S>- есть ли какие-либо контраргументы? (может быть, IFRAME плохо cross-browser compatible?)
Ну, в общем да...
При использовании iframe как минимум можно получить разный view в разных браузерах (где есть скроллер, где нет...). Да и, частенько, необходимо достаточно активно взаимодействовать с этим фрэймом из других фрэймов и из родительской страницы, что требует очень аккуратного прописывания JavaScript для обеспечения кроссбраузерности.
S>- есть ли опыт применения?
Есть. У нас весь вебинтерфейс системы прописан на iframe.
S>- любые комментарии привествуются
Всё проще, если ограничить пользователя использованием только IE, например Если это возможно, конечно.
Ещё такая штука — если хорошо пишется на JavaScript, то можно в главную страницу (да и в нулевые iframe-ы) выносить как можно больше JavaScript-овкого кода, чтобы не грузить его по сетке каждый раз. Да и некоторое форматирование тоже можно вынести. Например, подгружается страница только с данными, а страница прорисовыватся уже на клиенте заранее подгруженным JavaScript-ом.
Здравствуйте, Sinclair, Вы писали:
S> При нажатии F5 КПД равен, соответственно, 16/48000.
А что, бизнес процесс работы с сайтом подразумевает постоянное нажатие пользователями F5?
S>З.Ы. еще один вопрос: а meta refresh ифреймы хорошо поддерживают? А то там есть одно место, где хочется сделать еще и автоматический релоад.
Без проблем. Но лучше делать скриптом.
Здравствуйте, Spidola, Вы писали:
S>А что, бизнес процесс работы с сайтом подразумевает постоянное нажатие пользователями F5?
В частности. А в целом будет очень большая нагрузка со стороны различных пользователей, а также относительно длинные пути навигации по сайту в процессе визита. S>>З.Ы. еще один вопрос: а meta refresh ифреймы хорошо поддерживают? А то там есть одно место, где хочется сделать еще и автоматический релоад. S>Без проблем. Но лучше делать скриптом.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Всем привет. S>У нас тут намечается проект с жесткими требованиями по масштабируемости и производительности. Теорию этого дела я себе более-менее представляю, хочу обсудить с коллегами некоторые практические аспекты. S>Итак, к делу. S>Сайт состоит из большого количества страниц, значительную часть которых составляет тяжеловесная статическая навигация.
[...] S>- любые комментарии привествуются
Ok, тогда так.
А что такое тяжеловесная статическая навигация. и почему она тяжеловесная.. К тому же если посмотреть на prior art, то что-то не припомню сайтов concerned with "масштабируемость и производительность" сделанных так.
Я не expert, просто пытаюсь использовать "engineering common sense".
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, Mamut, Вы писали:
M>>>>И еще минус. Говорят, что такой способ приводит к утечкам памяти в эксплорере
O>Одно дело манипулировать, и совсем другое — создавать cyclic reference. Если ты манипулируешь DOM-ом — это ок, но если ты, например, посадишь обработчик на onclick, который в своём теле ссылается на этот же элемент — тогда труба. Вот пример того, как делать memory leak в IE :
O>
O><html>
O><head>
O><script>
O>function create_div()
O>{
O> var x = document.createElement("div");
O> x.innerText = 123;
O> // Тут создаётся замыкание - функция содержит ссылку на x,
O> // x содержит ссылку на функцию - итого memory leak
O> x.onclick = function() { alert("Clicked!"); };
O> document.body.appendChild(x);
O>}
O>function create()
O>{
O> for (var i = 0; i < 1000; ++i) {
O> create_div();
O> }
O>}
O></script>
O></head>
O><body onload="create()">
O></body>
O></html>
O>
Глубоко прокопано!
Это проверенно на IE? или еще на других browsers? Вообще то по идее замыкание образовываться не должно — function() { alert("Clicked!"); } не использует никаких переменных из create_div — но я давно ECMA standard читал уже деталей не упомню. Вообще надо бы разобраться и в FAQ.
Здравствуйте, mbergal, Вы писали: M>А что такое тяжеловесная статическая навигация. и почему она тяжеловесная..
А потому, что там куча всяких стандартных формочек, менюшечка с полусотней линков. Конечно же, она будет графическая. И конечно же, там будут ролловеры. А каждый ролловер — это лишние байты для биндинга обработчиков. В общем, типичный "красивый" сайт — это странички по 50-80k без учета графики. M>К тому же если посмотреть на prior art, то что-то не припомню сайтов concerned with "масштабируемость и производительность" сделанных так.
Это меня и беспокоит. Возиожно. это потому, что народ просто недотумкал. Многие простые идеи остаются невостребованными. Сколько ты знаешь сайтов, где сделан load on demand, как в дереве на RSDN? Единицы, верно? M>Я не expert, просто пытаюсь использовать "engineering common sense".
спасибо. Вот и я тоже пытаюсь. С точки зрения ECS, это хороший способ. Пока мне неясно, по какой причине его не применяют.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Spidola, Вы писали: S>Хм, мы поступили наоборот — выкинули в IFRAME-ы динамику. Т.е. вся навигация висит в главном окне, а кнутри него сидит IFrame такого вида:
Это знакомая техника. Вижу с ней несколько неудобных проблем. S>fr_load() подгружает соджержимое первой страницы внутрь iframe. Все изменения, которые могут происходить в главной странице (например, поменять отображение названия раздела или любые другие параметры вне фрэйма), делаются JavaScript-ом, приходящим внутри фрэйма.
А как насчет прямых ссылок и соответствия между урлом в адрес баре и контента страницы? Вот на rsdn приходится иметь отдельную кнопку для обновления верхнего урла. S>Вся навигация перенаправляется таргетами внутрь врэйма.
S>Кстати, указанная технология хорошо подходит для закрытой системы (не публичной), поскольку сложнее подставлять под поисковики и делать полную печать страницы средствами браузера. Зато всё летает.
Вот про эти проблемы хотелось бы поподробнее.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
[... skipped ...]
M>Глубоко прокопано!
M>Это проверенно на IE? или еще на других browsers?
Это именно IE known bug. В остальных браузерах вроде всё ОК.
M>Вообще то по идее замыкание образовываться не должно — function() { alert("Clicked!"); } не использует никаких переменных из create_div — но я давно ECMA standard читал уже деталей не упомню. Вообще надо бы разобраться и в FAQ.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, mbergal, Вы писали: M>>А что такое тяжеловесная статическая навигация. и почему она тяжеловесная.. S>А потому, что там куча всяких стандартных формочек, менюшечка с полусотней линков. Конечно же, она будет графическая. И конечно же, там будут ролловеры. А каждый ролловер — это лишние байты для биндинга обработчиков. В общем, типичный "красивый" сайт — это странички по 50-80k
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, mbergal, Вы писали: M>>А что такое тяжеловесная статическая навигация. и почему она тяжеловесная.. S>А потому, что там куча всяких стандартных формочек, менюшечка с полусотней линков. Конечно же, она будет графическая. И конечно же, там будут ролловеры. А каждый ролловер — это лишние байты для биндинга обработчиков. В общем, типичный "красивый" сайт — это странички по 50-80k без учета графики.
Тут надо смотреть конкретные Use cases.
— если страница информационная, то она перегружается не очень часто( загрузили, читаем, идем дальше ) — тут не совсем оправдано применение фреймов.
— если же предусмотрен интерактив с пользователем, где планируется ОЧЕНЬ много перегрузок в рамках одной страницы — то стоит подумать над оптимизацией( фреймы, callbacks...)
M>>К тому же если посмотреть на prior art, то что-то не припомню сайтов concerned with "масштабируемость и производительность" сделанных так. S>Это меня и беспокоит. Возиожно. это потому, что народ просто недотумкал. Многие простые идеи остаются невостребованными. Сколько ты знаешь сайтов, где сделан load on demand, как в дереве на RSDN? Единицы, верно?
Наверное потому что фреймы усложняют логическую структуру. Мы жертвуем простотой во имя перформанса. это не всегда оправдано.
M>>Я не expert, просто пытаюсь использовать "engineering common sense". S>спасибо. Вот и я тоже пытаюсь. С точки зрения ECS, это хороший способ. Пока мне неясно, по какой причине его не применяют.
еще один возможный минус — возможность посмотреть линк самого фрейма, и загрузить в браузере только его.
Прибавь к этому еще и обилие вложенных table/tr/td, поскольку других способов контролировать позиционирование еще не изобрели — и ты получишь то, что требовалось. M>Ну 100 байт на пункт меню. 100 * 100 = 10K.
M>А можно пример если не сложно.
Ну вот смотри:
1. Первое, что у меня было открыто в браузере. 23849 байт. Чистый текст без спецэффектов. при этом payload едва на килобайт.
2. http://www.ntv.ru. 52k.
3. Возьмем страничку поинтереснее. Amazon. 91к. Чистого текстового контента (середина) — 2k. Его размер в html — 19k. Итого примерно 70k на навигацию
Достаточно?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mogadanez, Вы писали:
M>Тут надо смотреть конкретные Use cases. M> — если страница информационная, то она перегружается не очень часто( загрузили, читаем, идем дальше ) — тут не совсем оправдано применение фреймов.
Ну как тебе сказать. Зато на эту страницу будут заходить миллионы пользователей. Грамотное использование фреймов должно максимально переложить нагрузку на прокси, а не на основной сервер. M> — если же предусмотрен интерактив с пользователем, где планируется ОЧЕНЬ много перегрузок в рамках одной страницы — то стоит подумать над оптимизацией( фреймы, callbacks...)
S>>Это меня и беспокоит. Возиожно. это потому, что народ просто недотумкал. Многие простые идеи остаются невостребованными. Сколько ты знаешь сайтов, где сделан load on demand, как в дереве на RSDN? Единицы, верно?
M>Наверное потому что фреймы усложняют логическую структуру.
Фреймы — да. ифреймы, по идее, выглядят и ведут себя также, как div. С точки зрения пользователя. M>Мы жертвуем простотой во имя перформанса. это не всегда оправдано.
"Мы" — это кто? Обычно жертвуют перформансом во имя простоты (разработки). Потому как сайтов с жесткой нагрузкой меньше одного процента от общего количества. Я лично вижу необходимость пожертвовать простотой разработки во имя перформанса. Удачные примеры таких жертований можно увидеть у гугла. M>еще один возможный минус — возможность посмотреть линк самого фрейма, и загрузить в браузере только его.
Это, во-первых, требует определенного шаманства, а во-вторых обходится на серверной стороне проверкой referrer.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, mbergal, Вы писали:
O>[... skipped ...]
M>>Глубоко прокопано!
M>>Это проверенно на IE? или еще на других browsers?
O>Это именно IE known bug. В остальных браузерах вроде всё ОК.
M>>Вообще то по идее замыкание образовываться не должно — function() { alert("Clicked!"); } не использует никаких переменных из create_div — но я давно ECMA standard читал уже деталей не упомню. Вообще надо бы разобраться и в FAQ.
O>Как раз замыкание тут и происходит...
O> Почитай, например, тут про замыкания в JavaScript.
Здравствуйте, Sinclair, Вы писали:
M>>Наверное потому что фреймы усложняют логическую структуру. S>Фреймы — да. ифреймы, по идее, выглядят и ведут себя также, как div. С точки зрения пользователя.
я про разработчиков, такая структура более сложная, хоть с фреймом хоть с Ифреймом
M>>Мы жертвуем простотой во имя перформанса. это не всегда оправдано. S>"Мы" — это кто? Обычно жертвуют перформансом во имя простоты (разработки). Потому как сайтов с жесткой нагрузкой меньше одного процента от общего количества. Я лично вижу необходимость пожертвовать простотой разработки во имя перформанса. Удачные примеры таких жертований можно увидеть у гугла.
"Мы" — в данном контексте образное понятие тех кто использует ифреймы.
M>>еще один возможный минус — возможность посмотреть линк самого фрейма, и загрузить в браузере только его. S>Это, во-первых, требует определенного шаманства, а во-вторых обходится на серверной стороне проверкой referrer.
Ну дык если писал, то должен знать, что в замыкание функции попадают все переменные, объявленные в том же scope до неё (пусть даже они и не используются в функции). Кстати, мог бы попробовать приведённый мной код в IE — в Task Manager чётко видно, как отжирается память в никуда (у меня по 1 МБ после каждого рефреша), даже если дать IE GC собрать мусор (свернуть его, например). А вот если закомментить "x.onclick = ...", то память не уходит в никуда...
O>>Кстати, IE memory leak with cyclic references это очень известная проблема...
M>А ссылку можно?
Здравствуйте, Sinclair, Вы писали:
S>Прибавь к этому еще и обилие вложенных table/tr/td, поскольку других способов контролировать позиционирование еще не изобрели — и ты получишь то, что требовалось.
ну это спорно... меню любой вложенности прекрасно делается из списков...
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, mbergal, Вы писали:
O>[... skipped ...]
O>Ну дык если писал, то должен знать, что в замыкание функции попадают все переменные, объявленные в том же scope до неё (пусть даже они и не используются в функции).
Вы правы, конечно должен был. Спасибо.
O>Кстати, мог бы попробовать приведённый мной код в IE — в Task Manager чётко видно, как отжирается память в никуда (у меня по 1 МБ после каждого рефреша), даже если дать IE GC собрать мусор (свернуть его, например). А вот если закомментить "x.onclick = ...", то память не уходит в никуда...
Здравствуйте, anonymous, Вы писали: A>ну это спорно... меню любой вложенности прекрасно делается из списков...
Ты это дизайнеру расскажи. Он тебе будет смеяться в лицо. Меню можно делать на списках только в том случае, если тебя не заботит его внешний вид.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mogadanez, Вы писали:
M>опять таки лишний код проверок и прочего..
Ну естественно. А как вы хотели? Сделать хороший сайт — не в поле выйти.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот смотри:
[...] S>3. Возьмем страничку поинтереснее. Amazon. 91к. Чистого текстового контента (середина) — 2k. Его размер в html — 19k. Итого примерно 70k на навигацию
Вполне, ситуация понятна — хотя числа у меня получились другие — поменьше (43k на стандартную навигацию ).
Здравствуйте, Sinclair, Вы писали:
A>>ну это спорно... меню любой вложенности прекрасно делается из списков... S>Ты это дизайнеру расскажи. Он тебе будет смеяться в лицо. Меню можно делать на списках только в том случае, если тебя не заботит его внешний вид.
передай этому дизайнеру, если он действительно так считает, чтоб шёл домашние странички верстать... ) ибо на большее он видимо не способен...
Здравствуйте, anonymous, Вы писали: A>передай этому дизайнеру, если он действительно так считает, чтоб шёл домашние странички верстать... ) ибо на большее он видимо не способен...
Ну, я может, конечно и неправ. И хорошо, если неправ. Вот только насколько все эти css изыски совместимы с браузерами?
На самом деле, скорее всего нам дадут странички в виде psd файлов. Дело дизайнера — нарисовать look. Обеспечить верстку в HTML вынуждены будем мы, для обеспечения собственно производительности.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, anonymous, Вы писали: A>>передай этому дизайнеру, если он действительно так считает, чтоб шёл домашние странички верстать... ) ибо на большее он видимо не способен... S>Ну, я может, конечно и неправ. И хорошо, если неправ. Вот только насколько все эти css изыски совместимы с браузерами?
кое-что, конечно, не будет совместимо с "динобраузерами" типа NS4.x или IE4.x, возможны проблемы с IE5.0, далее практически всё решаемо...
S>На самом деле, скорее всего нам дадут странички в виде psd файлов. Дело дизайнера — нарисовать look. Обеспечить верстку в HTML вынуждены будем мы, для обеспечения собственно производительности.
если воспользоваться таким подходом (т. е. "правильный" HTML + CSS), то размеры страничек можно уменьшить в разы...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Spidola, Вы писали: S>>Хм, мы поступили наоборот — выкинули в IFRAME-ы динамику. Т.е. вся навигация висит в главном окне, а кнутри него сидит IFrame такого вида: S>Это знакомая техника. Вижу с ней несколько неудобных проблем. S>>fr_load() подгружает соджержимое первой страницы внутрь iframe. Все изменения, которые могут происходить в главной странице (например, поменять отображение названия раздела или любые другие параметры вне фрэйма), делаются JavaScript-ом, приходящим внутри фрэйма. S>А как насчет прямых ссылок и соответствия между урлом в адрес баре и контента страницы? Вот на rsdn приходится иметь отдельную кнопку для обновления верхнего урла.
Верхний урл всегда один и тот же. Есди у вас требуется обеспечивать пользователю возможность прямых ссылок на конкретные страницы, то это проблематично. Для нас это плюс, поскольку во внутренний контур безопасности системы (другими словами, на любую страницу), можно попасть только после авторизации через конкретную страницу и организацию сессии на сервере...
S>>Вся навигация перенаправляется таргетами внутрь врэйма.
S>>Кстати, указанная технология хорошо подходит для закрытой системы (не публичной), поскольку сложнее подставлять под поисковики и делать полную печать страницы средствами браузера. Зато всё летает. S>Вот про эти проблемы хотелось бы поподробнее.
Если рассматривать замкнутую систему, в которую имеют доступ только определённый круг пользователей, то вход на любый внутренние страницы должен осуществляться через авторизацию. Поскольку при указанной технологии в браузере фактически открыта только одна страница, то дать внешнюю ссцлку кому-то проблематично. Поисковик сквозь авторизацию всё-равно не пройдёт, поэтому не проиндексирует внутренности сайта, а пользователь (даже поимев ссылку на страницу внутренего фрэйма), будет попадать на страницу авторизации.
Печать страницы делать сложнее, поскольку содержимое iframe печатается как видится, т.е. в окне с казанными размерами iframe-а. Что влезло, то напечаталось — остальное за кадром. Приходится делать специальную кнопку, которая бы открывала, к примеру, ещё одно окно и всё содержимое прорисовывала бы уже одним лопухом без внутреннего фрэйма...
Что касается скорости, то фактически нарисовав внешний "фрэймворк" в виде страницы и загрузив единожды туда всё, что можно, дальше в процессе работы пользователя грузятся только непосредственно необходимые данные и управляющие контролы.
Здравствуйте, Spidola, Вы писали: S>Верхний урл всегда один и тот же. Есди у вас требуется обеспечивать пользователю возможность прямых ссылок на конкретные страницы, то это проблематично.
Именно. Публичный сервис. S> Для нас это плюс, поскольку во внутренний контур безопасности системы (другими словами, на любую страницу), можно попасть только после авторизации через конкретную страницу и организацию сессии на сервере...
Это тоже косяк. Нормальные системы авторизации построены не на незнании прямого урла. При попытке им проследовать просто сначала предъявляется логин-форма, но потом юзер таки попадает в ту страницу, куда шел.
бы поподробнее.
S>Если рассматривать замкнутую систему, в которую имеют доступ только определённый круг пользователей, то вход на любый внутренние страницы должен осуществляться через авторизацию. Поскольку при указанной технологии в браузере фактически открыта только одна страница, то дать внешнюю ссцлку кому-то проблематично. ) См. выше. S>Поисковик сквозь авторизацию всё-равно не пройдёт, поэтому не проиндексирует внутренности сайта, а пользователь (даже поимев ссылку на страницу внутренего фрэйма), будет попадать на страницу авторизации.
У нас все наоборот. Надо не затруднять пользование сайтом, в том числе и индексацию и печать, а наоборот упрощать. S>Печать страницы делать сложнее, поскольку содержимое iframe печатается как видится, т.е. в окне с казанными размерами iframe-а. Что влезло, то напечаталось — остальное за кадром. Приходится делать специальную кнопку, которая бы открывала, к примеру, ещё одно окно и всё содержимое прорисовывала бы уже одним лопухом без внутреннего фрэйма...
S>Что касается скорости, то фактически нарисовав внешний "фрэймворк" в виде страницы и загрузив единожды туда всё, что можно, дальше в процессе работы пользователя грузятся только непосредственно необходимые данные и управляющие контролы.
Это-то то понятно. Я и пытаюсь вывернуть вашу схему наизнанку, чтобы сохранить преимущества скорости, избавившись от проблем с навигацией/индексацией/печатью.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Spidola, Вы писали: S>>Верхний урл всегда один и тот же. Есди у вас требуется обеспечивать пользователю возможность прямых ссылок на конкретные страницы, то это проблематично. S>Именно. Публичный сервис. S>> Для нас это плюс, поскольку во внутренний контур безопасности системы (другими словами, на любую страницу), можно попасть только после авторизации через конкретную страницу и организацию сессии на сервере... S>Это тоже косяк. Нормальные системы авторизации построены не на незнании прямого урла. При попытке им проследовать просто сначала предъявляется логин-форма, но потом юзер таки попадает в ту страницу, куда шел.
Так прямого урла никто не знает, во-первых, во-вторых заход через кривой урл в принципе невозможен, даже случайно, а в третьих все урлы кроме первого входного криптуются... Попадать на нужную страницу нет необходимости (опять таки в нашей системе), поскольку есть несколько бизнес-процессов, подразумевающих выполнение некоторого набора операций и и имеющие конкретную точку входа на процесс, привязанную к меню. Таким образом, человек по любомцу должен попадать сначала на авторизацию, потом на "распределитель".
Т.е. другими словами, информация в нашей системе не существует независимо от контекста её испрользования, поэтому переход сразу на конкретную страницу не предполагается.
С другой стороны, например, существует набор вебсервисов, которые позволяют выцепить такую информацию извне (например, какую-то конкретную картинку). Эти сервисы подразумевают передачу авторизационной информации непосредственно в ХML-запросе, к примеру. Это позволяет давать уже оторванную от контекста информацию наружу. Т.е. получается, что есть "защитный периметр" системы, который можно пересечь либо через форму авторизации, либо через механизм авторизации внутри вебсервиса, но в последнем случае внешняя система имеет доступ к ограниченному функционалу.
Ой, чего-то я увлёкся...
S>>Поисковик сквозь авторизацию всё-равно не пройдёт, поэтому не проиндексирует внутренности сайта, а пользователь (даже поимев ссылку на страницу внутренего фрэйма), будет попадать на страницу авторизации. S>У нас все наоборот. Надо не затруднять пользование сайтом, в том числе и индексацию и печать, а наоборот упрощать.
Ну раз задача обратная, то и технологию надо наизнанку выворачивать, отчего решение со статической, а не с динамической, информацией во фрэймах вполне подходит
S>>Печать страницы делать сложнее, поскольку содержимое iframe печатается как видится, т.е. в окне с казанными размерами iframe-а. Что влезло, то напечаталось — остальное за кадром. Приходится делать специальную кнопку, которая бы открывала, к примеру, ещё одно окно и всё содержимое прорисовывала бы уже одним лопухом без внутреннего фрэйма...
S>>Что касается скорости, то фактически нарисовав внешний "фрэймворк" в виде страницы и загрузив единожды туда всё, что можно, дальше в процессе работы пользователя грузятся только непосредственно необходимые данные и управляющие контролы. S>Это-то то понятно. Я и пытаюсь вывернуть вашу схему наизнанку, чтобы сохранить преимущества скорости, избавившись от проблем с навигацией/индексацией/печатью.
См.Выше
Ещё одно замечание насчёт использование фрэймов и т.п. Касается особенностей поисковых машин. То, что на странице и то, что фо фрэйме поисковиками будет рассматриваться как разные страницы, как минимум... И, желательно, перед использованием фрэймов почитать рекомендации тех поисковиков и каталогизаторов, которые вы предполагаете задействовать...
Здравствуйте, Sinclair, Вы писали:
S>Теперь, собственно, вопросы: S>- есть ли какие-либо контраргументы? (может быть, IFRAME плохо cross-browser compatible?) S>- есть ли опыт применения? S>- любые комментарии привествуются
такое замечание: iframe требуют много дополнительной памяти, поскольку фактически это отдельные полноценные браузеры...
а Питер тут причем 
* thriving in a production environment *
) См. выше.