Картинки то бедные зачем туда запихали? Конечно, апач напрямую их выдавать не будет, он же понятия не имеет, что такое phar.
mpak по поводу моего пример. Если тебе надо будет взять данные не из $_GET вдруг, а с другого места, например, что бы открыть доступ к модулям системы как к модулям API интерфейса, ты будешь писать весь API, а я напишу только пару функций, тотому как ты задолбаешься свой $_GET переписывать везде, наплодишь кучу багов и т.п. прелести...
Задача проста. Взять из гета. И в видимой перспективе она будет оставаться такой. Зачем придумывать гипотетические возможности? С таким успехом можно предположить что будет если мы будем завтра исполнять код не на апаче а на исс и написать еще две тысячи строк кода. Мы работаем с Гетом не вижу причин почему я должен брать их из другого места.
Когда мы перешли с апача на nginx нам не пришлось ничего переписывать в коде. Что мы изначально сделали не так?
Поять же для удобства. человек кидает архив и не задумывается что в нем внутри. Система работает. А на вопрос зачем? Могу ответить а почему бы и нет? Разработчики уверяют что работа в таких архивах будет не многим отличаться от работы с обычной фс. Есть директивы которые кешируют данный файл. А если не обманут то такой способ запуска становится очень привлекательным. Но решение достаточно свежее. Полноценная поддержка появилась только в php 5.3 поэтому в интернете информации не так много даже на иностранных сайта. Сама технология подобна архивам jar в JAVA. Думаю если интересно то можно легко найти все задачи которые решаются с ее помощью. Подобный архив в php создается phar расширением.
ИСС это просто пример. Смысл его был в том что не надо придумывать себе вещей вероятность столкнуться с которыми достаточно мала. Плюс подозреваю что данная проблема свойственна только вашей реализации. Думаю я никогда с подобными проблемами не столкнусь. Мой код тоже хорошо переносится на нгинкс. Ищу что не правильно сделал
mpak да чё тебе доказывать то, если ты ламер или у тебя просто нету опыта, что бы понять, что у тебя может пойти не так
Работает но реализовано через обращение к модулю. Обычные картинки выдаются пхпшником. Не мерял скорость но думаю было бы лучше для быстродействия если бы обращение шло напрямую к графическим файлам
mpak я тебе уже писал выше, что ты опять как баба на базаре трындычишь? Если несколько человек понимают, а нет, или прикидываешься что нет, то кто тут кто? Расскажи мне? Или ты такой гордый что не можешь признавать своих ошибок и неудач?
Какие ошибки у меня работает все как надо. И не надо высасывать ошибки из пальца. Мне сложно понять про какую ошибку ты мне втираешь. К тому же которая в теории может возникнуть. Ее никогда небыло и возникнуть она не может. Потому что код прост как барабан. В нем не может быть ошибок. Ошибки которые я вижу это что тот кто буде писать код забудет переключить раскладку и напишет вместо $_GET ;_ПУЕ. Наверно это тоже стоит учеть и написать еще какой нибудь класс защищающий меня от этой ошибки. Перед каждым запуском кода проверять его на корректность, генерировать кучу нотайсов , подготовить сообщение для посетителя что что то пошло не так и использовать ИИ для анализха сложившейся систуации.
Я, безусловно, абстрагировался от обсуждения, но позволю себе заметить, что, во-первых, безошибочного кода не бывает (если только это не while(true) ), а во-вторых, потенциальные ошибки у Вас в системе есть, и Вам на них указали. Вообще, достаточно интересная идея, хранить ядро в одном файле. Однако, было бы интересно увидеть тесты быстродействия. Ну и, конечно, есть проблемы с отдачей .. тех же картинок, например.
Проблемы безусловно есть. Но есть и плюсы. В файле не только ядро но и куча модулей. После установки сразу получаем рабочий сайт с прикрученным на выбор одним из трех дизайнов. Любой другой можно подключить копирванием в папку /themes директории в которой лежит файл. Код любой части системы можно заменить не меняя архива. К примеру можно в корень положить файл <? echo "Hellow World" ?> для системы это будет сигнал что нужно исполнять этот код вместо движка. Выполнив его работа остановится. Подобным образом заменяются и добавляются шаблоны блоки модули картинки и вообще все что есть в архиве. Для разработки это просто идеально. С одной стороны имеем систему которая всегда неизмена, с другой возможность менять ее всю по частям. К примеру я меню код движка на любом из хостов просто копируя в его корень новую копию файла index.php Для данного сайта исполняется данный файл и не влияет на работу других сайтов. Устранив ошибку или изменив файл я меняею его в основной директории. И изменения становятся доступны всем сайтам Одновременно. А их уже больше 200
Если поменяется архитектура то поменяется и код. При данной методике и архитектуре ошибок описанных выше просто не может возникнуть. Потому что ничего не делается. люой модуль в большенстве своем делает два действия. Делает запросы к бд и подключает шаблон данной страници.
И это прекрасно. Все просто и понятно. Зачем усложнять когда все можно сделать в три строки. Тупое кодирование это круто. Опять же приведу высказывание http://ru.wikipedia.org/wiki/Философия_Юникс «Будь попроще, тупица»
mpak ты реально тупой или прикидываешься? Я обычно не доказываю дальше ничего, а сейчас я просто продолжу. Ну так, или ты читаешь сквозь строки что тебе пишут?
Зачем делать в три строки, если можно написать класс из 20 строк, а потом в сотне мест заменить эти три строки на одну?
Или вот еще с того же документа Правило 4: Упрощайте ваши алгоритмы и структуры данных где это возможно, поскольку изощрённые алгоритмы труднее реализовать без ошибок.
Я не мерял. В директивах пхп есть параметр для кеширования данного архива. Если он будет находится в оперативе то работать должен очень быстро. Хотя нужно тестить.