Система загрузки и прикрепления файлов. Описание лежит в документа Upload файлов. По объему это вполне тянет на мажорный релиз, и стоит его начинать планировать.
Уже начинает её не хватать, для проекта дачи, в который надо прикреплять фотки чертежей и участка.
Будут сервисы:
Ну что, наконец ревью!
С атачментами пришлось делать такой же костыль, как и в комментариях, с фейковым полем ownerEntity которое не восстанавливается и БД и не является ленивой реляцией. Решено это будет в tndt-232
Вобще у запроса есть referer, то с какой страницы он пришел. Вот его инадо заюзать для ответа. По идее мы это даже реализовали, только не проверили. Потом полезли переносить логику в сервис и на этом остановились. Мне кажется половину действий аплоадера можно туда же. А если по итогу в аплоадере ничего не останется, то и ладно.
Теперь вопрос с ответом. Мы думали сделать просто, с перезагрузкой страницы из бекенда, но для этого нам нужно знать на какую страницу возвращаться. Тут или передавать её в бек, и там делать редирект, но это временный костыль. Или переделывать на полноценный ajax, с отправкой axios и принятием рещения на фронте. Но это долговато.
Диалог вызывается без jQuery и работает на наборе кнопок.
Еще раз засел за задачу. Опять поздновато, но все таки немного продвинулся, смог найти кнопки и повесить на них события через нативный js. Осталось через него вызвать диалог.
Уф, два вечера собирался, и вчера таки сел за задачу, правда поздно, в ноль часов, но хотя бы вспомнил на чем остановился.
И вот считанные дни до весны, а мы так и не сели за задачу. А ведь осталось немного. Очень бы хотелось выпустить релиз с ней до поездок на дачу.
По итогу решили оставить карточку файла в twig, а модалку делать средстваvb ванильного js (сейчас такая для закрытия задачи сделана на jquery, но с множественными кнопками не работает)
Жесть конечно, ради крестика и всплывающей модалки мы весь день страдаем по переносу части функционала во вью. Может отказаться от него в пользу ванильного js или alpine
Да уж, создание компонента и проброс в него уже имеющихся на странице сведений - такая мука. И все ради кнопки и диалога подтверждения удаления.
Да, эта задача еще на долго, несмотря на отпуск. Вот мы дочистили и улучшили загрузк уи показ файлов, а нам бы еще их удаление хотя бы.
Уф, ну теперь файлы аплоадятся куда надо, отображаются после, и скачиваются
Думаю надо сначала просто заставить его работать, а уже потом думать куда убиать создание путей, в File или в FileHelper и как называть
Пока рисовали галерею файлов решили, а может выйдет делать динамическую иконку. Размышления оформили как tndt-225
Что-то мы все запутали, и пришли к тому, что метод выдачи файла все равно должен сделать запрос к бд. Так что нет смысла в хелперах, давайте сущность файл будет сама генерить нужные пути. Впрочем хелпер может к ним добавлять путь в ФС или путь в от хоста.
Уф продолжили работу. Надеюсь за эту неделю доделаем таки.
Давайте на этом этапе откажемся от caption/description и отдельного окна их заполнения. Полезность их несколько туманна, по опыту что вики, что треккеров их почти никто толком не заполняет и мы врядли будем. Те важные файлы, к которым захочется добавить описание будут скорее документами типа файл. Ну а елси поймем, что вс еже нужно можно сделать отдельню задачу.
Добил таки открытие загруженного файла и начала приводить навороченное в порядок.
Кажется теперь дело не в путях, а в нейминге. Надо остановиться и доделать path, entityId и экранирование имени в файле
Врожде разрулили с путем к файлу, но кто-то его все равно не находит, пок пхп.
С учетом tndt-119 no не такой уж и постоянный. Вне зависимости от того как будет организован перенос, задача в новом проекте очевидно должна получить новый suffix и новый номер уже в составе нового проекта, а значит все привязано к задаче, должно привязываться или к id или уметь поменять свой номер. Wiki например без вариантов должна такое ловить, она показывает цифры пользователю, а потому должна оперировать номером. А вот остальные весьма не факт, что это стоит мнимого удобство понимания связи в бд. Так что это аргумент в пользу entityId
Пока что доделали вариант где в бд хранится номер сущности, а не её id, но название поля там entityId, а не entityNo, что путает. Т.е. надо или переименовывать атрибут, или переделывать везде на id. И тут скорее что удобнее и логичнее. а еще единообразнее, ибо комментари и активно крептся по id
новые задачи и идеи это хорошо, но мы так и не ответили на вопрос, мы будем крепить файлы по id сущности или по её номеру.
Начали делат галарею с циклом на стороне твига. В целом она даже выводит инфу в твиг, осталось нарисовать галерею.
Дуаю сейчас галерею будем делать с циклом на стороне твига. После если понадоится - переделаем.
Вот и закончился сезон, и уже месяц прошел с окончания. Хотелось бы продолжить. Судя по состоянию, базово система даже что-то загружает. но хотелось бы это показывать
вот и начался сезон, фестивалей в нем не мало, и месяц до платформы, так что кажется все это на паузе тепрь до конца июля
Идея пока не очень актулаьная, но в целом важная. А не хранить ли нам рассчитанный путь до файла прямо в таблице в отдедбной колонке? Да, это некоторая денормализация, но не критичная. Так мы сможем найти запись в тбалице по найденному файлу. В сулчае если мы решим изменить правила построеня пути, это не сломает предыдущие файлы, и можно неспешно их фоном обновить позже. В случае необзодимости файл переметить, переименовать или что подобное, так же будет проще не потерять его.
В целом ничего не мешает даже в сервисе сделать раздельные методы для разных таргетов. А после разделить FileService на FileUploader, и FileManager
вобще так как сейчас у нас всего один тип алоада, - attachment можно роут заточить под него. А когда будем добавлять аватарки, будем думать как сделать его более универсальным или разделить
Ну, что поздравляем нас. Файл наконец отправляется таки на сервер. Пока вопросы с сохранением инфы об этом базе. С получением и отображением его. Но все таки, дело сдвинуто с мертвой точки!
Уф, наконец мяч на стороне бекенда. Тут то же вопросы.
как-то в итоге я и без dropZone встал на том же месте. Есть реактивная ссылка на инпут, в котором вся инфа. Есть formData для ajax. Есть поля где те же данные будут отображаться в виджете.
И вот май наступил. 2 месяца паузы .вспоминаем на чем остановились и что решили.
И вот прошел целый месяц с последнего раза, как я об этой задаче думал. Уже май на носу.
Вынесли идею сложного vue-компонента в tndt-211. Пока нет сил так глубоко копать фронтенд, мы в нем закапываемся и все стоит.
Март идет к концу, а задача забуксовала. Давайте подумаем над тем, как бы её упростить. Здесь много нового бекенд функционала, давайте сложный и гибки vue-загрузчик отложим на потом, а тут сделаем максимально простую форму в стиле web 1.0.
Единственное что усложнит бекенд, это роут на который нужно будет сделать редирект после загрузки.
Сел таки, и пока нихрена не понимаю, что тут происходит. Надо бы разрисовать схему, а в vue-компоненте определиться что мы и где храним, а то пока как-то набросано всякого случайно
И вот начался март, и что-то пока совсем некогда сесть за задачу. А ведь в ней еще готова только меньшая часть. А за ней еще и работа с картинками. Может пока отложить dropZone и её обвязку и ajax агрузку на следующий этап?
Готовых компоннтов аплоадера на js не то, чтобы нет. Скорее нет какого-то общепринятого и популярного. А потому думается надо делать свой, саользуя vueUse как я и предполагал с начала.
и так, теерь кусочек со стороны аплоада. Dropzone есть готовый у таблер. но сходу не подключается. В js-пакетах правда черт ногу сломит, этот dropzone у них встроенный или внешний, и как его подключить через webpack.
Это было очень неочевидно, но похоже мы таки освоили отдачу файлов через X-Accel. Т.е. система работает, и тепреь убирать это все в сервис и делать аплоадер
Процесс пошел, сущность в первом приближении есть. Volume к php и nginx прикрепляется, nginx с неё файлы отдает. Осталось со стороны php придумать отдачу для private
надо уже определяться с приватным и публичным путем и volume.
Ну вот и все, рабоа начата. Конечно есть еще куча непонятных вопросов, но лучше уж с ними столкнуться при написании кода, и там принимтаь временные и постоянные решения, чем сидеть которую неделю раздумывать иготовится. Думается, что основное мы определили.
Up, не забываем, что за всеми дополнительными задачами. основная, начать крепить к проектам фотки чертежей, и прочего.
Кстати, чтобы не плодить вложенные сущности, хороший повод попробовать в деле Embedable. Чтобы доктрина по type сразу гидрировала нужную сущность. А сущность ImageFile будет наследоваться от File.
Кстати да, дуамю систему все же называть File, а не Upload, хотя можно еще подумать.
Вывод в тегах в тексте вероятно будет позже, это не так просто. Плюс это скорее vue на textarea, чтобы оперативно искать загруженное, а может быть и на лету грузить и крепить.
Ну все, берем в работу, делаем минимально необходимый функционал:
https://uppy.io/docs/quick-start/ аплоадер файлов сторона фронтенда
К этому лету мы это не успели, а осенью важность несколько снизится, но к следующей весне надо непременно. (так что вероятно у 3 версии будет мало минорных релизов)
Приподнял приоритет, если савмому tndt эта задача не особо важна, то многим моим непрограмерским проектам этого функционала крайне не хватает. Прикреплять сюда планы участка и дома, сделанные 3-d модели деталей, конфиги устройств, схемы и диаграммы.
Для tndt этот эпик менее важен, чем гипертекст, связи и т.д. А вот для других проектов, например дачи очень не хватает. Плюс возможность вставить документ и картинку - повод активнее заняться документами
Задачу возможно стоит разбить на несколько. Как минимум обдумать над минимлаьно необходимым функционалом и основным. Как минимум мы хотим раздельные конфиги для аватарок и аттачментов (как изображений, так и разных документов нестандартных расширений, возможно больших), сабнейлы. Если сами аватарки могут и подождать, то даче очень нужно прикрепить нарисованные нами планы. Так что либо в v0.3 либо в v0.4
Up. Чуть не забыли и не завели по новой. Очень не хватает и фильтрации и категорий.
попробовал сегодня выкатить его на dev. Но там не собирается compose, ругается на что-то, хз на что