Personalizzazione JHipster

È possibile personalizzare/estendere JHipster per un'organizzazione?Personalizzazione JHipster

Con ciò intendo una versione locale che crea alcuni progetti con funzionalità specifiche per un'organizzazione? Ad esempio, utilizzando uno schema di autenticazione personalizzato (che si basa ancora sulla sicurezza Spring), utilizzando stili personalizzati (colori, caratteri), aggiungendo determinate dipendenze Maven e così via.

Se ciò è possibile, può essere fatto pur mantenendo la possibilità di aggiornare JHipster in modo tale che un aggiornamento di JHipster non sovrascrivere queste estensioni?

Grazie.

fonte

2015-12-01 ccc

Sì, questo è possibile, e corrisponde perfettamente al progetto a cui sono attualmente coinvolto. Ma la risposta dettagliata dipende da cosa vuoi da JHipster. Si tratta di un ottimo strumento per l'avvio rapido, ma non usiamo JHipster stesso in uno sviluppo di applicazioni completamente sviluppato. Solo occasionalmente per una rapida creazione di entità. – dfche

@dftche: Beh, questo è esattamente quello che sto pensando: usare JHipster per l'impalcatura: creare la struttura di base, le pagine CRUD e le entità. Dopodiché, continua con lo sviluppo normale, ovvero implementando la logica di business, l'integrazione con altre app e così via. Potresti per favore condividere con me quanto esattamente stai personalizzando e usando JHipster? Sarebbe molto apprezzato Grazie. Se lo fai, rispondi alla domanda, piuttosto che commentare, così posso darti il merito di risolverlo. – ccc

Ecco l'approccio in generale:

In primo luogo, abbiamo creato un progetto vuoto con tutta JHipster pila standard. Il DBMS utilizzato è Postgres. Abbiamo delineato la struttura dati di base con lo strumento di generazione di entità jhipster, creando le più importanti relazioni ecc. Abbiamo anche definito i ruoli utente e le autorizzazioni di base all'interno delle opzioni standard di JHipster. In questa fase non abbiamo prestato molta attenzione ai dettagli come i complessi vincoli unici, le restrizioni aziendali , la gestione degli utenti, la gestione degli errori JPA e la presentazione . Basta creare una sorta di backbone per iniziare. Le pagine CRUD sono tutte standard.
Abbiamo introdotto alcune logiche di business specifiche del dominio. La personalizzazione di base del frontend è stata eseguita: branding, stili , alcune visualizzazioni personalizzate (classi di bootstrap ancora utilizzate in modo esteso) ecc. Il frame generato da Jhipster è stato mantenuto ma esteso. Abbiamo modificato un po 'la logica di autorizzazione su entrambi i backend e frontend, è basata su token con determinate regole di convalida dei token . È stata introdotta una gestione degli errori user-friendly, che consente all'utente di leggere le restrizioni aziendali in diverse condizioni. Abbiamo iniziato a scrivere test unitari più complessi per soddisfare la logica aziendale implementata di recente. Le entità sono per lo più (~ 80%) elaborate manualmente in questa fase, perché ci siamo abituati alla struttura dati offerta da JHipster e abbiamo avuto troppa personalizzazione nei controller CRUD REST, pagine e test che coprono tutto ciò. I changelog di Liquibase sono stati generati con liquibase: diff e modificati manualmente. Non aggiungiamo tali entità alla cartella .jhipster.
A causa delle richieste di un design di interfaccia sempre più severo, è stato deciso di introdurre un frontend separato per l'interazione con l'utente finale. Condivide parzialmente le interfacce REST con il frontend generato da jhipster, ma è assolutamente indipendente in termini di struttura del progetto. Abbiamo deciso di utilizzare Angular anche per il nuovo frontend layer. Di fatto, si tratta di una sottocartella con index.html, bower.json, Gruntfile.js e così via. Allo stesso tempo, abbiamo continuato a migliorare la logica aziendale, perfezionare la struttura del database, aumentare la copertura del codice, introdurre nuovi ruoli utente, ecc.
...

Quindi abbiamo personalizzato un frontend JHipster "vecchio" per scopi amministrativi e di gestione dei dati. E un frontend "nuovo" indipendente con design personalizzato per affrontare gli utenti finali. Si prega di notare: È possibile mantenere un'interfaccia originale, personalizzarla a un certo limite e preservare la possibilità di generare entità, e ha funzionato bene nel nostro progetto per quanto era giustificato.

Alcune note:

versioni dei componenti in pom.xml sono stati costantemente aggiornati a mano;
Le dipendenze Maven sono state aggiunte manualmente a pom.xml;
Le dipendenze JS sono state aggiunte manualmente a index.html/bower.json/app.js;
Se si dispone di script di frontend complessi, la gestione dell'eguaglianza di JS per il profilo di produzione può essere complicata;
Un'altra cosa difficile è mantenere gli script di liquibase funzionanti per entrambi i DBMS utilizzati da spring-boot e H2 che viene utilizzato per i test;
Probabilmente avrete problemi con l'ottimizzazione della configurazione in base alla logica del dominio specifica per il vostro progetto.

Spero che sia d'aiuto.

fonte

2015-12-05 23:23:57 dfche

Grazie per l'ampia risposta. Tuttavia, quello che stai descrivendo è più o meno ciò che sono nel processo di fare me stesso. Ho eseguito l'upvoting della risposta, ma non è stato possibile contrassegnare il problema come risolto perché la mia domanda riguardava la personalizzazione di JHipster stesso, ovvero la personalizzazione del generatore di scaffold. Quindi, quando lo usi per generare un nuovo progetto, hai un'altra pagina iniziale, con alcuni CSS personalizzati, sicurezza personalizzata e così via. Motivo: se si utilizza JHipster per creare più progetti in un'azienda, non si perde tempo a modificare lo stile/il marchio in ognuno, ma sono già presenti nel codice generato da JHipster. – ccc

Oops, ti ho sbagliato. Ho dato una breve occhiata alle fonti di jhipster e penso che sia possibile personalizzarlo in base alle tue esigenze dopo averlo clonato (https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md#-generator- development-setup) – dfche

Ecco cosa intendevo. Tuttavia, dubito che molte aziende vorrebbero che il loro generatore fosse di pubblico dominio, quindi il mio problema era: 1) personalizzare le fonti di JHipster (immagino che dovrebbe essere possibile - questa dovrebbe essere la parte più facile, in realtà); 2) l'hosting di questo JHipster personalizzato sulla rete interna di un'azienda, 3) mentre idealmente è anche in grado di aggiornare il codice quando JHipster viene aggiornato; continua .... – ccc

Un altro approccio che è stato introdotto nella versione 2.26.0 (metà dicembre 2015) è quello di creare i propri moduli, vedere documentation.

fonte

2016-02-27 20:01:04

Personalizzazione JHipster

risposta

Problemi correlati