Создание блога

[miketomlin]

Не могли бы вы показать свой класс?

Не. Если охота посмотреть готовый код, используй packagist и т.п. или репозитории поп. фреймворков. Я просто говорю, что для полноты класса в нем должны быть методы закрытия соединения, выполнения обычного запроса (а не подготовленного) и т.п. Кстати, если совсем лень делить метод выполнения запроса, можешь хотя бы еще флажок добавить, чтобы не только по значению $args определять тип запроса, а еще и по флажку.

Я не совсем понял про закрытие соединения. В деструкторе $this->pdo = null это не про это?

С PDOшкой и объектами PHP все сложно. Даже если ты будешь так вызывать декструктор твоего объекта, никто не гарантирует, что он сразу отработает. Поэтому лучше использовать обычный метод. Даже если он не будет толком работать с PDOшкой, то заработает, когда ты в этот класс обернешь работу через мускулай, PGшку и т.п.

 

[miketomlin]

Сегодня вот напишу контейнер и глобальных переменных не будет.

Кстати, необязательно подтягивать объект из глобальной области видимости, чтобы не передавать его явно

db()->query('SELECT 1');

db() необязательно должна быть функцией-синглтоном. Она может только хранить объект (или какой-нибудь null).

 

[firep91613]

выполнения обычного запроса (а не подготовленного) и т.п. Кстати, если совсем лень делить метод выполнения запроса, можешь хотя бы еще флажок добавить, чтобы не только по значению $args определять тип запроса, а еще и по флажку.

Ок. Я понял. Сделаю.

Кстати, необязательно подтягивать объект из глобальной области видимости, чтобы не передавать его явно

Ну там же автозагрузка классов в точке входа. А в нужном контроллере получение сервиса. Или не так должно быть?

Поэтому лучше использовать обычный метод.

Создать метод close и вызывать его явно?

public function close() {
    $this->pdo = null;
}

 

[firep91613]

db()->query('SELECT 1');

Реализовал. Это типо для каждого сервиса можно создать обертку? И просто вызывать ее.

 

[miketomlin]

Ну там же автозагрузка классов в точке входа. А в нужном контроллере получение сервиса. Или не так должно быть?

Вообще вспомогательные объекты частенько создаются до основного, даже если этот основной – контроллер. «Получение сервиса» можно по-разному понять: 1) получение ранее инициализированного; 2) получение и инициализация при первом обращении (в процессе получения). Можешь и в контроллере инициализировать для моделей. Можешь даже в одной из моделей при первом обращении.

Но та моя фраза про глобальную область видимости относилась к очередному упоминанию глобальной переменной. Т.е. это про вариант инициализации еще до создания/вызова контроллера.

Создать метод close и вызывать его явно?

Да. Причем в той же области видимости, в которой ты инициализируешь этот объект. Можно вне контроллера/экшена, чтобы не дублировать код открытия/закрытия во множестве контроллеров/экшенов.

Это типо для каждого сервиса можно создать обертку? И просто вызывать ее.

Да. Можно даже одну обертку для всего:

registry('db')->query('SELECT 1');

P.S. Реестр – это НЕ про инициализацию объектов, а только про хранение.

 

[firep91613]

получение и инициализация при первом обращении (в процессе получения).

Ну у меня сейчас так и есть. При обращении вызывается функция.

Да. Причем в той же области видимости, в которой ты инициализируешь этот объект. Можно вне контроллера/экшена, чтобы не дублировать код открытия/закрытия во множестве контроллеров/экшенов.

Ну вот, допустим, получение сервиса:

$connection = classes\App::get(classes\DataBase::class);
// Дальше выполнение запроса. И после закрытие.
$connection->close();

Так?

 

[AnrDaemon]

Ну, ОК. Называй, как хочешь. Но иметь в классе метод с подготовленными выражениями и не иметь без – это такое себе. Так понятнее?

Непонятно. Зачем тебе это?

Сегодня вот напишу контейнер

Зачем писать то, что давно написано за нас?

Я не совсем понял про закрытие соединения. В деструкторе $this->pdo = null это не про это?

Зачем?… Для PDO это не нужно в 99,(9)% случаев.
Самый надёжный код - это код ненаписанный. В нём нечему ломаться и багов в нём не бывает.

 

[firep91613]

Зачем?… Для PDO это не нужно в 99,(9)% случаев.
Самый надёжный код - это код ненаписанный. В нём нечему ломаться и багов в нём не бывает.

То есть, у меня нормальный класс?

Зачем писать то, что давно написано за нас?

Ну просто копировать не интересно. Я стараюсь после прочтения самостоятельно написать.

 

[AmdY]

То есть, у меня нормальный класс?

Ну просто копировать не интересно. Я стараюсь после прочтения самостоятельно написать.

лучше сразу посмотреть чужую реализацию, попользоваться ей и только потом писать своё, пока у тебя опыта мало. Иначе ты тратишь кучу времени и сил пока гребешь не в ту сторону.

 

[firep91613]

Как в идеале должно быть? Абстрактный класс Controller, от которого наследуют все контроллеры? Абстрактный клас View, от которого наследуют все виды? В каждый контроллер передается свой вид?

У меня щас просто контроллеры, к которым инклюдятся шаблоны.

 

[miketomlin]

Так?

Да, примерно.

У меня щас просто контроллеры, к которым инклюдятся шаблоны.

Можно и так. Только include в функцию рендера запихни, которая на входе получает имя шаблона и набор данных для подстановки (в массиве) и возвращает готовый статик. Т.е. результат этой функции можно выводить «в браузер» или вставлять в др. шаблоны.

 

[miketomlin]

...или опять для уменьшения дублирования кода выносить рендеринг из контроллера, т.е. размещать после вызова контроллера/экшена. Но это редкая практика. Чаще из контроллера возвращают готовое тело ответа и заголовки (тоже уменьшает дублирование, т.к. хотя бы вывод делать не нужно). Либо вообще рассматривают выход из контроллера, как exit.

 

[miketomlin]

...рендеринг обычно делается «по восходящей»: сначала один или несколько внутренних блоков (осн. контент), а потом уже вся страница. Всю страницу можно не рендерить в память, а сразу выводить, т.к. считается, что рендеринг осн. контента – наиболее затратная часть работы.

 

[firep91613]

Как лучше сделать слаг? Я вижу два варианта: в форме добавления статьи создать скрытое поле и туда уже функцией вставить преобразованный заголовок, или в контроллере, до добавления в БД?

 

[AmdY]

Поле редактируемое, при создании заголовка в него вставляется слаг, но пользователь может редактировать его. И важно после публикации сохранять старые слаги при редактирование и делать редиректы со старых вроде 301 на новый.

 

[miketomlin]

Без скрытых полей, пожалуйста. Можешь использовать «не сразу» редактируемое поле. Т.е. на клиенте защитить от редактирования, пока не сделают доп. клик. Естественно, первоначально генерировать дефолтное значение тоже на клиенте.

А вообще я не люблю излишнюю автоматизацию. Поэтому мой вариант автогенерации, если он вообще есть, – что-то вроде post-<id> (post-100500). Возможно, такое отношение связано с тем, что я в основном использую CSM'ки, в которых слаг указывается в первую очередь (как имя файла при его создании из какой-то оболочки). Для автогенерации можно оставить поле пустым, но ты ничего круче post-<id> скорее всего не получишь, т.к. доп. полей вроде заголовка в форме создания обычно нет.

 

[miketomlin]

И важно после публикации сохранять старые слаги при редактирование и делать редиректы со старых вроде 301 на новый.

Кстати, да. Соответственно в таблицах разных сущностей кроме самих сущностей могут храниться и «редиректы». Обычно записи этих двух типов различаются по какому-то флажку или числовому признаку (категория, порядок и т.п.): редирект можно обозначить нулем или NULL'ом.

P.S. Конечно, лучше всего с адресом/слагом сразу определиться. А редиректы использовать (т.е. в принципе добавлять такой функционал), когда ты за каким-то контент-менеджером подчищаешь дебильные адреса.

 

[weregod]

и делать редиректы со старых вроде 301 на новый.

ох, не люблю я эти перманентные редиректы, уж очень они в браузерах оседают, фиг что поменяешь потом клиенту, уж лучше "302 Found" имхо, но не в курсе, хорошо ли последнее для поисковиков...

 

[firep91613]

Не совсем понял. Ну вот есть статья, там должна быть кнопка редактировать? Надо создать новый контроллер, для редактирования, с формой и в нее вставлять старую статью?

Для слагов лучше сделать отдельную таблицу? Чтобы и редиректы хранить.

 

[ksnk]

Вот тут, например такой адрес talk/threads/Создание-блога.88142/page-5#post-782781
Тоесть, все, что перед точкой в слаге - это свободно изменяемая часть, захотелось переназвать - переназывай как хочешь. А после точки - ID-никогда не изменяемый. Никаких лишних телодвижений, таблиц редиректов и гемора. Можно сразу показывать новую страницу, но чтобы сеошники не прокляли - лучше через 301.
Ну а если не так, то да, таблицы, гемор, все такое. И за каждое новое переназвание будет прилетать от сеошников...