К сожалению, тут много сложностей: App - это singleton и инициализируется в произвольном месте кода по первому вызову статической функции get(). В конструкторе App не только объект Loader, а еще может быть неопределенное количество объектов других классов - передавать их через параметры не очень удобно. Еще один из частных случаев - когда в конструкторе App описана инициализация autoload, после чего вызывается какой-нибудь $this->cat = new Cat(); Так вот чтобы передать Кота через параметры нужно будет подключать его вручную..
Ну да, это практически равносильно моему 1му варианту - кусок кода где идет непосредственное обращение к классу Loader вынести в отдельный переопределяемый метод. Но я думал быть может есть какие-то методы манипуляции с NS, которые бы позволили решить эту задачу. Ведь static/self же есть, неужели нельзя никак по-простому обратиться к NS вызывающего класса, а не того, где определен метод..
А, вы про new Image.onload, я вас неправильно понял сначала. Через Image можно отследить только окончание загрузки, процент загрузки не покажет. Но тут вот грузили через ajax - blogs.adobe.com/webplatform/2012/01/13/html5-image... - можно так попробовать.
Касательно клиентской части: что jQuery File Upload, что FileAPI, что любое другое решение обычно использует одно и тоже и различается лишь поддержкой "неправильных" браузеров и набором фич. Если вам не столь принципиальна кроссбраузерность - то просто берите то, в чьем мануале проще разобраться.
Да, это клиентские решения, хотя у этих проектов на githubе есть куски сервероного кода - для начала можете воспользоваться ими.
Боюсь я не смогу в двух словах описать как встроить загрузчик. Но суть в том что из-за многообразия браузеров одни нативные решения могут напрочь отсутствовать в других браузерах, потому подобные плагины призваны убрать эту головную боль с поддержкой, предоставляя единое решение для всех браузеров.
Эти плагины работают через события, на которые вы можете навешивать все что угодно - от вывода превью изображения и обрезки его на клиенте (без необходимости загрузки на сервер, хотя по факту вы не изображение обрезаете, а лишь получаете координаты, по которым будете обрезать на сервере) до красивого прогрессбара. Когда вы получаете файл вы частично получаете о нем информацию (название файла, размер, тип..), но на проверки на клиенте ориентироваться не стоит - всегда проверяйте все на сервере.
На "вредоносный код" файл обычно не проверяют. Проверяют на соответствие требованиям - т.е. если ожидается изображение, то файл обязан быть изображением - в противном случае сообщаем об ошибке. На php это можно проверить с помощью функции getimagesize(), которая возвращает наиболее достоверный mime-type. На расширение вообще можете не смотреть - назвать файл можно как угодно и это вовсе не говорит о его типе. Чтобы быть полностью спокойным следуйте еще одному правилу - загружаемые файлы должны лежать в директории, из которой запрещено выполнение скриптов. Тогда даже если кто-то и загрузит php-файл - он все равно не запустится.
@rumkin Судя по тесту (цикл с 10к итерациями) у меня получилось 0.03 сек если исключения не было, и 1.11 сек если исключение произошло (все 10 тысяч раз). Блоки if-else работают примерно с той же скоростью, как если бы исключений не происходило.
У меня существует только одно исключение, которое отлавливается глобально - AppException - оно бросается с кодом http-статуса. Например, 404 - будет Page not found, 301 - редирект, и т.д. Соответственно в любом месте программы я могу сделать выход из нее и вернуть пользователю нужный статус. Все остальные эксепшены падают в exception handler, логируются/выводятся (в зависимости от прав запрашивающего) и кидают 500й статус.
Вообщем, все еще сыро и не обкатано, но в любом случае перевести ВСЮ работу с ошибками на эксепшены мне гораздо более симпатично, чем придумывать разношерстные варианты для разных случаев. Я еще покурю код популярных фреймворков - возможно там будут интересные идеи - и посмотрим что получится сделать. Если интересно - могу потом поделиться)
Да, хранение в базе не очень удобное. Да, можно в столбце добавить для всех записей "," в начале и в конце строки - тогда выборку можно делать одним лайком "%,{$user},%". Я лишь предложил вариант где в базе не надо ничего менять) А так нормализация - наше все :)
Ну вот касательно увеличения нагрузки - то да, я, конечно, слышал об этом, но не совсем понимаю причин..
Касательно классификации эксепшенов по назначению, а не по источнику - идея, на самом деле, замечательная, но я затрудняюсь с ее реализацией.
Во-первых, зачастую эксепшен вызывает какая-либо сторонняя библиотека (например, тот же PDOException). Во-вторых, обратная ситуация - при разработке подобных сторонних библиотек мы не можем рассчитывать на то, что у конечного разработчика будет обработка эксепшенов именно по назначению.
Кстати, да, можете пояснить назначение эксепшенов ClientException, AppExcetion и CoreException?
Касательно использования CID вместо ID - то да, его можно даже собирать на лету, например:
user_login_failed говорит что в классе User методе login() произошла ошибка failed.
Иногда помимо стандартного текста ошибки "Email не верный" требуется вставлять дополнительную информацию - "Использование почты с домена {$domen} запрещено" - в этом случае можно прибегнуть к sprintf(), я так полагаю.. Но есть один нюанс: получив в форме регистрации ошибку "Использование почты с домена {$domen} запрещено" мы не сможем подсветить красным поле ввода email - мы должны еще дополнительно как-то его идентифицировать..
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
