Настройка JHipster - программирование

Можно ли настроить/расширить JHipster для организации?

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

Если это возможно, можно ли это сделать, сохранив возможность обновления JHipster таким образом, чтобы обновление JHipster не перезаписывало эти расширения?

Спасибо.

Ответ 1

Здесь общий подход:

Сначала мы создали пустой проект со всеми стандартными JHipster стек. СУБД используется Postgres. Мы изложили основную структуру данных с помощью инструмента генерации сущности jhipster, создавая наиболее важные отношения и т.д. Мы также определили основные пользовательские роли и разрешения в стандартных вариантах JHipster. На этом этапе мы не платили очень большое внимание к деталям, таким как сложные уникальные ограничения, бизнес-ограничения, управление пользователями, обработка ошибок JPA и презентация и т.д. Просто создал своего рода основу для начала. Страницы CRUD являются стандартными.
Мы представили некоторую бизнес-логику, специфичную для домена. Была выполнена основная настройка интерфейса: брендинг, стили, некоторые пользовательские представления (по-прежнему используются классы начальной загрузки) и т.д. Рамка, созданная Jhipster, была сохранена на месте, но расширена. Мы немного изменили логику авторизации на обоих бэкэнд и frontend, он основан на токенах с определенной проверкой маркера правила. Была введена удобная обработка ошибок, позволяющая пользователю понять, какие бизнес-ограничения проявляются в различных условиях. Мы начали писать более сложные модульные тесты для удовлетворения недавно реализованной бизнес-логики. Объекты в основном (~ 80%) создаются вручную на данном этапе, потому что мы привыкли к структуре данных, предлагаемой JHipster, и у нас было слишком много настроек в контроллерах CRUD REST, страницах и тестах, охватывающих все это. Списки изменений Liquibase были созданы с помощью Liquibase: diff и отредактированы вручную. Мы не добавляем такие объекты в папку .jhipster.
Из-за того, что требования к дизайну интерфейса стали высокими и строгими, было решено ввести отдельный интерфейс для взаимодействия с конечным пользователем. Он частично разделяет интерфейсы REST с интерфейсом, созданным с помощью jhipster, но абсолютно независим с точки зрения структуры проекта. Мы решили использовать Angular для нового слоя frontend. Фактически, это подпапка с отдельными index.html, bower.json, Gruntfile.js и т.д. В то же время мы продолжали совершенствовать бизнес-логику, улучшать структуру db, увеличивать охват кода, вводить новые пользовательские роли и т.д.
...

Итак, у нас есть слегка настроенный "старый" интерфейс JHipster для администрирования и управления данными. И независимый "новый" интерфейс с индивидуальным дизайном для работы с конечными пользователями. Обратите внимание:: возможно сохранить оригинальный интерфейс, настроить его до определенного предела и сохранить возможность генерации объектов, и он хорошо работал в нашем проекте, насколько это было оправдано.

Некоторые примечания:

Компонентные версии в pom.xml постоянно обновлялись вручную;
Зависимости Maven были добавлены вручную в pom.xml;
Зависимости JS были добавлены вручную в index.html/bower.json/app.js;
Если у вас есть сложные скрипты с интерфейсом, обработка JS uglification для профиля производства может быть сложной:
Еще одна сложная задача - сохранить скрипты Liquibase для обеих СУБД, используемых spring -boot и H2, которые используются для тестов;
Вероятно, у вас возникнут некоторые проблемы с настройкой конфигурации в зависимости от конкретной логики домена для вашего проекта.

Надеюсь, это поможет.

Ответ 1

Ответ 2