Здравствуйте, mbergal, Вы писали:
M>А что такое тяжеловесная статическая навигация. и почему она тяжеловесная..
А потому, что там куча всяких стандартных формочек, менюшечка с полусотней линков. Конечно же, она будет графическая. И конечно же, там будут ролловеры. А каждый ролловер — это лишние байты для биндинга обработчиков. В общем, типичный "красивый" сайт — это странички по 50-80k без учета графики.
M>К тому же если посмотреть на prior art, то что-то не припомню сайтов concerned with "масштабируемость и производительность" сделанных так.
Это меня и беспокоит. Возиожно. это потому, что народ просто недотумкал. Многие простые идеи остаются невостребованными. Сколько ты знаешь сайтов, где сделан load on demand, как в дереве на RSDN? Единицы, верно?
M>Я не expert, просто пытаюсь использовать "engineering common sense".
спасибо. Вот и я тоже пытаюсь. С точки зрения ECS, это хороший способ. Пока мне неясно, по какой причине его не применяют.

Здравствуйте, Spidola, Вы писали:
S>Хм, мы поступили наоборот — выкинули в IFRAME-ы динамику. Т.е. вся навигация висит в главном окне, а кнутри него сидит IFrame такого вида:
Это знакомая техника. Вижу с ней несколько неудобных проблем.
S>fr_load() подгружает соджержимое первой страницы внутрь iframe. Все изменения, которые могут происходить в главной странице (например, поменять отображение названия раздела или любые другие параметры вне фрэйма), делаются JavaScript-ом, приходящим внутри фрэйма.
А как насчет прямых ссылок и соответствия между урлом в адрес баре и контента страницы? Вот на rsdn приходится иметь отдельную кнопку для обновления верхнего урла.
S>Вся навигация перенаправляется таргетами внутрь врэйма.

S>Кстати, указанная технология хорошо подходит для закрытой системы (не публичной), поскольку сложнее подставлять под поисковики и делать полную печать страницы средствами браузера. Зато всё летает.
Вот про эти проблемы хотелось бы поподробнее.

Здравствуйте, mbergal, Вы писали:

[... skipped ...]

M>Глубоко прокопано!

M>Это проверенно на IE? или еще на других browsers?

Это именно IE known bug. В остальных браузерах вроде всё ОК.

M>Вообще то по идее замыкание образовываться не должно — function() { alert("Clicked!"); } не использует никаких переменных из create_div — но я давно ECMA standard читал уже деталей не упомню. Вообще надо бы разобраться и в FAQ.

Как раз замыкание тут и происходит... Почитай, например, тут про замыкания в JavaScript.

Кстати, IE memory leak with cyclic references это очень известная проблема...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mbergal, Вы писали:
M>>А что такое тяжеловесная статическая навигация. и почему она тяжеловесная..
S>А потому, что там куча всяких стандартных формочек, менюшечка с полусотней линков. Конечно же, она будет графическая. И конечно же, там будут ролловеры. А каждый ролловер — это лишние байты для биндинга обработчиков. В общем, типичный "красивый" сайт — это странички по 50-80k

Все равно не понимаю откуда 50-80К:

<div ...>
    <img class="menu_item" src="djfkdshkfhsdkhskdghksfgh/a.gif"/>
</div>

Ну 100 байт на пункт меню. 100 * 100 = 10K.

А можно пример если не сложно.

Здравствуйте, 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, это хороший способ. Пока мне неясно, по какой причине его не применяют.

еще один возможный минус — возможность посмотреть линк самого фрейма, и загрузить в браузере только его.

Здравствуйте, mbergal, Вы писали:
M>Все равно не понимаю откуда 50-80К:
M>

M><div ...>
M>    <img id=2 class="menu_item" src="djfkdshkfhsdkhskdghksfgh/a.gif" onmouseover="switch_picture(2, '/images/item2over.gif'" onmouseout="switch_picture(2, '/images/item2.gif'">
M></div>
M>

Прибавь к этому еще и обилие вложенных 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 на навигацию
Достаточно?

Здравствуйте, mogadanez, Вы писали:

M>Тут надо смотреть конкретные Use cases.
M> — если страница информационная, то она перегружается не очень часто( загрузили, читаем, идем дальше ) — тут не совсем оправдано применение фреймов.
Ну как тебе сказать. Зато на эту страницу будут заходить миллионы пользователей. Грамотное использование фреймов должно максимально переложить нагрузку на прокси, а не на основной сервер.
M> — если же предусмотрен интерактив с пользователем, где планируется ОЧЕНЬ много перегрузок в рамках одной страницы — то стоит подумать над оптимизацией( фреймы, callbacks...)

S>>Это меня и беспокоит. Возиожно. это потому, что народ просто недотумкал. Многие простые идеи остаются невостребованными. Сколько ты знаешь сайтов, где сделан load on demand, как в дереве на RSDN? Единицы, верно?

M>Наверное потому что фреймы усложняют логическую структуру.
Фреймы — да. ифреймы, по идее, выглядят и ведут себя также, как div. С точки зрения пользователя.
M>Мы жертвуем простотой во имя перформанса. это не всегда оправдано.
"Мы" — это кто? Обычно жертвуют перформансом во имя простоты (разработки). Потому как сайтов с жесткой нагрузкой меньше одного процента от общего количества. Я лично вижу необходимость пожертвовать простотой разработки во имя перформанса. Удачные примеры таких жертований можно увидеть у гугла.
M>еще один возможный минус — возможность посмотреть линк самого фрейма, и загрузить в браузере только его.
Это, во-первых, требует определенного шаманства, а во-вторых обходится на серверной стороне проверкой referrer.

Здравствуйте, 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.

Да я читал Standard ECMA-262: ECMAScript Language Specification 3rd edition (December 1999) и Douglas Crockford. А это даже когда-то сам писал.

O>Кстати, IE memory leak with cyclic references это очень известная проблема...

А ссылку можно?

Здравствуйте, Sinclair, Вы писали:

M>>Наверное потому что фреймы усложняют логическую структуру.
S>Фреймы — да. ифреймы, по идее, выглядят и ведут себя также, как div. С точки зрения пользователя.

я про разработчиков, такая структура более сложная, хоть с фреймом хоть с Ифреймом

M>>Мы жертвуем простотой во имя перформанса. это не всегда оправдано.
S>"Мы" — это кто? Обычно жертвуют перформансом во имя простоты (разработки). Потому как сайтов с жесткой нагрузкой меньше одного процента от общего количества. Я лично вижу необходимость пожертвовать простотой разработки во имя перформанса. Удачные примеры таких жертований можно увидеть у гугла.

"Мы" — в данном контексте образное понятие тех кто использует ифреймы.

M>>еще один возможный минус — возможность посмотреть линк самого фрейма, и загрузить в браузере только его.
S>Это, во-первых, требует определенного шаманства, а во-вторых обходится на серверной стороне проверкой referrer.

опять таки лишний код проверок и прочего..

Здравствуйте, mbergal, Вы писали:

[... skipped ...]

O>>Как раз замыкание тут и происходит...

O>> Почитай, например, тут про замыкания в JavaScript.

M>Да я читал Standard ECMA-262: ECMAScript Language Specification 3rd edition (December 1999) и Douglas Crockford. А это даже когда-то сам писал.

Ну дык если писал, то должен знать, что в замыкание функции попадают все переменные, объявленные в том же scope до неё (пусть даже они и не используются в функции). Кстати, мог бы попробовать приведённый мной код в IE — в Task Manager чётко видно, как отжирается память в никуда (у меня по 1 МБ после каждого рефреша), даже если дать IE GC собрать мусор (свернуть его, например). А вот если закомментить "x.onclick = ...", то память не уходит в никуда...

O>>Кстати, IE memory leak with cyclic references это очень известная проблема...

M>А ссылку можно?

http://support.microsoft.com/default.aspx?scid=kb;en-us;830555

http://www.bazon.net/mishoo/articles.epl?art_id=824

http://jibbering.com/faq/faq_notes/closures.html#clMem

Здравствуйте, Sinclair, Вы писали:

S>Прибавь к этому еще и обилие вложенных table/tr/td, поскольку других способов контролировать позиционирование еще не изобрели — и ты получишь то, что требовалось.

ну это спорно... меню любой вложенности прекрасно делается из списков...

Здравствуйте, Oyster, Вы писали:

O>Здравствуйте, mbergal, Вы писали:

O>[... skipped ...]

O>Ну дык если писал, то должен знать, что в замыкание функции попадают все переменные, объявленные в том же scope до неё (пусть даже они и не используются в функции).

Вы правы, конечно должен был. Спасибо.

O>Кстати, мог бы попробовать приведённый мной код в IE — в Task Manager чётко видно, как отжирается память в никуда (у меня по 1 МБ после каждого рефреша), даже если дать IE GC собрать мусор (свернуть его, например). А вот если закомментить "x.onclick = ...", то память не уходит в никуда...

Да я не сомневался.

O>>>Кстати, IE memory leak with cyclic references это очень известная проблема...
O>http://jibbering.com/faq/faq_notes/closures.html#clMem

Классно, то что надо

Здравствуйте, anonymous, Вы писали:
A>ну это спорно... меню любой вложенности прекрасно делается из списков...
Ты это дизайнеру расскажи. Он тебе будет смеяться в лицо. Меню можно делать на списках только в том случае, если тебя не заботит его внешний вид.

Здравствуйте, mogadanez, Вы писали:

M>опять таки лишний код проверок и прочего..
Ну естественно. А как вы хотели? Сделать хороший сайт — не в поле выйти.

Здравствуйте, Sinclair, Вы писали:

S>Ну вот смотри:
[...]
S>3. Возьмем страничку поинтереснее. Amazon. 91к. Чистого текстового контента (середина) — 2k. Его размер в html — 19k. Итого примерно 70k на навигацию

Вполне, ситуация понятна — хотя числа у меня получились другие — поменьше (43k на стандартную навигацию ).

Здравствуйте, Sinclair, Вы писали:

A>>ну это спорно... меню любой вложенности прекрасно делается из списков...
S>Ты это дизайнеру расскажи. Он тебе будет смеяться в лицо. Меню можно делать на списках только в том случае, если тебя не заботит его внешний вид.

передай этому дизайнеру, если он действительно так считает, чтоб шёл домашние странички верстать... ) ибо на большее он видимо не способен...

и еще вот эти ссылки, пусть займется самообразованием:
http://webmascon.com/topics/coding/36a.asp
http://webmascon.com/topics/coding/37a.asp
http://css.maxdesign.com.au/listamatic/
http://css.maxdesign.com.au/listamatic2/

Здравствуйте, anonymous, Вы писали:
A>передай этому дизайнеру, если он действительно так считает, чтоб шёл домашние странички верстать... ) ибо на большее он видимо не способен...
Ну, я может, конечно и неправ. И хорошо, если неправ. Вот только насколько все эти css изыски совместимы с браузерами?
На самом деле, скорее всего нам дадут странички в виде psd файлов. Дело дизайнера — нарисовать look. Обеспечить верстку в HTML вынуждены будем мы, для обеспечения собственно производительности.

Здравствуйте, 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>Что касается скорости, то фактически нарисовав внешний "фрэймворк" в виде страницы и загрузив единожды туда всё, что можно, дальше в процессе работы пользователя грузятся только непосредственно необходимые данные и управляющие контролы.
Это-то то понятно. Я и пытаюсь вывернуть вашу схему наизнанку, чтобы сохранить преимущества скорости, избавившись от проблем с навигацией/индексацией/печатью.