вообще php код держать в публичной директории не комильфо, вот смотрите https://github.com/dimaxz/frameworkless/blob/maste... команда php app/command packages:install переносит публичные файлы пакета в публичную директорию
не знаю у меня не было проблем с установкой модуля через компосер и переброской публичных скриптов в публичную директорию сайта, и не нужно избавляться от перенесенных файлов в vendor, вообще там удалять не чего не нужно.
по поводу произвольной директории вот что гуглится https://getcomposer.org/doc/faqs/how-do-i-install-...
я думаю схемы есть разные у каждой есть плюсы и минусы, посмотрите как сделано в других CMS
очень странно, в компосер можно вписать любую структуру, и еще лучше с стилем PSR так будет лучше поддерживать, если вы переживаете на счет публичных файлов css,js и тд. это тоже решаемо. компосер в данном случаем дает дает схему обновления с учетом версионности, автозагрузку классов, и возможность выполнения bash скриптов
на счет датамаппера я согласен, я тоже приветствую такой подход и даже писал свой велосипед https://github.com/dimaxz/SimpleORM, но просто так замапить объект по простому не получиться так как нужно думать о таких вещах как транзакционность, связи с другими объектами (Relationships), их сохранение или выборка, кеширование, валидация и многое другое.
ну ок. выберет щас модели создаст классы нашпигует методами работы с хранилищем, нашпигует бизнес логикой, добавит валидации, и создаст зависимости от других моделей, в итоге напишет вопрос, а куда выделить бизнес логику, писать в модели или в контроллере или а где валидировать в контроллере или модели, а как избавиться от зависимостей?
поэтому меня удивило следующее:
Понятие "модель" может сильно отличатся в различных системах и подходах, но грубо говоря нужен мэпепер.. все, вы навязываете свой какой то маппер., хотя если вы бы имели ввиду Entity + DataMapper я бы согласился
скорее всего должно звучать так:
Понятие "модель" может сильно отличатся в различных системах и подходах, но грубо говоря нужен Activerecord
так как он прост в использовании но имеет все знакомые минусы.
агрегация по простому возможность сущестования одного класса без второго, например в модель мы можем просто внедрить заглушку (например при тестах) например new Model(new DataBaseMock)
композиция же наоборот не позволяет одному классу работать без другого.
Например, оригинал db.config.php --> db.config.php.example
на самом деле это делается по другому, у проекта создается файл с конфигурацией .env
в котором перечислены все настройки сервера, а также режим работы develpment, production
конфигурация codeigniter использует настройки из этого файла
и .env соответственно не заливается в репозиторий https://github.com/vlucas/phpdotenv
Подключаемся к серверу, определяем папку.
Получаем последние N писем (можно вытаскивать все за раз, можно порциями), с основной информацией кроме содержимого. Проходим по данному массиву с фильтрацией по отправителю, теме и тд.
Для получения детальной информации о письме шлем запрос на получения полной информации о письме с содержанием, вложениями по uid.
формы для админки и публички строятся на основе одного и того же конструктора форм, не хотелось бы разделять реализацию админки и публики так как это может значительно усложнить разработку функционала.
