Entità estesa, apre screen di edit dell'entità base

Buongiorno a tutti,

ho un altro dei miei quesiti fantastici… :slight_smile:

Creo un’entità Test e i relativi screen browse/edit.

Poi estendo l’entità Test come Test2 e creo gli screen browse/edit sull’entità estesa, a questo punto il browse utilizza lo screen di Test2, ma l’edit utilizza lo screen di Test.

Vorrei capire come ragiona Cuba, capire dove ho sbagliato e quindi come fare per dirgli di usare lo screen di edit relativo all’entità estesa. Mi sono studiato i file java e xml di Test2, ma non ho trovato traccia della cosa, deve essere un meccanismo di default.

Qui c’e’ un piccolo progetto di esempio: https://github.com/mselmi65/Test

Grazie come sempre in anticipo per l’aiuto.

Marco Selmi

Ciao e bentornato!

Dai un’occhiata a questi due punti nei docs:
https://doc.cuba-platform.com/manual-7.2/entity_extension.html
https://doc.cuba-platform.com/manual-7.2/entity_class_annotations.html#extends_annotation

Estendere un’entità si può fare in due macro modi diversi:

  1. Creare una nuova entità che è separata dal parent
  2. Sostituire l’entità parent in modo che venga usata al posto del parent

La differenza sta nell’usare o meno l’annotazione @Extends: se la usi sei nel caso 2., altrimenti nel caso 1.

Nel tuo caso l’hai usata (Test2 sostituisce Test1 nei meccanismi di CUBA). Pertanto non ha senso creare o usare screens che usino Test1, perché introduce solo confusione e problemi.
Quindi devi eliminare gli screens di Test1 (e i menù relativi) e usare solo Test2. Se vuoi usare ancora Test1 in modo separato, allora non devi usare @Extends e devi pianificare bene la strategia di estensione JPA (questo a prescindere: https://thorben-janssen.com/complete-guide-inheritance-strategies-jpa-hibernate/ – si riferisce ad Hibernate ma è lo stesso con EclipseLink).

Paolo

Ciao Paolo,

forse mi sono spiegato male, ho bisogno di creare diversi parent di una stessa entità e utilizzare screen di browse/edit diversi per i vari parent. Nello specifico un’entità documenti da cui derivo i vari tipi di documento (Ordini, DDT, Fatture, ecc…) che mi servono. Quindi dovrebbe essere corretto l’uso di @Extend in modo che tutte le entità figlie confluiscono nell’unica tabella dell’entità madre.

Leggendo la documentazione ho visto che si puo’ modificare l’action standard della griglia, in particolare sempre riferendomi al progettino di esempio che ho nel frattempo aggiornato:

public class Test2Browse extends StandardLookup {
@Named(“test2sTable.create”)
private CreateAction test2sTableCreate;
@Named(“test2sTable.edit”)
private EditAction test2sTableEdit;

@Subscribe
public void onInit(InitEvent event) {
    test2sTableEdit.setScreenClass(Test2Edit.class);
    test2sTableCreate.setScreenClass(Test2Edit.class);
}

}

In questo modo posso impostare l’apertura di Test2Edit. Se non specifico niente di default apre sempre TestEdit anche se io sto utilizzando Test2. Probabilmente legge l’impostazione dall’entità madre.

Ritieni in base alla tua esperienza che questo possa essere il metodo corretto?

Marco

In realtà no… :wink:
@Extends non ha nulla a che fare con le strategie di inheritance JPA, come ti ho spiegato sopra.
Cioè, prima definisci quale strategia adottare in base se vuoi una tabella sola con colonna discriminante, più tabelle ecc.

Estesa la tua entità con la strategia corretta ti domandi: a me servono contemporaneamente parent e child?
NO, devo sostituire il parent ovunque possibile --> applichi @Extends
SI, devo poter usare le entità in modo indipendente --> NON applichi @Extends

Spero di essere stato chiaro stavolta :wink:

PS: il caso NO si usa tipicamente quando estendi entità di sistema, come User e vuoi che CUBA usi il TUO nuovo user al posto del suo. Allo stesso modo può capitare che tu faccia un’app component con entità comuni (tipo Indirizzo) ma poi in un’app in cui lo usi ti salta in mente che vuoi aggiungere a quella entità qualcosa e usarla al posto dell’originale…

Paolo

Inoltre ti consiglio di non abusare dell’ereditarietà, e di usarla in maniera “ponderata” al tuo scopo.

Nel caso che mi hai descritto è probabile che l’entità parent Documento possa essere solo una @MappedSuperclass e non una entità con la sua table.
In generale, in JPA e con gli ORM, si deve cercare di usare l’ereditarietà con tantissima parsimonia. Personalmente forse la uso una volta o due ogni 20/30 tabelle, e solo se proprio ne vedo un grande vantaggio.
Non so quanta esperienza tu abbia con JPA, ma ti assicuro che lavorare con entità estese non è come il normale polimorfismo OOP.

Paolo

Infatti ti stavo per scrivere…esperienza JPA = 0.

Quindi mi suggerisci per favore un bel libro anche in inglese da leggere su JPA?

Forse e’ meglio se comincio dalle basi. :wink:

Marco

Bella domanda, è passato abbastanza tempo da non ricordarmi le mie fonti :wink:

In ogni caso essendo un argomento insegnato da 20 anni, puoi partire da risorse free in rete, senza perdere troppo tempo con un libro. Il libro o il corso vero e proprio li potrai affrontare se vuoi approfondire.

In linea generale, la prima fonte in rete che ti consiglio è il sito di Baeldung, praticamente l’80% delle prime posizioni in google quando cerchi qualcosa su Java/Spring sono sue.

Anche se parla di Hibernate, quello che ti serve imparare è standard e funziona uguale in EclipseLink (nota: CUBA usa EclipseLink come ORM, un’alternativa famosa a Hibernate).

Paolo

OK, vado di Baeldung.

Grazie

Marco