> Да, я считаю вашу критику не обоснованной.
Да мне в общем то все равно, вы же защищаете подобие фреймворка, разработчики которого даже в MVC не смогли))
Так как вы сказали что знакомы с Yii буду приводить сравнение с ним.
0. Autoloading www.codeigniter.com/user_guide/general/models.html
ci: $this->load->model('modelName') - НЕ ОК, но справка так рекомендует!
> If you find that you need a particular model globally throughout your application, you can tell CodeIgniter to auto-load it during system initialization.
ЛОЛШТО?? Автолодинг на нейспейсах еще в 5.3 появился. А то, что предлагается подгружать модели в конфиге при инициализации - за это надо... плохо в общем сделать.
У ci - значения параметров запроса жестко привязаны к их порядку объявления, у yii они привязаны к именам. Контроллер ничего не должен знать о роутинге, он решает другие задачи.
Наличие _remap - это вообще зло))
В задачи контроллера не входит полное управление представлением. Он обязан сформировать данные для вывода и передать их в шаблон, но не разбираться с тем какие зависимости есть у шаблона, динамические они, или статические, это полностью задача шаблона, справка ci предлагает делать по другому.
Модель не должна быть связана с пользовательским вводом, это задача контроллера, но справка ci учит обратному! Если вы поменяли ЧПУ - придется исправлять все зависимые контроллеры И все зависимые от них модели, это путь в никуда.
Что на счет валидации данных?
В ci это дело должно быть прописано обязательно руками отдельно. Но на секундочку, проверка данных перед запросом к БД - это одна из важнейших задач модели.
Я в курсе про form_validation, валидация форм - это проверка пользовательского ввода, валидация модели - это работа с БД, если в промежутке между form_validation и моделью данные изменяются - их обязательно необходимо проверять.
4. Контроль доступа, ci его просто нет из коробки, у yii - есть причем несколько имплементаций.
5. Кэширование, что на счет инвалидации кэша?
У yii есть зависимости, у ci - только ручное удаление. Кэша фрагментов тоже не вижу, хотя это ончеь удобно))
6. Виджетов тоже не наблюдаю..
И это только беглый просмотр доки))
> CI не быстрый? Быстрый.
Быстрый он не потому что качественный, а потому что убогий по функционалу. Качественный фреймворк - это тот, в котором составляющие части являются минимально зависимыми друг от друга, что бы в случае изменений - правки приходилось выполнять в минимуме компонент.
> ... но отстаивать свою правоту не обосновав ничем весомым своё решение. Так-что я думаю не стоит им уподобляться...
Вы считаете мою критику не обоснованной?))
> Да и вопрос ставился чутка иначе :)
На ваш вопрос ответили уже выше)
Месседж был в следующем:
если нужна скорость выполнения - это не CI
если нужна функциональность - это не CI
если проект большой - это не CI
если нужно что-то "на коленке" - вот это CI, но есть решения по лучше
> Не знаю, я лично memcached так не использовал, но модуль для ...
смысл в том, что бы отправлять данные на прямую из мемкэша, без использования ноды, php, python, или на чем там бэкенд написан.
> Возможности nginx. Разве нет? Можете сказать, что не работает?
Я ж вам привел пример с мемкэшем
> Сокеты и порты. А как связать, скажем, 80 порт с нужным сокетом нужного приложения ноды по домену?
Обычно проксируется через nginx на сокет файл + nginx отадет статику. Но это не является обязательным, можно напрямую поднять ноду на 80-м, в таком случае слушать сокет нет необходимости.
> Так passenger разве отнимает возможность взаимодействия с окружением, в котором запускается приложение?
Тебе это не нужно.
> Приложение работает точно так же, за исключением того, что нет необходимости переписывать код для работы в разных окружениях и конфигурация сервера приложения интегрирована в web-сервер.
Если код должен работать на РАЗНЫХ окружениях - он должен таки тестироваться на РАЗНЫХ окружениях)).
> Опять-таки, непонятно, как может конфликтовать сервер приложения с подобным софтом?
Например вы запускаете на старой версии ноды свою апликуху, но используете API последний версии - работать корректно не будет. Либо протвиоположный вариант: используете устаревшее API.
Еще раз, то, что предлагает ваша аплиукха - это сознательное завязывание собственных глаз для маленьких проектиков.
Пул тредов для эмуляции асинхронности - 4. Если вы читаете 5 больших файлов в асинхронном режиме, 5-ый таки подождет до момента, пока не освободится хотя бы один тред. Подобная штука и с драйверами БД: если драйвер реализовывает собственный обработчик очереди + мультитредовость, а данные отадет через event-loop - тогда имеет смысл говорить про асинхронность, в противном случае: 4 потока, ил тюн libuv.
@mr_T
> настройка в конфигурационном файле nginx
ну, такое. он умеет сетапать прямую отдачу страниц, закешированных в кластере мемкешей?))
> авторестарт сервера при ошибках
Авторестарт - это признак очень дурного тона. Если вы сейчас подумали про не перехваченные исключения - да, я именно о них.
> все возможности nginx
Да лааадно.
> быстрое взаимодействие nginx с самим приложением за счет использования сокетов вместо портов
Как правило unix sockets быстрее, но отнюдь не всегда, это базовый функционал вебсервера ноды. https://nodejs.org/api/http.html#http_server_liste...
> приложения на ноде не занимают отдельный порт
это следствие того, что нода будет слушать сокет файл.
Мда... посмотрел интро у этой штуки, полная хрень. Погуглите puppet, chef, salt, vagrant, docker. Окружение - это неотъемлемая часть приложения. Хотите вы того, или нет - ваш код в абстрактном вакууме работать не будет. Да даже сама нода вместе с npm - это тоже часть окружения.
Когда нужна реальная скорость - это не php)). Тот же файлькон такой быстрый потому, что не native php. Еще раз. php - state-less язык, только за счет этого говорить о сверх производительности - это по меньшей мере смешно. На каждый запрос создается отдельный процесс, все окружение поднимается заново.
На счет тестов - это с включенным OPcache? Тот же yii используется через yiilite.php? Что на счет кэширования в memcached?
По хорошему - для тех же статических страниц вполне норм решение - заливать в memcached и читать ngnix-ом на прямую. Для остального - хотите выжать из php максимум:
- отказывайтесь от php в сторону HHVM
- отказывайтесь от серверного рендеринга в пользу SPA, или гибридного (как на пример catberry)
- отказывайтесь от максимального числа запросов к БД, кэшироваться должно практически все
PHP - это язык быстрых решений, но не язык быстрых систем.
@Relike
> будь в курсе событий
Да я в курсе, что 3-ий вышел. Даже в PDO смогли, молодцы, что тут скажешь
> Не переписывать код фреймворка, а расширять его, ведь Yii тоже даёт такую возможность, не так-ли?
Yii-way предполагает, что фреймворк отдельно - ваш код отдельно.
> И я думаю надо придерживаться этого ибо это уже флуд.
На счет ЧПУ: тут все зависит от бизнес задач и прошаренности SEO. Для статей норм решением считается slug названия статьи через дефис + id статьи там же, например:
mysite.com/some-very-cool-article-125
Пример кода, что вы сбросили реально гуано. Дело тут в том, что ваш роутер будет понимать всего один человек в мире. Пример, что написал diamond - вполне ок.
> глобальные переменные... ГДЕ?
конфиги, супер глобальные переменные.
> правила валидации моделей пишутся руками. Ну я думаю другими местами писать не очень удобно.
У того же Yii они пишутся как списки параметризируемых валидаторов, у Doctrine - как аннотации, yaml-ы, или php-шные массивы настроенных валидаторов. "руками" === "свой велосипед"
> что на счет именованных параметров в запросах?
Тут не уточнил, в БД. В оф. справке рекомендуется использовать плейсхолдеры "?", для большого количества плейсхолдеров - это не самая лучшая идея.
При чем тут Yii?)) Это не единственный фреймворк, а первая версия вовнутри - полное гуано. Вторая уже по лучше, но за счет завязки на синглтоне для крупных проектов - не подходит.
Недостатки:
- нет поддержки PSR
- поддержка говна мамонта (5.2.4) ... php 5.3 официально не поддерживается, о чем можно говорить?
- кастомный автолоад, ну это конечно здорово, но уже как бы давно composer придуман и все такое))
- фреймворк как именно часть приложения. Сама идея на момент создания - была вполне торт, но сейчас это не актуально. CI предполагает следующее: если в самом CI что то работает не так, как нужно - правим CI, следственно официальная дока для проекта уже будет не корректной. Пример: у вас есть средний проект на CI, обросший некоторыми изменениями, новый сотрудник работавший с CI раньше должен будет все равно изучить в полной мере, что вы там поменяли, потому как оф. документация уже не будет подходить. Это путь в никуда.
- глобальные переменные...
- правила валидации моделей пишутся руками.
- что на счет именованных параметров в запросах?
- SOA не возможен
Поймите правильно, я тоже когда-то фанател от CI (лет 6-7 назад), но потом познакомился с другими фреймворками и могу сказать следующее: CI любит куча народу потому, что он очень простой, а простой он потому, что предлагает простые решения "в лоб".
В средних и больших проектах решения "в лоб" обычно не приемлемы.
Сергей > но может еще покажет класс в будущем..
Пока не:
- откажется от 5.2
- перейдет на общие стандарты
- откажется от идеологии "фреймворк - можно изменять"
- победит уже существующие микро фреймворки
он так и останется старой какой мамонта.
Relike > С чего ты решил что это прошлое?
Пункты выше
> Он в разы гибче, более расширяемый.
Что на счет silex?
Расширяемость за счет того, что можно поправить код фреймворка - это не расширяемость - пример хреновой архитектуры.
> Возможно я еще не опытен и поэтому мне нравится писать всё самому, но при всём этом создание сайта на CI на много быстрее создания сайта на том-же Yii. habrahabr.ru/post/39300 Когда вырастите с проектов, рассчитанных на одного программиста, это пройдет))
> И сам сайт в разы быстрее работает.
Скорость за счет функциональности - не самая хорошая идея. Если хочешь реальной скорости - смотри в строну Phalcone, или HHVM например.
Ждал уже комментария про пропадание света...
Если вам так нужно качать постоянна - что мешает, например на DO (https://www.digitalocean.com/?refcode=ca94b4fc3b57) поднять vps, + написать скрипт, который будет вам постоянно качать 24/7 с большой скоростью ваши сайты, а дальше их запаковывать. Все что останется - скачать результат
Рекомендую это делать в виртуалке потому как рано, или поздно могут возникнуть конфликты зависимостей пакетов, а на host системе - это не самое приятное.
> Зачем, если это можно реализовать у себя на сервере и не платить. ))
Даже если это домашний сервачок - платить будете (за электричество например).
> Под Linux есть только сторонний консольный клиент.
Чем браузерный вариант не подходит? Вы в вопросе указывете "PHP скрипт" - он в принципе будет работать на вывод либо в веб-сервер -> браузер, либо в консольку.
> Если сервис закроется
Тогда - пичаль. Закроется все рано, или поздно. И ваш скрипт php-шный тоже в один прекрасный момент перестанет работать. Такова жизнь.
> Хотелось бы, все таки, иметь какой-то контроль, что бы данные вдруг не утекли куда-нибудь.
Шифруйте ваши данные AES256, и все норм будет
Да мне в общем то все равно, вы же защищаете подобие фреймворка, разработчики которого даже в MVC не смогли))