Я предполагаю, что разработчики оптимизировали отрисовку и логика начала отрисовки достаточно сложна, однако проблема пересчета размеров остается достаточно острой т. к. даже изменение элемента на 1px может повлечь проход по всему DOMу документа.
Да, это собственно еще один способ, который применяю в том случае, когда мне нужно чтобы все объекты имели такой метод. Описанный мной способ подходит когда для конкретного объекта нужно сделать метод по каким-то соображениям логики. Но стоит задуматься о том, насколько хорошо использовать запись типа
Была у меня один раз задача проанализировать данные о 120 000 файлах и оценить, какой из подходов структурирования этой кучи будет оптимальней, для этого был написан js файл, в котором как раз и все делалось. Первая реализация повергла в шок: скрипт выполнялся более 40 минут и занял аж 2Гб памяти и до конца так и не дошел. После того как я его немного поменял он выполнился за 5 минут с использованием «всего» 100Мб памяти. Отличие в реализации было минимальное: Первый вариант
function File(...)
{
this.method = function(...)
{
... // использовались обращения только к this, никаких замыканий
}
}
Второй вариант
function File(...)
{
this.method = File_method;
}
function File_method(...)
{
...
}
На странице при выполнении анимации будет работать дополнительный уровень связи между скриптом и DOM элементами, а это дополнительные расходы ресурсов. Плюс к этому практически все браузеры бросаются перерисовывать окно (и пересчитывать размеры элементов) при изменении в DOM. Сильно снизило бы нагрузку очень простая вещь: перед массированным изменением DOMа вызывается метод, который блокировал бы перерисовку на время изменения, а потом вызывался бы другой метод, разрешающий перерисовку. Опять же пример из жизни: HTA копирует 7000 небольших файлов, если ничего не выводить в HTML, то процесс проходит за (примерно) 2 минуты, если просто выводить число скопированных файлов и аналог ProgressBar, то это уже 7 минут. Промежуточный вариант: данные о процессе обновляются каждые 5 секунд, и время работы получается 3 минуты.
Вывод: даже если язык и выглядит просто и незатейливо, но писать на нем все равно нужно с умом.
Есть немного другой механизм генерации кода по произвольному файлу в проекте — можно написать свой кодогенератор, который будет работать в Visual Studio. Отличия от описанного метода: работает только на этапе разработки, применяется для любых типов проектов (WinForms, DLL, ASP.NET), созданный файл кода лежит рядом с исходным и в проекте виден как пара по типу *.aspx + *.cs, можно положить в VSS или в SVN. Более детально можно почитать тут: rsdn.ru/article/devtools/vsnetcodegen.xml (статья старая, работу в 2008 студии не проверял).
Написать достаточно внятный визуальный редактор весьма непростая задача и, как показала практика, не оправдывает надежд и потраченного на него времени т.к. результаты порой приводят к тому, что на сайт без содрогания трудно смотреть.
Когда на сайте есть такой редактор, то предполагается, что пользователю будет проще писать текст и правильно его оформлять, однако уважаемые писатели ударяются в крайности: одни начинают заниматься дизайном текста (очень трепетно подходят к выбору размера, начертания, цвета шрифта и прочему выделению, совершенно не воспринимая общий стиль сайта), другие же делают просто Ctrl+C Ctrl+V из ворда и успокаиваются. Самое страшное, когда такой писатель начинает пробовать писать HTML, не предусмотренный многочисленными инструментами. Против таких начинающих «верстальщиков» нам пришлось в свое время сделать фильтр текста, который бы пропускал только то, что предусматривается инструментарием редактора.
Вообще редакторы, которые порождают HTML, в большинстве случаев для публикации материалов на сайте не нужны, а нужен редактор, который был бы компактным (небольшой объем скрипта), исключал самодеятельность в дизайне, обеспечивал бы (как минимум) похожесть текста при редактировании тому, что будет отображаться, но самое главное, что бы он помогал работать над текстом (в идеале совсем не беря в руки мышь). Большое количество тулбаров с инструментами не столько помогает, сколько мешает и подталкивает писателя заняться не текстом, а оформлением. Кстати, очень редко можно встретить грамотное дублирование инструментов горячими кнопками.
Близким к идеалу является редактор, основанный на разметке типа markdown (но без возможности вставить HTML) т.к. там весь текст виден (нет скрытой части в виде атрибутов тэгов), текст весьма похож на то, что потом будет отображаться после преобразования в HTML (конечно за исключением картинок). Сложность написания редактора для такого текста примерно сопоставима с написанием редактора на основе HTML, но результат использования намного лучше, да и товарищам, далеким от разработки, объяснять правила легче. Есть, конечно, еще и вики разметка, но она достаточно перегружена правилами.
И вообще, любой инструмент должен быть не «навороченным», а удобным. И удобным не для разработчика инструмента, а для пользователя.
Похожий подход я использую в своих проектах, отличие в том, что у меня в описании зависимости всего 2 уровня и этого достаточно т.к. результирующий список строится в несколько проходов, потом полученный скрипт пропускается через упаковщик скрипта, а затем упаковывается gzipом и помещается в кэш на сервере и затем отдается всем, кто желает получить такой же набор скриптов.
На практике сталкивался с тем, что для некоторых скриптов важен порядок помещения в единый файл скриптов, поэтому зависимости и порядок описываю отдельным файлом.
Так же оставил возможность простым переключением использовать скрипты классическим способом (например при отладке). Таким же образом обрабатываю и CSS файлы. Сейчас решаю вопрос с версионностью наборов скриптов. Если интересно, попробую найти время и описать поподробнее.
$.each(..., function(...){...});в часто вызываемом куске кода.
Первый вариант
function File(...) { this.method = function(...) { ... // использовались обращения только к this, никаких замыканий } }Второй вариант
function File(...) { this.method = File_method; } function File_method(...) { ... }На странице при выполнении анимации будет работать дополнительный уровень связи между скриптом и DOM элементами, а это дополнительные расходы ресурсов. Плюс к этому практически все браузеры бросаются перерисовывать окно (и пересчитывать размеры элементов) при изменении в DOM. Сильно снизило бы нагрузку очень простая вещь: перед массированным изменением DOMа вызывается метод, который блокировал бы перерисовку на время изменения, а потом вызывался бы другой метод, разрешающий перерисовку. Опять же пример из жизни: HTA копирует 7000 небольших файлов, если ничего не выводить в HTML, то процесс проходит за (примерно) 2 минуты, если просто выводить число скопированных файлов и аналог ProgressBar, то это уже 7 минут. Промежуточный вариант: данные о процессе обновляются каждые 5 секунд, и время работы получается 3 минуты.
Вывод: даже если язык и выглядит просто и незатейливо, но писать на нем все равно нужно с умом.
Когда на сайте есть такой редактор, то предполагается, что пользователю будет проще писать текст и правильно его оформлять, однако уважаемые писатели ударяются в крайности: одни начинают заниматься дизайном текста (очень трепетно подходят к выбору размера, начертания, цвета шрифта и прочему выделению, совершенно не воспринимая общий стиль сайта), другие же делают просто Ctrl+C Ctrl+V из ворда и успокаиваются. Самое страшное, когда такой писатель начинает пробовать писать HTML, не предусмотренный многочисленными инструментами. Против таких начинающих «верстальщиков» нам пришлось в свое время сделать фильтр текста, который бы пропускал только то, что предусматривается инструментарием редактора.
Вообще редакторы, которые порождают HTML, в большинстве случаев для публикации материалов на сайте не нужны, а нужен редактор, который был бы компактным (небольшой объем скрипта), исключал самодеятельность в дизайне, обеспечивал бы (как минимум) похожесть текста при редактировании тому, что будет отображаться, но самое главное, что бы он помогал работать над текстом (в идеале совсем не беря в руки мышь). Большое количество тулбаров с инструментами не столько помогает, сколько мешает и подталкивает писателя заняться не текстом, а оформлением. Кстати, очень редко можно встретить грамотное дублирование инструментов горячими кнопками.
Близким к идеалу является редактор, основанный на разметке типа markdown (но без возможности вставить HTML) т.к. там весь текст виден (нет скрытой части в виде атрибутов тэгов), текст весьма похож на то, что потом будет отображаться после преобразования в HTML (конечно за исключением картинок). Сложность написания редактора для такого текста примерно сопоставима с написанием редактора на основе HTML, но результат использования намного лучше, да и товарищам, далеким от разработки, объяснять правила легче. Есть, конечно, еще и вики разметка, но она достаточно перегружена правилами.
И вообще, любой инструмент должен быть не «навороченным», а удобным. И удобным не для разработчика инструмента, а для пользователя.
На практике сталкивался с тем, что для некоторых скриптов важен порядок помещения в единый файл скриптов, поэтому зависимости и порядок описываю отдельным файлом.
Так же оставил возможность простым переключением использовать скрипты классическим способом (например при отладке). Таким же образом обрабатываю и CSS файлы. Сейчас решаю вопрос с версионностью наборов скриптов. Если интересно, попробую найти время и описать поподробнее.