Comments 24
CodeIgniter 4.0 — Спустя 5 лет разработки вышла новая версия фреймворка. Переписан с нуля, но всё так же в виде единого пакета. Работает на PHP 7.2+, реализованы PSR-1,3,4.
Какой-то «привет из 2008», и больше похоже на пет-проект начинающего разработчика, чем что-то, что можно использовать в своих проектах.
Всё на статических хелперах, наследовании, protected-полях, массивах, DI даже не пахнет.
Из интересного сейчас есть Laminas, в частности, Mezzio(бывш. Expressive), с миддлварами из коробки и без http-kernel с его противными «ивентами».
Но контейнер хочется от Symfony, потому, кажется, проще из неё выпилить http-kernel и впилить миддлвари, чем в laminas нужный контейнер.
$hook['pre_controller'] = array(
'class' => 'MyClass',
'function' => 'Myfunction',
'filename' => 'Myclass.php',
'filepath' => 'hooks',
'params' => array('beer', 'wine', 'snacks')
);
$this->load->helper('html');
echo heading('Welcome!', 3, 'class="pink"');
public function create()
{
helper('form');
$model = new NewsModel();
if (! $this->validate([
'title' => 'required|min_length[3]|max_length[255]',
'body' => 'required'
]))
{
echo view('templates/header', ['title' => 'Create a news item']);
echo view('news/create');
echo view('templates/footer');
}
else
{
$model->save([
'title' => $this->request->getVar('title'),
'slug' => url_title($this->request->getVar('title')),
'body' => $this->request->getVar('body'),
]);
echo view('news/success');
}
}
// Create a new class manually
$userModel = new App\Models\UserModel();
// Create a new class with the model function
$userModel = model('App\Models\UserModel', false);
// Create a shared instance of the model
$userModel = model('App\Models\UserModel');
// Create shared instance with a supplied database connection
// When no namespace is given, it will search through all namespaces
// the system knows about and attempt to located the UserModel class.
$db = db_connect('custom');
$userModel = model('UserModel', true, $db);
Вот такое в «моделях»:
public function insert_entry()
{
$this->title = $_POST['title']; // please read the below note
$this->content = $_POST['content'];
$this->date = time();
$this->db->insert('entries', $this);
}
Нормальным кодом в 2020?
Это, если что, прям из документации codeigniter, и в таком стиле там всё, а не особо неудачные модули.
Или что «ивенты» с «приоритетами» от симфони лучше явной цепочки миддлварь?
Из интересного сейчас есть Laminas, в частности, Mezzio(бывш. Expressive), с миддлварами из коробки и без http-kernel с его противными «ивентами».
Вот бы был очень быстрый и компонентный PSR-* фреймворк. С RAD, но без магии. C нормальной ORM и инструментарием для горизонтального масштабирования. Желательно чтобы поддерживался компанией и имел 600 страниц документации. :D
Это не ирония (https://spiral.dev/). Через 2-3 недели анонсируем официально.
А нет ли в недрах телеграмма (или где-то еще) чатика, куда можно задать вопросы по Cycle? Посмотрел на нее и возникло несколько «а почему так?».
Например, почему через Repository я всегда заново обращаюсь к БД и надо получать уже выбранные сущности через Heap? Или почему Repository зависит от Select?
Наверняка это сделано по какой-то причине и решает определенные проблемы. Вот бы были профильные чаты где помогли входящим в проект (тыкнули хотя-бы на страницу доки).
Что-то я не понял сложности добавления контейнера от Симфони в Ламинас. Подумал даже, что туплю и перепроверил. У Симфони PSR-11 контейнер — вот https://github.com/symfony/dependency-injection/blob/24918d956cec89aebdf9dd69fc569a980469be3c/ContainerInterface.php#L25
Laminas поддерживает любой PSR-11 контейнер. Профит
Moving repositories from the entity folder <...> The namespace is now in App\Repository instead of App\Entity.
Да-да, сущности в / Entity, репозитории в /Repository, сервисы в /Services
Ну да, ну да, конечно — пошла я, плоская нормальная логическая структура проекта, нафиг :)
[RFC] Stringable — Предложение от Nicolas Grekas принято. В PHP 8 можно будет использовать union-тип string|Stringable там, где ожидается строка, и передавать классы с __toString(). При этом интерфейс явно добавлять не нужно.
Вперед, к утиной типизации!
Вообще объекты, реализующие __toString() и так можно принять в функцию по хинту string. По моему так и надо делать, если функция собирается работать с параметром как со строкой, то какая ей разница родной это стринг или или объект?
Конструкции типа string|Stringable будут только засорять код без острой на то необходимости.
и так можно принять в функцию по хинту string
в режиме строгой типизации
declare(strict_types=1)
не можно (а я не видел проекты большие и современные без него)Нужно приводить к строке при передаче
Вообще повальное увлечение этой директивой больше похоже на попытку компенсировать свои комплексы. Мол раньше все считали пхпшников говнокодерами из-за слабой типизации. А теперь и у нас есть сильная типизация и можно наконец-то причислить себя к когорте «нормальных» программистов.
Реальные проблемы слабой типизации эта дериктива все равно не решает.
symfony можно считать "большим и современным" проектом?
declare(strict_types=1) нужен лишь для редких случаев, когда нам кровь из носу нужно не пролюбить какое-то float-string-int приведение (работа с бд, например)
Разрабы доктрины например ЗА строгость явную и настаивают на этом :)
Однако обсуждаемое предложение — от основного разработчика Symfony.
тем не менее, они пока так и не реализовали этот фичреквест.
не думаю, что у симфони есть проблемы с легаси. в рамках мажорных версий они ее ломают и прекрасно сохраняют чистоту кода.
для доктрины понятно использование strict_types (именно из-за нее и упомянул в предыдущем посте работу с БД). Но так же мне приходилось сталкиваться с проблемами вроде той, что описана здесь https://github.com/symfony/symfony/issues/28423#issuecomment-420972515
в итоге от использования phpstan будет больше пользы, чем от strict_types. по крайней мере, пока php не оптимизирует свои структуры специально для strict_types.
https://github.com/symfony/symfony/issues/28423#issuecomment-419857864
не кодить в комментраиях
«Кодить в комментариях» ничем не отличается от кодить на «листе блокнота», парсится так или иначе все одинаково, просто на разных уровнях абстракции
Не понятно чем не понравились аннотации как в java (те, что сейчас в phpdoc)… Обязательно что то новое придумывать?
Обсуждаем в телеграме: @beerphp_spb (https://t.me/beerphp_spb)
Скриншот
PHP-Дайджест № 175 (25 февраля – 10 марта 2020)