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

[miketomlin]

Под спойлер все выкладывать?

Не надо. Может, новый аккаунт создать? Хотя кому надо, тот и так скачает.

Лучше демку выложи. Я, например, люблю покликать по сайту, прежде чем смотреть его исходники. На самом деле оцениваю адресацию и т.п.

 

[firep91613]

Я решил сделать класс View. Ну через виды и шаблоны вобщем. На главной странице и в результатых поиска дожен быть сайтбар, а на странице конкретного поста - не должен. Как лучше сделать шаблоны? Для главной и результатов поиска сделать один шаблон с сайтбаром, а для поста без? Или основной шаблон надо собирать по кускам, ну т.е. подключить шапку, подвал, по условию сайтбар?

 

[miketomlin]

На главной странице и в результатых поиска дожен быть сайтбар, а на странице конкретного поста - не должен.

Обычно делают наоборот Или везде одинаково (в плане сайдбара), чтобы юзеров не напрягать. Сейчас кстати можно везде одинаково без сайдбара.

Для главной и результатов поиска сделать один шаблон с сайтбаром, а для поста без? Или основной шаблон надо собирать по кускам, ну т.е. подключить шапку, подвал, по условию сайтбар?

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

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

 

[firep91613]

Обычно делают наоборот Или везде одинаково (в плане сайдбара), чтобы юзеров не напрягать. Сейчас кстати можно везде одинаково без сайдбара.

Ну я понимаю, так проще. Я просто специально так выбрал, ну чтобы посложнее было.

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

Я еще не знаком с кешированием. Мне бы по проще для начала, но более-менее прилично

Вот, допустим, как делают. Есть главный шаблон, ну т.е. в него выносятся все неизменяемые части на всех страницах. В моем случае это шапка и подвал. А дальше уже в главный шаблон вставляются соответсвующие виды, ну просто меняется контентная часть. Если я сделаю, главный шаблон с шапкой и подвалом, а в виде, буду или не буду инклюдить сайтбар в зависимости от вида - это не совсем убого?

Вот, к примеру, для главной страницы вид сделать такой:

<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]

Я еще не знаком с кешированием. Мне бы по проще для начала, но более-менее прилично

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

if (!$sidebar = file_get_contents(PATH.'cache/sidebar'.quantum())) {
    $sidebar = '';
}

Ф-ция quantum указывает на номер копии (можешь пока убрать эту концовку).

Если чистого статика недостаточно, оформи сайдбар в виде подключаемого файла (как ты собственно и сделал) и получай в контроллере все необходимые ему данные. Концовка _once в данном случае не нужна. И в шаблонах можно даже include использовать (но смотри сам: иногда выбор между include/require определяется логикой выполнения).

Если я сделаю, главный шаблон с шапкой и подвалом, а в виде, буду или не буду инклюдить сайтбар в зависимости от вида - это не совсем убого?

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

ПРОСТО ДЛЯ СПРАВКИ:
Бывает такая фишка, как отдельный код сопровождения (обслуживания) каждого «главного» шаблона. Если делать совсем по-простому, «главный» шаблон может выглядеть так:

<?php
    // код сопровождения
?>
<!DOCTYPE html>
и т.д.

«Главный» шаблон выбирается в частном. Сначала выполняет частный шаблон, а потом результат его выполнения втыкается в соотв. «главный».

Бывает даже код сопровождения у каждого блока страницы. В этом случае можно было использовать непосредственно код сопровождения сайдбара, а не выносить подготовку сайдбара в код сопровождения «главного» шаблона с сайдбаром.

Если все это пока сложно, еще есть подгрузка сайдбара и т.п. AJAX'ом

 

[miketomlin]

Еще лайф хак: php-вставки с управляющими конструкциями лучше писать без отступов. Если оч. хочется, можешь нужные отступы после <?php делать.

Это чтобы «чистый» (т.е. красивый) статик генерировался.

Вставки с выводом (<?=) аналогично, если ты не уверен, что всегда будет выводиться однострочное значение, т.е. без переносов строк. Можно вообще всегда писать без отступов. Короче чтобы не было в результате такой хрени:

    текст текст
текст текст
текст текст

 

[firep91613]

Что вы думаете о подходе, когда модель становится таблицей из БД, а объекты записи из таблицы?

 

[miketomlin]

В каком смысле «объекты», ООП-ном? Если в смысле терминологии, то у нас обычно таблицу называют коллекцией, а отдельную запись – да, объектом.

P.S. Не любую таблицу называют коллекцией, например словарную, когда нет возможности редактировать ее отдельные записи, так и называют словарем.

А в ООП-ном смысле модель тоже представляется объектом, причем это часто более рабочий объект, чем объекты отдельных записей. Отдельные записи легко и массивами представлять.

 

[firep91613]

@miketomlin, как я понял, классы создаются по названиям таблицы БД и содержит статические методы для работы с таблицей, а объекты это экземпляры класса, которые содержат записи из таблицы, ну типо у каждого объекта своя строка из таблицы.

К примеру, есть таблица users, создается класс Users, у которого есть свойства, допустим, id, name, email (каждый экземпляр имеет свою строку из таблицы). У класса Users делают статические методы, достать всех юзеров, достать конкретного юзера и т.п.

 

[ksnk]

Таблицы далеко не однозначно отображаются в табличную структуру данных.

 

[AmdY]

@miketomlin, как я понял, классы создаются по названиям таблицы БД и содержит статические методы для работы с таблицей, а объекты это экземпляры класса, которые содержат записи из таблицы, ну типо у каждого объекта своя строка из таблицы.

К примеру, есть таблица users, создается класс Users, у которого есть свойства, допустим, id, name, email (каждый экземпляр имеет свою строку из таблицы). У класса Users делают статические методы, достать всех юзеров, достать конкретного юзера и т.п.

Зачем тебе статика и геморой с ним. Чем тебя обычные классы не травятся, которые нормально передаются через DI и код получается прозрачнее с конструктором, наследование, перегрузкой методов, приватными-протектид методами и т.д.
Сам по себе Active Record нормальный и подходит для большинства кейсов, хотя у нас принято ругать. Но писать его с нуля - это жесть, может ещё что-то на уровне первой коханы получится написать без опыта с пару попыток.

 

[miketomlin]

классы создаются по названиям таблицы БД и содержит статические методы для работы с таблицей

Статик – это почти процедурка (процедурный стиль) с некоторым подобием инкапсуляции данных (разделением данных между несколькими связанными ф-циями). Я понял: ты насмотрелся ORM'ов вроде Элеквента (КуэриБилдер, РедБинПХП и т.п. тоже не сильно отличаются). Почти с таким же успехом можно использовать articles\all() и т.п. или collection\all('articles') и т.п. Это чистая процедурка (у нас такого полно). Но раз уж ты взялся за ООП, пробуй использовать его, как полагается.

P.S. Модель может быть реализована совершенно по-разному. Вон наборы ф-ций в пространстве имен articles и collection – это тоже модели. Ты можешь использовать для модели, представляющей собой набор однотипных сущностей (таблицу), обычный объект (т.е. динамический экземпляр класса).

 

[firep91613]

Ок. Я понял.

Считается ли дурным тоном инклюдить $dbconfig в конструкторе? Вместо того, чтобы передавать его. Просто этот конфиг все портит, только под него и надо подстраиваться.

Класс пагинации это зависимость? Сейчас я явно создаю экземпляр в экшене контроллеров, в которых она нужна. Это плохо?

 

[miketomlin]

Считается ли дурным тоном инклюдить $dbconfig в конструкторе? Вместо того, чтобы передавать его.

Обычно в моделях используются не конфиги, а соединения. Причем обычно используется «общее» соединение, но лучше иметь возможность выбирать соединение.

Я в теме уже писал, для меня норм. внедрять соединение без его явной передачи в параметре конструктора и т.п. ($db = db()). Но с точки зрения кем-то там сформулированных принципов ООП-разработки – НЕ норм.

 

[miketomlin]

Класс пагинации это зависимость?

А зачем модели пагинация? И пагинация, и модели просто принимают одинаковый параметр pageNumber (если модели используют номер страницы, а не смещение). Обратная зависимость есть – pageCount, но ты, правда, можешь в контроллере обратиться к модели для получения pageCount, а потом передать его пагинации. Вообще пагинация – довольно простая вещь (и в проекте обычно используется один тип пагинации), так что мне достаточно обычной ф-ции:

list($first, $last) = pagination($pn, $pc);

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

Оформление при этом находится в шаблонах/вьюшках, как это и должно быть.

 

[firep91613]

Я в теме уже писал, для меня норм. внедрять соединение без его явной передачи в параметре конструктора и т.п. ($db = db()).

Я до этого так же делал. Но теперь хочу все согласно DI.

Обычно в моделях используются не конфиги, а соединения.

Не в модели, в конструкторе класс Db.

А зачем модели пагинация?

Контроллеру. У меня сейчас без зависимости. Я просто создаю в контроллере инстанс и передаю виду.