«переименовала foto.pdf в фото.jpg. Тем самым она обошла mime-type check»
Таким образом проверка mime-type не обходится. Таким образом обходится проверка на расширение файла. Методы для получения mime-type не должены зависеть от расширения и / или заголовка «Content-Type» http-запроса.
Гм, в NetBeans эта проблема решается добавлением "-J-Dawt.useSystemAAFontSettings=on". Для Swing тоже должен быть подобный параметр, по крайне мере на форуме VP Suite я его видел.
Тут есть один момент, сдвиг не будет работать при определении констант класса. Поэтому я везде пользуюсь шестнадцатиричным определением констант, которые могут применяться в битовых операциях.
Сейчас у меня в приложениях в принципе всего одна точка входа, index.html, ибо занимаюсь в основном RIA. Но такой подход актуален и для CMS, в которых используется шаблонизация, подключение скриптов выносится в шаблон header, и не меняется для всех страниц. Конечно, рецепт не универсальный, но с точки зрения производительности проще собрать все скрипты и css в два файла, не резделяя их на группы для разных страниц, так будет меньше запросов к серверу и у пользователя в кэше сразу будет весь необходимый код. Разделять скрипты на группы я бы стал после разницы в объеме между группами в 100 Кб, например. Отдельный случай — админка CMS, ее нужно рассматривать как вторую точку входа с аналогичным подходом.
Зря, я не увидел в вашем методе удаления из javascript и css комментариев, прочих символов типа перевода строки и пробелов, замены имен переменных и функций в javascript на более короткие и т.д, а ведь они тоже дают солидную экономию в весе. А еще у вас используется нерациональная степень сжатия в gzip — 9, а ведь широко известно, что больше 5 ставить нет смысла. Можете посмотреть в комментариях к функциям: gzencode, gzcompress (тут кроме степени сжатия еще и время).
Я подключаю к файлу index.html один файл frontend.js и один style.css, внутри эти файлы, в зависимости от типа сборки, содержат или подключение остальных файлов или полностью сжатый с помощью google closure compiler и yui compressor код. А уже сервер занимается сжатием в gzip. Сжатие — это единственное, что стоит производить на уровне php, если нет доступа к сжатию с помощью самого сервера.
По поводу изменения версии с dev на product — с помощью билд-скрипта это делается намного удобнее, особенно если назначить целям для сборки каждой версии горячие клавиши.
Сейчас занимаюсь внедрением Ivy в систему сборки проектов. По этому поводу несколько комментариев:
1. С помощью неймспейса подключить Ivy не удалось, так как нельзя гарантировать его наличие в папке библиотек Ant на разных операционках. Сделал загрузку Ivy из репозитория в папку с зависимостями проекта и подключение с помощью taskdef.
2. Для управления наборами зависимостей для разных вариантов сборки проекта служит раздел configurations в ivy.xml, попробуйте описать в нем все варианты сборки, может плагин перестанет путать зависимости. На русском немного об этом я нашел тут
Ну вот я обычно ставлю софт с помощью aptitude, а не вытягивая исходники из репозитория проекта. Зачем мне отслеживать / форкать его на гитхабе? Объективный показатель — кол-во проектов, которые работают с помощью технологии, причем полноценных, а не хелло-ворд чатов.
Учитывая, что схема MVC разрабатывалась именно для GUI приложений, то нужно :) Тем более, что ExtJS позволяет абстрагироваться от сервера, HTML (если не нужно писать кастомные view) и, в какой-то степени, от JavaScript, предоставляя неплохой инструментарий из методов ядра и системы классов.
1. Это входит в формулировку архитектурной схемы MVC: Model in MVC pattern. Бизнес-логика в контроллере считается основной ошибкой при использовании MVC: Fat Stupid Ugly Controllers. Если следовать схеме MVC до конца, то я могу ошибаться, ведь если методы toggleHelp и menuRendered изменяют не состояние модели, а представление, то грамотнее расположить их именно в нем.
2. Разумеется, просто в случае моего приложения ошибку проще было исправить на самом низком уровне, так как объекты я использую практически во всех запросах, в том числе и совершенных с помощью Ext.Ajax.
А почему у вас методы toggleHelp и menuRendered находятся в контроллере, если при архитектуре MVC они должны находиться в модели?
По поводу AJAX: на мой взгляд, проблема не в «в ExtJS4 отсутствует простой случай Writer'а, который отправляет объект как множество HTTP параметров «ключ-значение»», а в том, что в классе Ext.data.Connection в методе setOptions метод Ext.Object.toQueryString() употребляется без флага, который разрешает рекурсивное преобразование. Собственно перегрузкой этого класса я и решил проблему с объектами в запросе.
Если использовать в параметре к down нормальный селектор, а не "#id", то не придется. В этом как раз и главное отличие down от get. Естественно, это не касается ситуаций, когда вы меняете Grid на Form, например, и ищете по xtype. Хотя можно оборачивать наследника в панель с определенным xtype.
Не обязательно тянуть со всеми потрохами. Я случайно обнаружил следующую возможность Ext:
/**
* Класс аналогичен классу Ext.data.proxy.Ajax
* за исключением того, что все запросы этого класса
* выполняются с помощью POST
*/
Ext.define('Ext.data.proxy.Ajax',
{
extend: 'Ext.data.proxy.Ajax',
alias: 'proxy.ajax',
actionMethods:
{
create : 'POST',
read : 'POST',
update : 'POST',
destroy: 'POST'
}
});
Таким образом на класс можно наложить требуемый патч. Очень помогает в борьбе с глюками ExtJS.
Конечно же нужен. Первой мыслью после чтения документации на php.net было «блин, если понадобится использовать в проекте, то придется писать ОО-обертку». Хороший пример сочетания объектно-ориентированного и процедурного API — расширение mysqli, например.
DoS и DDoS это разные вещи. DoS-атакой может являться запуск любой ресурсоемкой операции злоумышленником (запрос картинки в 100500х100500 пикселей там, где она генерируется автоматически скриптом, специально сформированный запрос, который вызовет чтение большого кол-ва строк из БД и т.п.). От атак этого типа можно защититься с помощью проверки данных, полученных от пользователя, на попадание в допустимый диапазон. Естественно, такая проверка должна проводиться кодом, который обладает знаниями об это диапазоне.
Таким образом проверка mime-type не обходится. Таким образом обходится проверка на расширение файла. Методы для получения mime-type не должены зависеть от расширения и / или заголовка «Content-Type» http-запроса.
Я подключаю к файлу index.html один файл frontend.js и один style.css, внутри эти файлы, в зависимости от типа сборки, содержат или подключение остальных файлов или полностью сжатый с помощью google closure compiler и yui compressor код. А уже сервер занимается сжатием в gzip. Сжатие — это единственное, что стоит производить на уровне php, если нет доступа к сжатию с помощью самого сервера.
По поводу изменения версии с dev на product — с помощью билд-скрипта это делается намного удобнее, особенно если назначить целям для сборки каждой версии горячие клавиши.
1. С помощью неймспейса подключить Ivy не удалось, так как нельзя гарантировать его наличие в папке библиотек Ant на разных операционках. Сделал загрузку Ivy из репозитория в папку с зависимостями проекта и подключение с помощью taskdef.
2. Для управления наборами зависимостей для разных вариантов сборки проекта служит раздел configurations в ivy.xml, попробуйте описать в нем все варианты сборки, может плагин перестанет путать зависимости. На русском немного об этом я нашел тут
2. Разумеется, просто в случае моего приложения ошибку проще было исправить на самом низком уровне, так как объекты я использую практически во всех запросах, в том числе и совершенных с помощью Ext.Ajax.
По поводу AJAX: на мой взгляд, проблема не в «в ExtJS4 отсутствует простой случай Writer'а, который отправляет объект как множество HTTP параметров «ключ-значение»», а в том, что в классе Ext.data.Connection в методе setOptions метод Ext.Object.toQueryString() употребляется без флага, который разрешает рекурсивное преобразование. Собственно перегрузкой этого класса я и решил проблему с объектами в запросе.