Так как у меня уже был проект на T4. Собственно он и будет подопытным. Это проект финальная домашка по курсу PHP2 полуторагодовой давности. https://github.com/Mike0712/phpT4.git В самом проекте ничего менять не будем, за исключением конфига, куда добавим значение domain и токен {{domain}}, так как нам это понадобится для выполнения задания.

Итак, устанавливаем phing. Просто скаичиваем файл phing.phar сюда же в нашу же текущую директорию build. Находясь в корне проекта вызывать phing будем командой:

php build/phing.phar -f build/production/build.xml

Дефолтной целью проекта указываем build. Таргет build сам по себе ничего выполнять не будет, в нем просто будут поочередно вызываться другие цели. Вообще отмечу что несколько перестраховался добавив таргет build, плюс остальные таргеты также выполняются по цепочки, пследующий зависит от предыдущего. В общем паранойя. Ну а в целом все вроде бы работает:

• проект копируется в директорию php3, которая расположена на уровень выше корня проекта (tmp.dir).
• проект копируется не в корень директории php3 а в отдельную директорию с имененем соответствующую времени в формате "Ymd_his".
• при копировании не копируются файлы директории build проекта (т.е. собственно конфиг для деплоя phing), так как это служебная директория, а также директория .idea, где содержится информация нужная для работы ide, что совершенно лишнее на сервере. Так же не копируется файл конфига protected.php, так как копируется он персонально в следующем шаге.
• далее копируется файл protected/config.php и в нем заменяется строчка {{domain}}. Несмотря на то, что данный файл не копировался, я добавил ему свойство overwrite=true. Навредить это не должно.
• ну и последним этапом создается симлинк, который создается только после успешной работы композера.

Сайт сделан на фреймворке Т4. Тема: Фансайт любимой музыкальной группы Сделан фансайт рок-группы Red Hod Chili Papers. Правда эта группа не является моей любимой, к её творчеству отношусь довольно прохладно, впрочем и отторжения никакого она не вызывает. Просто по ней нашёл подходящий контент. Хотя контентом я этот сайт так и не заполнил, только тестовые записи в базе данных для целей отладки. Что было сделано?

1. Были созданы миграции, всего семь таблиц.

2. Созданы следующие связи между таблицами. A). Таблица news (модель Articles) и таблица Category для разделения новостей на подкатегории,например Гастроли и новости из жизни группы. Связи BELONGS_TO, HAS_MANY. B). Таблица members (модель Artists) связана с biography по связи BELONGS_TO, HAS_ONE. С таблицей Status по связи BELONGS_TO, HAS_MANY. C). Таблица albums связана с songs по связи HAS_ONE BELONGS_TO.

3. Фронт енд. Вывод на страницы всех данных, создание меню для перехода по разделам. Верстка неважнецкая, надеюсь попозже доделать.

4. Админ-панель. Были 'обобщены' методы контроллера inset, update, delete, так чтобы можно было вносить и изменять данные в любую из таблиц. Конечно реализованный способ вызывает определённые сомнения в его правильности, однако отсутствие практического опыта по разработке админ-панели позволило реализовать только такой вариант. Вкратце суть. Структура контроллера не претерпела каких-то изменений по сравнению с нашим микрофрейворком, что мы создавали на курсе.

Есть страничка представления, которая просто отображает данные из таблицы БД. Разница в том, что в микрофреймворке мы отображали только данные из одной таблицы, и могли вручную задать данные для форм (контроллеры Insert, Update, Delete). Здесь же мы выводим все таблицы, под каждую создавая свой контроллер. При этом создавать под каждый контроллер отдельно служебные контроллеры (Insert, Update, Delete, Save) противоречит идее ООП. Конечно же контроллеры экшнов должны создаваться в единственном экземпляре и уметь обслуживать любые страницы админ-панели, отвечающие за вывод данных. Главная проблема, которую предстояло решить - передача данных в служебные контроллеры для вывода форм и собственно исполнения экшна. К сожалению не нашёл средств для передачи данных внутри самого фреймворка (может быть плохо искал). Поэтому использовал старый дедовский способ передачи информации методом post. Собственно, что мы передаём? Передаём массив с данными k = >v где k произвольное название колонок таблицы, а v имена колонок, как в БД (полагаю эту часть можно улучшить, автоматизировав получение названий колонок из БД. Получать эти колонки из метода модели findAll() плохая идея, так как мы ничего не получим, если таблица пуста. Буду искать другое решение), а также имя модели, которую нужно вызвать. Поскольку передавать мы будем массив, а метод post умеет работать только со строками, то мы 'упаковываем' наш массив в строку c помощью функции serialize. Для пущей надежности перекодируем нашу строку в формать base64. К слову сказать такой способ позволить передать методом POST хоть объект и ничего не потеряется. Впрочем можем ии методом GET (но это не наш метод). Чтобы не плодить химеры в экшнах, был предварительно создан служебный класс AdminDataHandler, чей объект мы создаём в контроллере и передаём туда наш массив вида 'название колонки' => 'название как в БД', а также Имя_класса::class, модель которого мы собираемся вызвать. И то что нам вернет метод AdminDataHandler::getData() мы передаём в шаблон. А вернет он нам массив с данными, которые мы аккуратно подставляем в нужных местах. Ну а дальше контроллеры Insert или Update (в зависимости того, что было вызвано) вместе с передачей данных сообщат методу Save в объект какой модель нужно 'вставить' данные. К слову сказать, при изменении данных мы также создаём новый объект, а не вызываем статитечкий метод findByPk($id) (передаём ему значение). Передо мной стояла диллема какой способ выбрать, я выбрал первый. Т.е. мы создаём новую запись, которая 'затирает' старую. При этом с помощью метода модели setNew(false) мы сообщаем, что запись не новая. Надеюсь это не является ошибкой, на мой взгляд такая логика несколько интереснее 'традиционного' изменения данных.

5. В шаблонах админ панели логики хоть и немного, но она есть. Общаая страница-слой Back.html - которая задаёт стиль страницы. Однако основной слой для админки это Table.html. По сути чтобы создать страницу, выводящую данные какой-либо таблицы достаточно только поименовать её как контроллер и втсавить единственную строку {% extends 'Table.html' %}. В Insert.html скрыто поле id, для того, чтобы у пользователя не возникло соблазна подставить id, на всякий случае этому полю уже присвоено null. Впрочем в шаблоне Update.html это поле пока скрыто, но может понадобиться его открыть. Ну например чтобы записать данные в пропущенный id (id строки, которую ранее удалили). Также до последнего было желание сделать странцы insert и update одной страницей (например update наследует insert). Но всё же логика контроллеров сильно отличается и я посчитал, что будет лучше сделать 2 разных шаблона.

Чтобы ещё хотел улучшить. Хотел бы чтобы в форме insert и ipdate в служебных полях выводилось не поле, куда нужно вписать номер id а select, куда бы подставлялось значение из связанной таблицы.

Что не успел сделать:

1. Добавление и удаление картинок на сайт через админку с жесткой привязкой к базе данных.
2. Вёрстка.

В целом это был интересный опыт! Ну и конечно ощущение, как много я еще чего не знаю.