Перед созданием модуля я изучал код Smarty. Так вот, по сравнению со Smarty класс просто «пушинка» :).
Пока что, к сожалению, я не нашел времени на написание тестов.
Большое количество файлов не единственный минус такого подхода, есть еще проблемы с обновленной версией блока. На хабре они решаються вот так xmlhandler.js? revision=12. Некоторые браузеры (Opera, Internet Explorer 6+, Safari) НЕ кешируют документы, если в адресе есть вопросительный знак, т.к считают их динамическими.
Видимо мое упущение в том что я не расписал «в деталях» принцип работы моего скрипта.
Я сторонник того, чтоб все скрипты необходимые в работе сайта, находились в одном файле в упакованом виде. Он не генерится каждый раз для каждой страницы. Он пересобирается в случае внесения изминений в какой-либо класс для всех страниц и находится в кеше пока не будет новых изминений.
Если не учитывать swfupload*, то все js-файлы Хабра можно было спаковать (я думаю) в 50-60 кб один архив и ставить его на каждую станичку без '?' вместо 200-250 как сейчас.
Но я не говорю что у Хабра сделано плохо. У любого метода есть свои плюсы и свои минусы.
Я ориентироваля на решение проблемы оптимизация или ускорение процесса коммандной разработки.
Так и задумано. Пересборка такого большого файла заняла бы лишние ресурсы. У меня, например, этот файл грузится с одного url для всех проектов. Некоторые его грузят через google.load;
Цена за такую неоптимальность не очень большая, зато убирается много проблем.
Кроме того, я специально оставил MooTools незакомпресированным. Чтоб можно было смотреть в код фреймворка в процессе разработки, когда возникают ошибки. На продакшин сервере я использую mootools-1.2-core-yc.js
По поводу обязательности использования фреймворков я уже отвечал.
А JsClasses создает два файла js/cache/<tmp_имя>.js и js/cache/<tmp_имя>.js.gz.
Второй файл отдается внутренним редиректом если в header-е http-запроса есть строка «Accept-Encoding: gzip, deflate». Т.е. запрашивается всегда первый файл а отдаваться он может в «сжатом» виде, в случае, если браузер такой вариант отдачи понимает.
Почему кто-то должен решать имею я право выразить свою точку зрения или нет, даже если она отличается от вашей.
Когда Штаты напали на Ирак, в стране были и другие взгляды, которые широко освещались в СМИ и никто никого не DOS-ил.
Захотелось человеку "отбить" затраты на приобретение книги за счет хабралюдей, лавочку открыл, таксу назначил. Некрасиво.
Тут многие люди тратят дни, недели своего драгоценного времени чтоб написать что-то полезное для хабра-людей и без всяких там барышей поделиться с ближним.
Что касается раздачи чужого творения "на шару", мол, намного хуже, с этим не согласен!
Когда человек выложил чужой труд в общий доступ, он поступил неправильно. Но ведь это Ваше решение качать краденное или нет. Автор написал как к нему попала книга, и из статьи ясно, что действия по распостранению книги являются незаконными.
Какая разница берет он плату за это или нет, если кто-то купил или "на шару" скачал книгу он тоже причастен к воровству.
Вариант с деньгами усугубляет ситуацию тем, что автор раздает "корысти ради", а не от "любви к искуству"! Как по мне, так это намного хуже!
И почему вы решили что та тысяча, которая стянет книгу, потенциальные покупатели. Я, лично, в этом сильно сомневаюсь.
Вначале писал статью о своей реализации дерева, и понял что без небольшого обзора других модулей статья будет менее полезна читателям habra.
Т.к. модулей на mootools не так уж и много, включил в обзор другие фреймворки.
Я согласен, что многие критерии оченки качества дерева в обзоре не описаны и тесты на ресуркоемкость и производительность тоже нужны.
Раз я уже взялся за это дело, напишу тесты, добавлю оценку по поддежке клавиш управления, динамической загрузке нодов, DnD, checkboxes, custom nodes и опубликую вторую (расширенную) часть обзора и назову ее "Обзор DHTML-деревьев на JavaScript".
У Linux конкурируют разные дистрибутивы, разные графические оболочки, разные файловые системы, http-демонов есть более 10 разновидностей. Почтовых систем несколько, SQL-серверов несколько и т.д.
Пока что, к сожалению, я не нашел времени на написание тестов.
На production-сервере можно проверки отрубить
и после каждого апдейта запускать модуль отдельно в режиме «чистки» кеша, с помощью «спецключа» к запуску сайта:
Тогда в коде ничего менять не прийдется. И нагдузка будет еще меньше.
Сам класс хорошо документирован, вы можете его можете наследовать в своем классе и доработать до того вида который нужен Вам.
Видимо мое упущение в том что я не расписал «в деталях» принцип работы моего скрипта.
Я сторонник того, чтоб все скрипты необходимые в работе сайта, находились в одном файле в упакованом виде. Он не генерится каждый раз для каждой страницы. Он пересобирается в случае внесения изминений в какой-либо класс для всех страниц и находится в кеше пока не будет новых изминений.
Если не учитывать swfupload*, то все js-файлы Хабра можно было спаковать (я думаю) в 50-60 кб один архив и ставить его на каждую станичку без '?' вместо 200-250 как сейчас.
Но я не говорю что у Хабра сделано плохо. У любого метода есть свои плюсы и свои минусы.
Я ориентироваля на решение проблемы оптимизация или ускорение процесса коммандной разработки.
Цена за такую неоптимальность не очень большая, зато убирается много проблем.
Кроме того, я специально оставил MooTools незакомпресированным. Чтоб можно было смотреть в код фреймворка в процессе разработки, когда возникают ошибки. На продакшин сервере я использую mootools-1.2-core-yc.js
Ошибку поравил, спасибо.
А JsClasses создает два файла js/cache/<tmp_имя>.js и js/cache/<tmp_имя>.js.gz.
Второй файл отдается внутренним редиректом если в header-е http-запроса есть строка «Accept-Encoding: gzip, deflate». Т.е. запрашивается всегда первый файл а отдаваться он может в «сжатом» виде, в случае, если браузер такой вариант отдачи понимает.
Но на мой взгляд это все же снижает скорость разработки.
Только я бы поставил статью в рубрику «Я пиарюсь».
Когда Штаты напали на Ирак, в стране были и другие взгляды, которые широко освещались в СМИ и никто никого не DOS-ил.
Тут многие люди тратят дни, недели своего драгоценного времени чтоб написать что-то полезное для хабра-людей и без всяких там барышей поделиться с ближним.
Что касается раздачи чужого творения "на шару", мол, намного хуже, с этим не согласен!
Когда человек выложил чужой труд в общий доступ, он поступил неправильно. Но ведь это Ваше решение качать краденное или нет. Автор написал как к нему попала книга, и из статьи ясно, что действия по распостранению книги являются незаконными.
Какая разница берет он плату за это или нет, если кто-то купил или "на шару" скачал книгу он тоже причастен к воровству.
Вариант с деньгами усугубляет ситуацию тем, что автор раздает "корысти ради", а не от "любви к искуству"! Как по мне, так это намного хуже!
И почему вы решили что та тысяча, которая стянет книгу, потенциальные покупатели. Я, лично, в этом сильно сомневаюсь.
Т.к. модулей на mootools не так уж и много, включил в обзор другие фреймворки.
Я согласен, что многие критерии оченки качества дерева в обзоре не описаны и тесты на ресуркоемкость и производительность тоже нужны.
Раз я уже взялся за это дело, напишу тесты, добавлю оценку по поддежке клавиш управления, динамической загрузке нодов, DnD, checkboxes, custom nodes и опубликую вторую (расширенную) часть обзора и назову ее "Обзор DHTML-деревьев на JavaScript".