@victorib_us: да не парьтесь вы, если собираетесь AMD-шную графику покупать и в игрушки играетесь, можете взять какой FX. Вам его хватит на пару тройку лет. Мне вот AMD A6 в ноуте хватает пока.
@vasIvas: что? Нет, я про символы (Symbols). А на счет WeakMaps не уверен что они заимплеменчены (пока не нашел времени разбираться с ES6). Вы точно запускали node.js с флагом --harmony?
@nepster09: Изначально задумывалось, что админка и пользовательская часть будут двумя разными приложениями. То есть два инстанса AppKernel, две точки входа (или через окружения но это уже странно). Конфиги шарятся (благо есть инклуды) и т.д. Но как-то так вышло что почти никто так не делает. А если и делает, то по довольно веским причинам (конфликты какие-то, или изза вопросов оптимизации). Я лично ни разу не видел и не применял такой подход, так как пока небыло необходимости.
По сути... Можно просто контроллеры для админки вынести в отдельный нэймспейс, разруливать все раутингом и компонентом security. Вариантов как разделить масса. Опять же большинство делают AppBundle и AdminBundle (и возможно третий куда выносят общие части). Решать вам. Опять же лучше попробовать и потом переделать чем рассуждать.
Скажем в приведенном вами примере структура проекта это последнее на что стоит обращать внимание. Куда грустнее когда вы посмотрите на контроллеры. В идеале вы не должны вызывать в контроллере доктрину. У вас же есть DI, сервисы, сборка контейнера, агрегация сервисов по тегам, ленивая инициализация сервисов (если думать о производительности).... Можно реализовать такую крутую архитектуру, причем с минимумом бойлер плейт кода для разработчика...
Так что думаю стоит потратить время на изучение DI и посмотреть как кто использует, зачем нужны скоупы, как собирать сервисы по тегам и где это может пригодиться. Конфигурация бандлов - тоже стоит глянуть что и как. Как минимум пригодится когда вам придется использовать чей-то плохо задокументированный бандл - влез в файл DependencyInjection/Configuration и документация не особо нужна.
Затем можете сконцентрироваться на HttpKernel, маршрутизации и т.д. Security и формы можно поищучать уже когда возникнут задачи с оными.
@nepster09: я бы порекомендовал вам посмотреть проекты ваших коллег. Мало кто использует структуру которую я привел. Сейчас вот вышла книга по бэст практисам, может ситуация поменяется. Просто для большинства проще сделать свой бандл AppBundle и там все фигачить, ибо с framework-standard-edition это проще (нету проблем с конфигами, ничего не нужно прописывать и т.д.). С другой стороны даже если у вас код внутри какого-то AppBundle или вы разделяете на CoreBundle, AdminBundle и AppBundle (еще может быть ApiBundle) ситуация не сильно меняется. Просто все становится разбросано по бандлам и иногда не очень очевидно что куда ложить. В итоге большая часть всего выносится в CoreBundle а контроллеры и вьюшки люди пихают по другим бандлам....
Разберитесь лучше с раутингом, Dependency Injection и циклом жизни запроса.
@WebDizi: промисы как по мне универсальнее. В той же Q есть Q.denodify. Если честно я уже давно не видел что бы использовали async.js. Из того что видел больше как раз таки в контексте циклов и больше для "распаралеливания".
@nepster09: нет, вы и в Yii значит не совсем правильно модули использовали. Смысл модулей и бандлов в том что бы разделить функционал на тот что будет реюзаться и тот что будет использовать функционал предоставляемый бандлами.
Давайте пройдемся по вашему примеру.
У нас есть функционал пользователей... тут можно реализовать базовую модель, базовый менеджер пользователей, сервисы для восстановления пароля, базовые правила валидации. Никаких Entity, только Model и возможно абстрактный класс Entity которые будет использовать ваше конечное приложение. То есть раутинг, контроллеры и т.д. в бандле имеет смысл создавать только если вы на 100% уверены что от проекта к проекту меняться это дело не будет (Либо можно что-то через конфигурацию бандла менять). Пример - FosUserBundle. В Yii идея модулей изначально была такой же, но что-то пошло не так. Как пример модуля для Yii - gii и их скаффолдинг, модуль по управлению правами пользователей (забыл название) и т.д. То есть то что будет либо использоваться нутром вашего приложения, на фронт не попадет, либо вообще какие-то дев тулы со своими специфичными маршрутами.
PagesBundle - можно опять же сделать базовую модель, менеджер мета данных, раутинг, переводы... Базовый функционал так скажем. Если у вас на всех проектах все одинаково - можно сделать все там и разрешить конфигурирование. Скажем туда можно запихнуть какую-нибудь интересную логику ресолвинга нужной статьи по URI на ивентах. Если логика нашего приложения подразумевает добавление какого-то поля, мы добавляем оный в классе энтити приложения, не модели бандла и радуемся.
Ваши бандлы потом можно будет сплитнуть в отдельный репозиторий и ставить через composer. Это удобно поскольку если вы закроете какой-то баг в одном проекте, сразу же закроете и в других.
Вы можете начать вообще без своих бандлов и потихоньку переносить туда все то, что повторяется из проекта в проект. Либо если вы знаете что у вас проекты однотипные и скажем штуки типа UserBundle и PageBundle можно реюзать, тогда вперед. Блог выносить в бандл уже сомнительно. Какой TaxonomyBundle возможно имеет смысл делать... но это уже вам решать, делать, использовать что-то готовое и т.д.
CommentBundle - тут вам решать. Можно сюда инкапсулировать базовые вещи, форм тайпы, валидацию и т.д Но этот бандл будет зависит от UserBundle и Blogbundle, что не хорошо. Либо вам нужно думать как отвязаться от конкретных бандлов и реализовать абстракцию для работы с комментариями.
Вообще я уже говорил, бандлы, модули это лишь средство, при помощи которого вы один и тот же код (не функционал заметте, а только основу для оного) выносите из проекта что бы было проще поддерживать и не писать что-то по нескольку раз. Если у вас проекты однотипные, можно больше выносить в бандлы. Если все проекты разные - делать бандлы более независимыми, что подразумевает что для приложения придется чуть больше кода писать...
p.s. И ради бога, не называйте сущности PostModel. Это просто Post.
@YourQuestion: supervisord сам будет следить. Вы просто добавляете в конфиги ваш джоб (что запускать, с каким приоритетом и т.д.) и он сам уже будет за всем следить. Почитайте документацию.
@ppa: ну то есть такие вещи как работа с git composer делает через эту штуку. Чисто теоритически можно ограничить prefere-dist и тогда можно обойтись без exec.... но это в теории...
@rmfordev: мне кажется у вас CMS головного мозга. Вы когда-нибудь работали с нормальными системами? Не на Yii или ModX а на нормальных системах. Которые реализованы по всем канонам, без тупых шаблонов на php, с автоматическим деплойментом, миграциями данных, тестами....
Вот честно, когда поработаешь с такими вещами потом на WP грустно смотреть. Я как-то помниться пытался прикрутить twig к wp - не помогло, всеравно боль и уныние.
