ppa > 1) Это таки не ошибка архитектуры. Мне нужно это, чтобы никто не мог вызвать функцию, не возбудив хэндлер.
Дык приватные методы для этого есть.
> Код может быть обфусцирован, также есть различные callback функции.
В чем проблема то? Смысл в том, что бы заменить:
myfunction($param1, $param2)
на
pleaseRunMyHandlerForFunction('myfunction', [$param1, $param2]);myfunction($param1, $param2);
Вы пытаетесь решить архитекрурный пр**б костылями из обогащенного урана.))
Тут могу предложить 2 решения:
1. Переделать архитектуру, что бы таких глупостей не требовалось.
2. Использовать предварительную модификацию кода, через token_get_all с явной модификацией кода и сохранением его во временную директорию, из которой он будет работать.
Reflection API в помощь. Если я правильно понял, что вы хотите сделать - лучше всего создать классы обертки (можно в виде наследников), которые будут реализовывать конкретно ваш функционал. К приватным методам/свойствам сможете достучаться через Reflection API.
Алексей Зорин > Он ведь устраняется функциями imagecreatefrom....
Ну, тут в исходниках колупать нужно, что именно переписывается в контейнере, и выполняется ли перекодирование целевого изображения при сохранении формата.
На счет каталогов: одна из очень весомых целей разбивки - это вовсе не сохранить дату файла (она и так сохраняется), а уменьшение нагрузки на файловую систему. При большом количестве файлов в одном каталоге время получения дескриптора файла будет только увеличиваться. Смысл разбиения на подкаталоги в том, что вы будете получать примерно одинаковый уровень заполнения каталогов и когда даже данный подход не будет справляться - придется смотреть в сторону распределенных систем хранения файлов, например mogilefs
Алексей Зорин Вы того, не думайте, что существует абсолютная защита)) Задача любой системы защиты - сделать ее взлом не выгодным, не более и не менее того.
Александр Аксентьев Новым он не станет, его можно будет легко спутать.
Тут проблема будет именно в человеческом факторе: есть некая уверенность, что файлы в этой папке именно за этот месяц. Замечательно, но вот про то, что файлы там могут быть за прошлые годы - легко за год забыть, а дальше наломать дров.
еще нюанс на счет имен файлов: через год работы у вас пойдет коллизия путей, не в плане повторов, а в плане того, что файлу будет год, а вы будете считать его новым. Вместо этого рекомендую сделать следующее:
Рассчитываете $md5 = md5_file, далее его путь берете, как:
"/path/to/{$md5[0]}{$md5[1]}/{$md5[2]}{$md5[3]}/" . substr($md5, 4) . ".{$ext}";
Хотя md5_file и будет кушать некоторые ресурсы, но вы с избавитесь от дубликатов. Да, у md5 есть коллизии, но вероятность попасть на нее будет очень мизерная, не выше, чем у вашего метода расчета имени.
> Но ведь в итоге каждый файл пустой, почему нельзя использовать один для всех?
Пример: ты делаешь запись комментария пользователя, ловишь эксепшн:
БД не доступна, твои действия? Можно конечно написать юзверю: это же сообщение, но это того, не комильфо, по хорошему - вернуть сообщение: "бла-бла-технические-бла-бла-бла-неполадки-бла-бла".
Там же после того, как БД восстановлена ловишь эксепшн: пользователь не авторизирован, по идее надо бы его отправить на авторизацию, а не только вывести сообщение.
Там же ловишь исключение: не валидные данные (пустое тело комментария), вот тут надо сказать юзверю конкретно это сообщение.
OnYourLips: как это противоречит моим словам? Если использовать только шаблонизатор, Twig, Smarty, Blade, да что угодно - действительно не надо париться на счет "Секции, наследование шаблонов, автоэкранирование". Но, фреймворки в большинстве так, или иначе решают эту проблему.
Я не утверждаю, что шаблонизаторы есть зло, я говорю о том, что по своей сути они пародируют php.
OnYourLips: > Вероятность того, что SoA проект будет дешевыми, стремится к нулю.
И как это противоречит тому, что я сказал? ТЗ определяет фреймворк. Если нужна визитка - symphony будет как по воробьям из миномета. В случае требований с горизонтальным масштабированием symphony очень даже рулит.
OnYourLips: >> Секции, наследование шаблонов, автоэкранирование - этого всекго PHP не умеет
Если вы используете абстрактный шаблонизатор в вакууме, без любой другой БЛ - действительно, все это не надо прописывать руками, замечательный профит.
Но в реальности этим занимается чаще всего фреймворк.
Anton: Вы сначала прочитайте, что такое PSR, а потом делайте такие заявления))
У PSR-0 - требования к именованию классов, неймспейсов и местонахождению классов/интерфейсов/трейтов, которых у 3.3 не заметил. PSR-1, PSR-2 - действительно стиль, PSR-4 - логгер, PSR-5(пока не принят) - DocBlocks. Остальные, хотя и не приняты, стандартизируют интерфейсы обобщенных модулей.
diamond: Дык не вопрос, пишите хоть на php4-совместимом фреймворке. Клиенту все равно в принципе, а вот программисту - не должно быть.
OnYourLips: Я вам по секрету: выбор фреймворка выполняется НЕ по цене проекта, а по его ТЗ. Symphony - это сервис-ориентированное программирование, Laravel - же более "неделимый"))
OnYourLips: Зря вы так. Задача шаблонизатора - ввести данные в верстку. Для простых шаблонов - it's ok, но когда появляются условия, циклы преобразования чисто под вывод - шаблонизаторы растут, и начинают реализовывать функционал, который и так обеспечивает php.
>> html5, я надеюсь, к тому времени, как я полностью постигну связку клиент-сервер, будет позволять делать в полной мере то, что душе угодно.
Ну, HTML5 как бы уже позволяет все что хочешь)) Посмотрите в сторону Canvas/WebGL например.
В том то и дело))
Не важно, сколько фреймворков вы изучали, важно - сколько и каких проектов на них сделали))
>> Для меня не в новинку слова координаты и gpu
Вы занимаетесь GameDev? Если не секрет, какие технологии используете?
>> js даже помог понять классы, в самом абстрактном их виде.
Ухты)) посмотрите Golang на досуге))
>> 1) По этому, посоветуйте статьи раскрывающие тему современных технических требований к вэб-приложениям.
Если брать самые общие требования - протокол передачи данных HTTP)) Понимаете, понятие web приложение очень обширно, это может быть чисто серверное приложение с html+css выводом, может быть SPA общающееся с сервером по REST, SOAP, WS, или какой-то своей реализацией RPC, например БД CouchDB, ElasticSearch - это тоже web приложения. Это может быть и без-серверное приложение, или мульти-серверное.
>> 2) За недолго мое прибывание на Тостере я с трепетом читал все темы и подчерпнул что AngularJS не подходит тогда, когда речь идет об индексации.
Почему же? Google бот вполне кушает js.
>> Так же я немного узнал о составлении html на сервере, но я не понял, нужно ли и есть ли фраймворк который будет работать с такими вот принятыми с сервера данными.
Строить SPA без опыта обычных сайтов - будет сложновато. Это как строить ядерный реактор после изучения термодинамики.
>> И если такие фраймворки есть, то посоветуйте два конкурирующих.
Backbone, Catberry, Ember
То, что ты выводишь в килл-фичи (если я правильно понял) - называется ЧПУ.