s0rr0w

Главное в этом деле - вывернуть наизнанку свое мышление, чтобы не скатываться постоянно к стандартному мышлению. Например, подгрузка постраничных данных может выглядеть вот так: 1 шаг <pager_top/> <data_container/> <pager_bottom/> <script> load data </sctript> 2 шаг <data/> <script> pager init </script> Т.е. данные приходят порционно. Не трудно догадаться, что первый шаг это банальный пейджер, второй - данные на одну страницу, которые рассказывают пейджеру, к какой именно странице это относится.

Возьмите готовый скрипт рисования диаграм и не насилуйте нам мозг.

Нашел проблему.. Ставь "Сисофт Сандру" и узнавай все про свое железо.

Читаем что такое логика. Я что-то не вижу предложения, что логика является частью математики...

Думаешь кому-то интересна твоя задача? Я на объем кода посмотрел и мне стало сразу лень в нем ковыряться.

Какое же это усложнение? Весь сайт может собираться тремя функциями!!! Я написал API системы еще два года назад. Только сейчас переписал, но чисто из-за спортивного интереса. Вернее увидел небольшое упрощение, воспользовался. С тех пор дописал всего ОДНУ функцию и добавил один патч. Все. Пишите универсальные вещи, не придется постоянно доделывать. Скрипты можно присылать даже не в CDATA, а как значение ноды, и выполнять их после вставки в основной документ. Это заблуждение. Программировать в разы проще и быстрее. И багов на порядок меньше. Система, которую мы разрабатываем, без проблем работает более двух лет. Построена как раз на данном принципе. Удовольствие от работы огромное. После своей системы мне gmail кажется убогой неудобной поделкой.

Неверно тебе думается. А из папки WINDOWS его тяжело выковырять?

Оперативка сейчас стоит копейки. Жалко добавить?

Аналитическое мышление требует умения логически мыслить и управления абстракциями. Что из этого воспитывается математикой?

Будет обрезано, если у блока заданы фиксированные размеры. В противном случае вступает в силу другой алгоритм.

Симплекс-метод экономисты тоже учат На прикладной математике тебя не научат программировать.

А вырвать его из потока, вставив вместо него заглушку в виде span'на с размерами, идентичными селекту до отрыва?

Усложнение там мизерное. Да и любую задачу можно решить разными способами. Если создать прецендент, то поисковики изменят свое отношение к таким сайтам. Где там больше работы? Больше работы со страницей, на которой нужно показывать несколько модулей. Вот там точно можно запутаться. Приведу простой пример. Есть набор базовых функций, например * получить меню * получить список новостей * получить список статей * получить текст новости * получить текст статьи * получить календарь с указанием заполненности Как видим, все можно свести к трем базовым типам: список(дерево), статья, календарь. Пишем три базисные функции, которые принимают параметры, а в ответ генерируют HTML. В зависимости от темплейта или типа данных, генерируется разный код. Итак, у нас есть три функции, один index.cgi, несколько темплейтов для разных типов данных. Что тут сложного? Зачем? Я три раза написал, что можно спокойно HTML пересылать. Данные можно гонять в виде JS. Меньше по размерам, правда на генерацию чуть больше времени будет затрачено.

а поменять ему size не катит?

Оптимизационные задачи - это чистой воды математика. Любую оптимизационную задачу можно свести к набору уравнений, а поиск оптимума делается примитивнейшим способом - симплекс-методом. Графическая интерпретация симплекс-метода - движение по граням n-мерной фигуры, которая описывается набором уравнений задачи. Насчет того, из кого получаются лучшие программисты... Из тех людей, кто может работать с абстракциями различного уровня.

Вопрос не про то, есть флешблок или нет, а в том, что установлен флеш или нет.

В постановке вопроса.

Таких людей можно заносить в красную книгу.

В HTML нет символов табуляции. А задачу так и не понял.

Перенес тему в соответствующий раздел

Ну а головой подумать? Вот вам код <div class="defContent"> <a href="#" onclick="doRequest('news'); return false;">Новости</a> </div> <div class="forPortable"> <a href="/news/">Новости</a> </div> .forPortable { display: none } @media handheld { .defContent { display: none } .forPortable { display: block } } Таким образом можно разложить весь сайт на набор маленьких страниц с нормальными ссылками. Маленькие кусочки можно тоже кешировать как и цельные страницы. Разницы - ноль. Интерпретатор не нужен, если передавать готовый HTML. По поводу форума. Переход на уже загруженные страницы не будет требовать запроса на сервер. Выгода очевидна.

Молодец

Лишний код? Давай сравним две технологии генерации страницы данных. Статическая страница 1. Запросить данные для меню. 2. Запросить данные всех модулей, которые отображаются на странице помимо контента 3. Запросить данные контента 4. Отобразить все это. Динамическая подгрузка 1. Запросить данные для контента 2. Отобразить. Скриптов там одинаково немного, если строить все правильно идеологически.

Научитесь доверять людям.

Речь идет про библиотеку, и там действительно используется iframe. Обоснуй, почему не рационально?