Настройка JHipster

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

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

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

Спасибо.

источник

2015-12-01 ccc

Да, это возможно, и это идеально соответствует проекту, в котором я сейчас участвую. Но подробный ответ зависит от того, что вы хотите от JHipster. Это отличный инструмент для быстрого запуска, но мы не используем JHipster непосредственно в разработке приложений. Просто изредка для быстрого создания сущности. – dfche

@ dftche: Ну, это именно то, о чем я думаю: используя JHipster для строительных лесов: создайте базовую структуру, страницы и сущности CRUD. После этого продолжайте нормальное развитие, это означает внедрение бизнес-логики, интеграцию с другими приложениями и так далее. Не могли бы вы поделиться со мной, как именно вы настраиваете и используете JHipster? Было бы очень благодарно. Благодарю. Если вы это сделаете, ответьте на вопрос, а не комментируете, чтобы я мог дать вам кредит на его решение. – ccc

Вот такой подход в целом:

Во-первых, мы создали пустой проект со всем стандартным стеком 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 и т. Д. В то же время мы продолжали совершенствовать бизнес-логику, улучшать структуру базы данных, увеличивать охват кода, вводить новые пользовательские роли и т. Д.
...

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

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

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

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

источник

2015-12-05 23:23:57 dfche

Спасибо за подробный ответ. Однако то, что вы описываете, более или менее то, чем я занимаюсь. Я подтвердил, что вы отвечаете, но не можете отметить проблему как решаемую, потому что мой вопрос был связан с настройкой самого JHipster, что означает настройку генератора лесов. Поэтому, когда вы используете его для создания нового проекта, у вас есть другая стартовая страница, с некоторыми пользовательскими CSS, настраиваемая безопасность и так далее. Причина: если вы используете JHipster для создания нескольких проектов в компании, вы не будете тратить время на изменение стиля/брендинга в каждом, но имеете их уже в коде, создаваемом JHipster. – ccc

К сожалению, вы ошибаетесь. Я кратко ознакомился с источниками jhipster, и я думаю, что после его клонирования можно настроить его на свои нужды (https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md#-generator- setup-setup) – dfche

Вот что я имел в виду. Тем не менее, я сомневаюсь, что многие компании хотят, чтобы их генератор был в общественном достоянии, поэтому моя полная проблема заключалась в следующем: 1) настройка источников JHipster (я полагал, что это должно быть возможно - это должна быть самая легкая часть, действительно); 2) размещение этого настроенного JHipster во внутренней сети компании, 3), а также в идеале возможность обновления кода при обновлении JHipster; продолжение ... – ccc

Другой подход, который был представлен в выпуске 2.26.0 (середина декабря 2015 года), заключается в создании собственных модулей, см. documentation.

источник

2016-02-27 20:01:04

Настройка JHipster

ответ

Смежные вопросы