Ну что, вроде все ок, если что вылезет поправим в следующих задачах

но мысль о src/ViewModel/ControlButton ,будем делать в tndt-42

Я конечно понимаю, что задача уже разрослась, но мысль о src/ViewModel/ControlButton не идет из головы, может не дожидаться отделения Presentation

так, конфликты мы вроде разрешили, в процессе теста выяснили, что улучшение в контролах страницы документа сломала нам модальное окно с подтверждением

Мы так красиво свернули проверки в tndt-134, что не понятно как теперь их сделать в здесь, с учетом разной логики в DocEvent и DocChangeStateEvent и аналогично TaskEvent и TaskChangeStageEvent

А да, и limit отменить, или сделать большим, записей в 100. Вот здесь у меня 20 коментов, это сложная задача. По этапам задачи туда сюда прыгать то же будут редко, так что к количеству комментов добавляются 4-6 активностей этапа. Т.е. 100 записей очень редкие задачи будут превышать, а те, что будут будут превышать очень старыми и малоактулаьными записями. Думается 100 хорошее число. А пагинацию отложим на дальнее потом

Не забыть свой контракт евента перенести аналогично tndt-134

С другой стороны активность оставил комментарий перед закрытием задачи можно и оставить. До те пор пока мы не научимся делать активность вида Закрыл задачу (сменив этап на и оставив комментарий: такой)

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

Например человек закрывает задачу и оставляет комментарий к закрытию.

• вызывается TaskService->closeTask
• вызывает евент TaskClose
• оставляет активность task.close
• вызывает CommentService->addComment
  • вызывает евент CommentAdd
  • оставляет активность comment.add
• вызывает TaskStageService->changeStage
  • вызывает евент TaskChangeStage
  • оставляет активность task.changeStage

Была мысль распространить область приложения vue и на сам контрол табов, чтобы при переключении не было релоада страницы. Но тогда нам на обоих страницах нужно будет отрисовывать комментарии (они же не ajax), и варганить этот виджет весьма не просто передавая туда горы кода из twig. Пок аотложили на момент переделки комментариев на ajax

Ну вот, с виджетами динамичность приехала. Осталось

• пагинация бесконечной догрузкой (этож помимо лимита надо и офсет готовить, может вынести отдельно)
• доп. информация об активности, хотя бы в виде неспецифичного json, просто чтобы выводить её иначе.
• А еще вот тут https://adminlte.io/themes/AdminLTE/pages/examples/profile.html в старом adminlte таки нашелся таймлайн, не очень нам подходящий, но все же, может таки? Или ждем tabler, все равно он все наши усилия по верстке сведет на нет

Здесь же попробуем сделать попроще, например обернем в try-catch и вернем как ответ

Неожиданная проблема. ErrorController должен знать какой роут не удался, html или ajax. И, в зависимости от этого вызывать разные ErrorController с разными ответами, или в виде html-страницы, или в виде json-ответа, с текстом ошибки. Это явно вылезает за границы и уходит в tndt-135

По итогу передаем в виджет в action (по аналогии с формой), url к данным, и виджет уже делает запрос на него. Все, ок, теперь виджет отображает данные с бека. Дополнительно и виджет отображения блока пользователя. Так что все движется хорошо, осталось спинеры, ошибки сделать. hasMore и пагинацию в целом можно отложить в отдельную задачу (или сделать, как пойдет)

С другой стороны, мы же в форму в поле actions проставляем url обработчика. И в ссылку url целевой страницы. Почему же в тег виджета не проставлять url откуда брать данные? Причем ему тогда даже не нужно знать эти subjectType, subjectId, он просто принимает url, а его можно убдет и поменять потом, с int db_PK на string buisnessLogic Id например taskId

Интересный вопрос, а как мы vue-виджету передадим на какой роут обращаться за активностью?

• захардкодим внутри виджета - но так у нас будет два места с маршрутами, и если мы что поменяем в routes.yml, придется и в виджетах менять.
• передадим в теге - но так нам придется в каждом месте, где мы рисуем виджет передавать путь до роута.

И так нам удалось вывести активность. Пока не подгружающуюся динамически, пока столь же некрасиво, как коменты, но уже модульно, с ощущением, что мы будем делать новые компоненты.

Мало нам остальных вопросов по активности, и монструозности предстоящего рефакторинга, мы сюда таки добавляем vue. Посмотрим насколько это будет успешно

https://ru.vuejs.org/v2/guide/components.html где-то тут ответ. Или https://ru.vuejs.org/v2/guide/components-props.html или даже тут https://habr.com/ru/companies/ruvds/articles/512658/

Сегодня мы ничего не закоммитили (ночные не в счет комиты, они ко вчера относятся), зато начали разбираться в vue.js, добавили первый vue-виджет, создали первый vue-компонент отображающийся в этом виджете, и пытаемся выяснить, как в этот компонент передать данные со страницы, т.е. из рендера твига. Все закопано в передачи данных из точки подключения vue в экземляр vue, а из экземпляра vue в компонет vue.

Вопрос, как по активности откомментировал задачу найти этот самый коммент оставим на tndt-132, а здесь будем просто отмечать работу.

Решили пока попробуем хешем, посмотрим как будет получаться. Если все ок, стоит поставить задачу и коменты туда перевести.

Таки начали. Итак первый вопрос, PK у нас будет int’ом или hash? Активити будет создаваться весьма активно, много, и старые убудут удаляться когда база разрастется.

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

• Вобще это не выглядит очень сложным (особенно если не выводить в интерфейс).
• Выглядит очень желанным побыстрее начать собирать статистику действий и историю перемещения задач по этапам

Я умаю в минимальном варианте это стоит сделать в ближайшем релизе, может быть даже в этом, может в следующем, если он будет быстрее чем месяц работы

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

Это и подогреет интерес к продолжению работы над проектом.

Еле нашел задачу. уже было думал, что создал последующую, а эту базовую не создавал. Надо бы переименовать.