Рад за вас)), однако правила для диплоя - это неотемлемая часть вашего проекта. Даже если вы подключите какую-то систему continuous integration то правила сборки и диплоя вам придется прописать.
Часто бывает, что весь диплой сводится к простому баш файлу. При этом через CI систму запускается тот же баш файл.
Роман
> Всегда jsonapi иначе расценивается как баг, со связями и т.д.
Конечный формат не имеет значения, важно - преобразование данных, например: нужно отдать данные о пользователе, фактически вы получите entity user -> достанете с него поля, которые можно и нужно отдеть -> запихнете в массив и сделаете json_encode. Я говорил об этом.
> Хочу повесить на хук типа "afterResponse", пока не успел дочитать маны по Симфони на эту тему.
Явное - лучше не явного. Чем меньше неявной магии вы будете использовать - тем лучше.
Роман
> Что-то в духе `\Acme\Frontend\ResponseRenderer\JSON::renderCollection(\Acme\Domain\Entity\BaseCollection $collection)
Явное - лучше неявного. \Vendor\Project\AppBundle\Api\V1\Serializer\MyEntitySerializer.
Для простых ответов - достаточно в экшне сделать.
> Кажется, я вас не понял – поясните чуть подробнее?
Событийная модель добавляет неопределенности в процесс выполнения. Вот поймали вы исключение в листнере при обработке ивента 4-го уровня вложенности и вас такая херня скорее всего расстроит))
Посему если есть возможность выполнить функциональность без ивент-лупа - очень вероятно, что это будет лучшим решением.
> Отказаться от событийной модели в пользу какой другой?
Я не говорю отказаться полностью, но там где возможно. Делать явные обработки выше уровнем.
Пример: при регистрации пользователя нужно отправить сообщение на почту. Лучше создать сервис, который будет регистрировать пользователя И отправлять сообщение в очередь на почту, чем привязываться листнером на создание этого пользователя.
> Где почитать (или по каким ключевым словам искать) способ сделать плоским наследование групп типа "manager может делать всё то, что и customer, но ещё вон то и вот это"? symfony.com/doc/current/security/voters.html - штука очень гибкая, но с проверкой прав нельзя забывать то, что это может быть очень затратно по ресурсам.
Например при чтении большого количества записей И уровне доступа к конкретным объектам, а не типам объектов - универсальное решение будет капец каким медленным так как нужно будет в отдельности проверить доступ к каждому ресурсу, а если их 1кк?)) Для подобных кейсов - acl лучше выполнять отдельно для каждого уровня.
Пример: человек может смотреть записи свои И доступные для своей группы, а нужно получить список доступных для просмотра с пагинацией. В таком случае не стоит обращаться к acl уровню, а джойнить таблицы с доступами при выборке.
> Резоннее и более поддерживаемо будет дублировать все права?
It depends. Нужно полностью понимать, какие требования к ACL у вас, что бы дать ответ. По хорошему: если можно без каскадного изменения прав - лучше без этого.
> Видимо, я попадаю в те 10%?
Я не совсем имел то ввиду. Если юзер группы статичны - замените это понятие на роль. При проверке прав к конкретному полю - проверяйте наличие роли. Опять же, если это не противоречит вашим бизнес требованиям.
Вот вам пример, как это может выглядеть: https://help.github.com/articles/repository-permis...
> Или есть best practice с реализацией проще?
ACL может быть либо хроновый, либо не существующий, увы))
> По поводу скопов прав, коли они могут помочь решить сценарии, направьте меня, пожалуйста, в симфони-доки/библиотеку/гугло-запрос для дальнейшего изучения? https://developer.github.com/v3/oauth/#scopes
Дмитрий Евграфович Есть в планах записать рекомендаций на youtube да времени катастрофически нет((
Максим Зайцев
> не вижу его применения в рамках реализации элементов CMS системы.
В том то и дело, cms - это зависимость проекта на базе этой cms. Да, вы можете отойти от этого принципа, но в этом случае проблем "не работает после обновления" будет на порядки больше.
Вот вам пример: пацанчеки из opencart в свое время не позаботились надлежащим образом об зависимостях (возможно на данный момент эта проблема и решена, не в курсе), результат: да, есть куча дополнений, которые прямо поверх кода устанавливаются, а дальше начинается капец так как затрагиваются системные части, результатом подобного подхода являются конфликты между разными дополнениями.
> На основе их я реализовал модуль для сайта "Shop" и положил его в .\frontend\modules\Shop\<файлы модуля>
В том то и дело, что вы привязываетесь к корневому каталогу, что неверно.
vendor/< vendor >/< projectName-ExtensionName >/< файлы зависимости >
За счет этого вы получите такое: бизнес логика зависимости существует в едином экземпляре, но в случае чего ее можно уже в приложении подстроить под себя.
> а шаблоны которые с мобулем идут их тоже туда пихать?
Путь к шаблонам по умолчанию vendor/< vendor >/< projectName-ExtensionName >/... Однако это настройка зависимости, которую можно переопределить.
При этом в проекте сайта непосредственно можно спокойно указать свой и юзать кастомную тему.
Статические файлы можно либо скопировать, либо слинковать. Это дело можно реализовать с помощью: https://getcomposer.org/doc/articles/scripts.md
Хотя... Лучше конечно не выдумывать костылей и заюзать twig, или smarty, которые и так это сделают, только лучше и быстрее))
> как я понял мне предлагают все файлы класть в папку vendor\zaitsev\modules\Shop\<файлы модуля> но блин тогда все мои файлы будут лежать в папке vendor, а что будет лежать в других файла?
Э-не. Еще раз, вы путаете понятия "зависимость" и "файлы проекта". Файлы проекта лежат не в vendor, их задача - реализовать конечную БЛ проекта. Задача зависимостей - максимально упростить этот процесс.
> накой мне все элементы валить в composer если например шаблоны я бы хранил вообще отдельно что вполне логично
Шаблоны конечного проекта - в каталогах конечного проекта. Шаблоны зависимостей - в каталоге vendor/...
Пример: у вас есть форма авторизации. В вендоре вы прописываете БЛ, там же делаете базовый шаблон. Если при подключении зависимости вас уже устраивает эта форма - зашибись. Если не устраивает оформление - ок, переопределите тему в своем проекте, но не в зависимости.
> да и шаблоын могут для одного и тогоже модуля быть от разных поставщиков.
Дык это замечательно! У вас есть базовая зависимость, возьмем туже форму авторизации. Есть 10 поставщиков оформления. В вашем проекте вы указываете в настройках подключаемой зависимости, где брать шаблон, в этом случае он будет из каталога vendor/< поставщик >/...
> А если это делать в рамках проекта, то есть не размещать файлы проекта в том чесле модулей в папке vendor, то тогда встает вопрос а как решить ту самую проблему с наименованием папок если два разных чувака работая над проектом независимо решили запилить одноименный модуль?
Чувак 1 создаст проект < Чувак1 >/< Проект >
Чувак 2 создаст проект < Чувак2 >/< Проект >
В каталоге vendor у вас будет И Чувак1 И Чувак2
То, какой модуль и как использовать уже будет определяться в вашем проекте.
alst161
> Как правильно реализовать проверку на новые?
> index0h зачем мне брать контент новости?
Вам нужен контент новости, что бы проверить, а новая ли она, ваш К.О.
> просто я не хочу их хранить в базе и каждый сверять с базой.
Урлы имеют очень неприятные свойства: меняться и протухать. Так что я бы на них не очень ориентировался. В случае репостов: у вас есть N копий одной и той же новости, слегка измененных под абсолютно разными урлами.
> как вариант думал при первом запуске сверить по бд и записать в массив все урл, а потом на каждой новой проверке по массиву проверять.
Если источников данных будет много - основной вашей проблемой будет не скорость обработки, а сетевая составляющая, которую можно решить горизонтальным масштабированием. При этом БД будет точкой синхронизации. Рано, или поздно узким горлышком станет уже БД, потребуется синк через что-то более быстрое, redis например.
FireGM
> да ладно, ведь человек спросил про проверку на новые новости, надо сразу советовать phantomjs, nodejs и docker.
Если бы автор спросил: мне нужны все новые урлы - ему бы такая фигня возможно подошла: stackoverflow.com/questions/2804467/spider-a-websi...
Но он спросил про новые новости, а "новость", как правило - это некий текстовый контент и определить новый ли он можно за счет разницы с уже существующими.
Для проверки времени попробуйте прогнать через ab, это более надежные результаты, чем через браузер.
Что касается инициализации для базовой сборки с прогретым кэшем, 80ms - это дохренища. Еще раз, убедитесь, что кэши не сбрасываются.
На всякий пожарный: посмотрите общую загрузку системы: CPU, RAM, HDD IO.
Если на момент запроса растет HDD IO И кэши не сбрасываются - перепроверьте, включен ли OPCache.
Если RAM уже в swap, или CPU сожран - разгрузите систему, у вас слишком много всего запущено.
Далее смотрите xhprof.
-- --
Вообще на инициализацию (prod) столько времени - это нормально только в том случае, если у вас огромное количество сервисов требуются сразу при запросе. В этом случае поможет разве что использование RPC через сервер очередей.
Из-за обилия магии в ларавеле вы еще хлебнете горя при дебаге. Если есть возможность - лучше откажитесь от этого фреймворка в пользу Symfony. Так же рекомендую почитать: Попросили проверить код, на что смотреть нужно? там про ларку больше
Михаил Вы же не указали, что это Yii::$app->request->post(), я этого тоже в вопросе не увидел.
По хорошему вам стоит передавать те данные, которые необходимы сервису. Если это именно RAW данные из POST, пусть и в обертке - то их и передавайте.
Если же данные вы уже проверили, они корректные и по ним вы уже получили модели - тогда не накладывайте на сервис дополнительных требований по валидации пользовательского ввода, а только передавайте модели.
Вы не правильно поняли мой ответ. Ни одна из CMS вам не подойдет.
CMS - это такая хрень, которая подходит только в случае, если она полностью решает поставленную бизнес задачу. Иначе вы будете с ней "воевать". Я не просто так указал действительно сложные задачи, которые вам так, или иначе придется решать на подобном проекте. Они дофига не тривиальные, а добавив сюда еще "войну" с CMS вы сделаете только хуже.
CMS подходит, если:
Вам нужен блог по быстрому - WP. Да, на WP и электронные магазины пишут, но это не целевое применение.
Вам нужен побыстрячку эл. магазин - prestashop.
Нужна визитка - MODx.
Нужен форум - BBForum
Еще раз, то, что на CMS пишут проекты не вкладывающиеся в назначение этой CMS - это вовсе не демонстрация, на сколько крутая CMS, ближе другое, увы: это как жрать песок и говорить, что вкусно.
Для не тривиальных проектов - фреймворки. Для очень специфических проектов, где даже фреймворки не помогают экономить время - нейтивный код.
Миша Коган Если вы уже решили сделать скидку - покажите это пользователю: зарегистрированным скидка 20%, этого достаточно. Поп-апы же - это игра с огнем на заводе фейерверков.
Если для товаров есть возможность поторговаться: сделайте клавишу "хочу дешевле", или "торг уместен".
Дмитрий
> это, на ваш взгляд, "вариативность"?
Чуть ниже я написла, что использование супеглобальных переменных - в принципе плохая идея.
> разницы, что именно использовать (если не обусловлено логикой приложения) нет
разница есть, причем существенная. Подвязываясь на суперглобальные переменные - с консольным запуском будут проблемы.
Дмитрий
Потому, что:
* api, которое вы предоставляете в данном случае более вариативно. Это приведет к ошибкам и костылям.
* супер глобальные переменные (просто глобальные - тоже) в принципе не стоит использовать так как они доступны на запись.
* покрывая тестами код вы обнаружите, что ваши супер и просто глобальные переменные - это внешние неявные зависимости. Как следствие код может менять свое поведения основываясь на этих самых неявных зависимостях. Как результат - ваши тесты будут давать ошибочно-положительные результаты.
* использование $_REQUEST примерно значит: да мне в принципе по боку, как придут данные, как следствие там, где вы рассчитываете на POST может придти GET и сломать вам часть обработки, просто потому, что вы понадеялись.