miketomlin
Новичок
Не надо. Может, новый аккаунт создать? Хотя кому надо, тот и так скачает.
Лучше демку выложи. Я, например, люблю покликать по сайту, прежде чем смотреть его исходники. На самом деле оцениваю адресацию и т.п.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Создание блога
- Автор темы firep91613
- Дата начала
Лучше демку выложи. Я, например, люблю покликать по сайту, прежде чем смотреть его исходники. На самом деле оцениваю адресацию и т.п.
firep91613
Новичок
Я решил сделать класс View. Ну через виды и шаблоны вобщем. На главной странице и в результатых поиска дожен быть сайтбар, а на странице конкретного поста - не должен. Как лучше сделать шаблоны? Для главной и результатов поиска сделать один шаблон с сайтбаром, а для поста без? Или основной шаблон надо собирать по кускам, ну т.е. подключить шапку, подвал, по условию сайтбар?
miketomlin
Новичок
Обычно делают наоборот
Или везде одинаково (в плане сайдбара), чтобы юзеров не напрягать. Сейчас кстати можно везде одинаково без сайдбара.Поменьше ветвлений в основном шаблоне. Лучше два разных.
Сайдбар может быть частью частного шаблона (смежный блок), когда типов страниц с сайдбаром ограниченное число. Причем подключаться даже не инклудом, т.к. он часто полностью кешируется. Т.е. в «паре» контроллеров подгружаешь кеш и втыкаешь его значение в соотв. частные шаблоны. Предполагается, что сайдбар кешируется фоновой задачей при помощи «неблокирующего» кеширования.
Последнее редактирование:
firep91613
Новичок
Ну я понимаю, так проще. Я просто специально так выбрал, ну чтобы посложнее было.Обычно делают наоборот
Я еще не знаком с кешированием. Мне бы по проще для начала, но более-менее прилично
Вот, допустим, как делают. Есть главный шаблон, ну т.е. в него выносятся все неизменяемые части на всех страницах. В моем случае это шапка и подвал. А дальше уже в главный шаблон вставляются соответсвующие виды, ну просто меняется контентная часть. Если я сделаю, главный шаблон с шапкой и подвалом, а в виде, буду или не буду инклюдить сайтбар в зависимости от вида - это не совсем убого?
Вот, к примеру, для главной страницы вид сделать такой:
PHP:
<main class="main">
<section class="posts">
<?php foreach ($posts as $post): ?>
<article class="post">
<h2 class="post__title"><?= $post['title'] ?></h2>
<div class="post__excerpt"><?= $post['excerpt'] ?></div>
<p class="post__link"><a href="<?= $post['slug'] ?>">Читать далее</a></p>
</article>
<?php endforeach; ?>
<?= $pagination; ?>
</section>
<?php require_once VIEWS . '/partials/sidebar.php' ?>
</main>
Последнее редактирование:
miketomlin
Новичок
Тогда «захардкодь» пока сайдбар. Если достаточно чистого статика, то это практически и есть значение из кеша. «Неблокирующий» кеш – это когда у тебе в кеше две копии, и ты выбираешь одну из них в зависимости от тек. времени (пока используешь одну копию, другая может обновляться). Примерно так:Я еще не знаком с кешированием. Мне бы по проще для начала, но более-менее прилично
PHP:
if (!$sidebar = file_get_contents(PATH.'cache/sidebar'.quantum())) {
$sidebar = '';
}Если чистого статика недостаточно, оформи сайдбар в виде подключаемого файла (как ты собственно и сделал) и получай в контроллере все необходимые ему данные. Концовка _once в данном случае не нужна. И в шаблонах можно даже include использовать (но смотри сам: иногда выбор между include/require определяется логикой выполнения).
Я же тебе вчера написал, что это норм. вариант, если типов страниц с сайдбаром немного, например «пара». Иначе надо использовать два разных «главных» шаблона. (И будет лучше, если сайдбар будет обслуживаться не в обычных контроллерах страниц, но для «пары» типов страниц данные для сайдбара или целиком сайдбар можно готовить и в обычных контроллерах.)
ПРОСТО ДЛЯ СПРАВКИ:
Бывает такая фишка, как отдельный код сопровождения (обслуживания) каждого «главного» шаблона. Если делать совсем по-простому, «главный» шаблон может выглядеть так:
PHP:
<?php
// код сопровождения
?>
<!DOCTYPE html>
и т.д.Бывает даже код сопровождения у каждого блока страницы. В этом случае можно было использовать непосредственно код сопровождения сайдбара, а не выносить подготовку сайдбара в код сопровождения «главного» шаблона с сайдбаром.
Если все это пока сложно, еще есть подгрузка сайдбара и т.п. AJAX'ом
Последнее редактирование:
miketomlin
Новичок
Еще лайф хак: php-вставки с управляющими конструкциями лучше писать без отступов. Если оч. хочется, можешь нужные отступы после <?php делать.
Это чтобы «чистый» (т.е. красивый) статик генерировался.
Вставки с выводом (<?=) аналогично, если ты не уверен, что всегда будет выводиться однострочное значение, т.е. без переносов строк. Можно вообще всегда писать без отступов. Короче чтобы не было в результате такой хрени:
Это чтобы «чистый» (т.е. красивый) статик генерировался.
Вставки с выводом (<?=) аналогично, если ты не уверен, что всегда будет выводиться однострочное значение, т.е. без переносов строк. Можно вообще всегда писать без отступов. Короче чтобы не было в результате такой хрени:
Код:
текст текст
текст текст
текст текст
Последнее редактирование:
firep91613
Новичок
Что вы думаете о подходе, когда модель становится таблицей из БД, а объекты записи из таблицы?
miketomlin
Новичок
В каком смысле «объекты», ООП-ном? Если в смысле терминологии, то у нас обычно таблицу называют коллекцией, а отдельную запись – да, объектом.
P.S. Не любую таблицу называют коллекцией, например словарную, когда нет возможности редактировать ее отдельные записи, так и называют словарем.
А в ООП-ном смысле модель тоже представляется объектом, причем это часто более рабочий объект, чем объекты отдельных записей. Отдельные записи легко и массивами представлять.
P.S. Не любую таблицу называют коллекцией, например словарную, когда нет возможности редактировать ее отдельные записи, так и называют словарем.
А в ООП-ном смысле модель тоже представляется объектом, причем это часто более рабочий объект, чем объекты отдельных записей. Отдельные записи легко и массивами представлять.
firep91613
Новичок
@miketomlin, как я понял, классы создаются по названиям таблицы БД и содержит статические методы для работы с таблицей, а объекты это экземпляры класса, которые содержат записи из таблицы, ну типо у каждого объекта своя строка из таблицы.
К примеру, есть таблица users, создается класс Users, у которого есть свойства, допустим, id, name, email (каждый экземпляр имеет свою строку из таблицы). У класса Users делают статические методы, достать всех юзеров, достать конкретного юзера и т.п.
К примеру, есть таблица users, создается класс Users, у которого есть свойства, допустим, id, name, email (каждый экземпляр имеет свою строку из таблицы). У класса Users делают статические методы, достать всех юзеров, достать конкретного юзера и т.п.
Зачем тебе статика и геморой с ним. Чем тебя обычные классы не травятся, которые нормально передаются через DI и код получается прозрачнее с конструктором, наследование, перегрузкой методов, приватными-протектид методами и т.д.
Сам по себе Active Record нормальный и подходит для большинства кейсов, хотя у нас принято ругать. Но писать его с нуля - это жесть, может ещё что-то на уровне первой коханы получится написать без опыта с пару попыток.
miketomlin
Новичок
Статик – это почти процедурка (процедурный стиль) с некоторым подобием инкапсуляции данных (разделением данных между несколькими связанными ф-циями). Я понял: ты насмотрелся ORM'ов вроде Элеквента (КуэриБилдер, РедБинПХП и т.п. тоже не сильно отличаются). Почти с таким же успехом можно использовать articles\all() и т.п. или collection\all('articles') и т.п. Это чистая процедурка (у нас такого полно). Но раз уж ты взялся за ООП, пробуй использовать его, как полагается.
P.S. Модель может быть реализована совершенно по-разному. Вон наборы ф-ций в пространстве имен articles и collection – это тоже модели. Ты можешь использовать для модели, представляющей собой набор однотипных сущностей (таблицу), обычный объект (т.е. динамический экземпляр класса).
Последнее редактирование:
firep91613
Новичок
Ок. Я понял.
Считается ли дурным тоном инклюдить $dbconfig в конструкторе? Вместо того, чтобы передавать его. Просто этот конфиг все портит, только под него и надо подстраиваться.
Класс пагинации это зависимость? Сейчас я явно создаю экземпляр в экшене контроллеров, в которых она нужна. Это плохо?
Считается ли дурным тоном инклюдить $dbconfig в конструкторе? Вместо того, чтобы передавать его. Просто этот конфиг все портит, только под него и надо подстраиваться.
Класс пагинации это зависимость? Сейчас я явно создаю экземпляр в экшене контроллеров, в которых она нужна. Это плохо?
miketomlin
Новичок
Обычно в моделях используются не конфиги, а соединения. Причем обычно используется «общее» соединение, но лучше иметь возможность выбирать соединение.
Я в теме уже писал, для меня норм. внедрять соединение без его явной передачи в параметре конструктора и т.п. ($db = db()). Но с точки зрения кем-то там сформулированных принципов ООП-разработки – НЕ норм.
miketomlin
Новичок
А зачем модели пагинация? И пагинация, и модели просто принимают одинаковый параметр pageNumber (если модели используют номер страницы, а не смещение). Обратная зависимость есть – pageCount, но ты, правда, можешь в контроллере обратиться к модели для получения pageCount, а потом передать его пагинации. Вообще пагинация – довольно простая вещь (и в проекте обычно используется один тип пагинации), так что мне достаточно обычной ф-ции:
PHP:
list($first, $last) = pagination($pn, $pc);Оформление при этом находится в шаблонах/вьюшках, как это и должно быть.
Последнее редактирование:
firep91613
Новичок
Я до этого так же делал. Но теперь хочу все согласно DI.
Не в модели, в конструкторе класс Db.
Контроллеру. У меня сейчас без зависимости. Я просто создаю в контроллере инстанс и передаю виду.
firep91613
Новичок
Читаю книгу М. Зандстры - PHP 8: объекты, шаблоны и методики программирования. В шаблоне DI он предлагает использовать XML-файлы и атрибуты. В XML-файле прописывает абстрактные классы и соответствующие им инстансы. В конструктры классов добавляет атрибуты и анализирует их. Мне интересно, в реальных проектах используется такое? Первый раз такое вижу...
Эта книга какого года?
Да, все используют. У тебя помимо рефлексии, должен лежать ещё где-то конфиг, это может быть php,xml, yaml или в атрибутах. У тебя же не всегда зависимость с одной реализацией.
Valick
Новичок
На самом деле книгу М. Зандстры - "PHP 8: объекты, шаблоны и методики программирования." считаю лучшей книгой для базового освоения ООП. Читал её давно в электронном виде, а несколько лет назад увидел свежее 4-е издание в книжном магазине и не удержался от покупки. Книгу нельзя назвать книгой для начинающих, так как ООП это в принципе не для начинающих. И уж тем более эту книгу нельзя назвать "Сборником рецептов" для копипасты "х.х. и в продакшин". Код в книге только для объяснения конкретной задачи (паттерна). Кстати чтение книги и написание этого кода собственными руками гораздо более эффективно нежели просто чтение с подходом "да тут всё ясно".
Одного Зандстры не достаточно, для выхода на более высокий уровень есть другие книги (TDD, DDD и тд), и их тоже придётся читать.
Одного Зандстры не достаточно, для выхода на более высокий уровень есть другие книги (TDD, DDD и тд), и их тоже придётся читать.