Migration 3.1 vers 3.2

AppDevelopment - Migration 3.1 vers 3.2
Mi
gr
ati
on
3.
1
ve
rs
3.
2
Séba
stien
Sch
mitt
De
Reke
neire
2014
/11/2
5
11:4
7
Table des matières
Page 1 - dernière modification par Sébastien Schmitt De Rekeneire le 2014/11/25 11:47
AppDevelopment - Migration 3.1 vers 3.2
Liste des modifications pouvant avoir un impact en 3.2
Le contenu de la version 3.2 est disponible sur cette page.
•
•
Java
.Net
Java
ATTENTION : Encore plus que d’habitude, il ne faut PAS générer les sources 3.2 par dessus des sources 3.1
existantes !
Automatisation d’une partie de la migration
Nous avons créé un programme qui migre en partie les sources custom de l’application générée.
Pour le lancer, il faut le copier dans le dossier “src\ fr\ logica\ domain\ logic” puis le lancer en double cliquant
dessus.
Le programme va réaliser une copie de sauvegarde de chaque fichier java (nommé .java.bak), puis il va migrer le
code de ces classes.
Une fois le programme terminé (et tel qu’il l’indique), il faut retourner dans eclipse et en sélectionnant le package
‘fr.logica.domain.logic’, appuyer sur Ctrl+Shift+o (c’est la lettre o, pas le chiffre 0).
Cela permet de mettre à jour les imports dans les classes Java.
Une fois ceci dit et lu, vous pouvez récupérer le programme ici :
MigrationJava3.2.exe
Entities
•
Le code des entités a été modifié pour ajouter des annotations, cela ne devrait pas avoir d’impact sur le
code mais il faut le savoir.
•
•
Les méthodes d’accès à la base de données ont été retirés des entités et sont maintenant accessible dans
la classe DB.
le code
•
•
User u = new User(login);
u.find(ctx);
•
deviens
•
•
•
Key key = new Key(UserConstants.ENTITY_NAME);
key.setValue(UserConstants.Vars.USER_LOGIN, login);
User u = DB.get(UserConstants.ENTITY_NAME, key, ctx);
•
La variable statique “NAME” a été supprimée, elle est accessible dans la classe de constantes sous le nom
“ENTITY_NAME” :
•
Contact.NAME
•
deviens
•
ContactConstants.ENTITY_NAME
•
Pour le layer JPA, les méthodes permettant d’accéder aux objets liés ont été modifiées :
•
task.getRefContact()
Page 2 - dernière modification par Sébastien Schmitt De Rekeneire le 2014/11/25 11:47
AppDevelopment - Migration 3.1 vers 3.2
•
deviens
•
task.getRefTaskRContact()
•
Le nom du lien a été ajouté dans la méthode afin traiter tous les cas possibles (multi-liens sur la même
entité et liens sur soi même).
Entity Models
•
•
Les objets Models ont tous été supprimés.
Leur contenu a été déplacé a plusieurs endroits : dans des annotations dans les entité ou dans une
nouvelle classe de constante.
•
Cela impact tout le code custom puisque ce qu’on écrivait avant ainsi TaskModel.ENTITY_NAME devient
maintenant TaskConstants.ENTITY_NAME.
Mais également Album.Var.DESCRIPTION devient maintenant AlbumConstants.Vars.DESCRIPTION.
Ou encore Album.Action.ACTION_5 devient maintenant AlbumConstants.Actions.ACTION_5.
•
•
Pour le cas particulier de la récupération de l’instance d’une Action Toy, il faut réaliser la modification suivante :
Action action = new ContactModel().getAction(Contact.Action.ACTION_13);
deviens
Action action =
EntityManager.getEntityModel(ContactConstants.ENTITY_NAME).getAction(ContactConstants.Actions.ACTION_
13);
Link Models
•
•
La notion de key a été enlevé des linkModels et les méthodes utilisant précédemment les clés utilisent le
linkName.
Ainsi la ligne entity.setForeignKey(linkMdl.getKeyName(), dep.getPrimaryKey()); deviens
entity.setForeignKey(linkMdl.getLinkName(), dep.getPrimaryKey());
Defined values
•
•
L’objet EntityField contient maintenant la liste des valeurs acceptées dans la propriété DefinedValues qui
correspond a à une liste de l’objet DefinedValue qui comprend le code, la valeur et le label de l’entrée.
L’accès aux valeurs qui se faisait de cette manière ((EntityField)f).getValues().get(1) se fera maintenant
ainsi ((EntityField)f).getDefinedValues().get(1).getValue()
Entity Logics
•
•
Toutes les classe de logic (ie le code custom) ont vu leur signature changer, maintenant la classe
implémente l’interface des constantes de l’entité.
Ainsi public class AlbumLogic extends DefaultLogic<Album> devient public class AlbumLogic
extends DefaultLogic<Album> implements AlbumConstants
•
Cela permet principalement d’avoir un raccourci pour utiliser les constantes de l’entité courante. Donc si on
est dans AlbumLogic au lieu de faire AlbumConstants.Actions.ACTION_5, on peut juste faire
Actions.ACTION_5
•
La méthode public List<Key> doCustomAction a été splittée en 2 suivant si on fait une action de type
“Input One” ou “Input Multiple”.
Celle avec la signature public List<Key> doCustomAction(Request<Entity> request, Entity entity,
RequestContext ctx) sert uniquement pour les Input One.
Celle avec la signature public List<Key> doCustomAction(Request<Entity> request, Entity entity,
•
•
Page 3 - dernière modification par Sébastien Schmitt De Rekeneire le 2014/11/25 11:47
AppDevelopment - Migration 3.1 vers 3.2
List<Key> keys, RequestContext ctx) sert uniquement pour les Input Multiple.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
La méthode public Response<?> uiCtrlOverrideAction a changé de type de variable de sortie pour un type
générique Response<?>.
Pour créer une action d’une entité, vous devrez utiliser la classe EntityModel au lieu de NomEntitéModel.
Exemple :
@Override
public Response<?> uiCtrlOverrideAction(Response<Pp2Propale> response, RequestContext ctx) {
if (response.getAction().is(Pp2PropaleConstants.Actions.ACTION_2)
&& ((Pp2Propale) response.getEntity()).getStatut() ==
Pp2PropaleConstants.ValueList.STATUT.FINALISATION) {
EntityModel model = response.getEntity().getModel();
// Get replacing action
Action newAction = model.getAction(Pp2PropaleConstants.Actions.ACTION_5);
// Return an action page containing action information.
response.setAction(newAction);
return response;
}
return super.uiCtrlOverrideAction(response, ctx);
}
UI
La classe fr.logica.ui.UI contenait la liste de tous les templates définis dans l’application.
Cette classe a été supprimée et les données réparties dans la classe Constants de l’entité du template.
Ainsi UI.Album.ALBUM devient AlbumConstants.Templates.ALBUM.
ASP .net
ATTENTION : Comme pour la version Java, il ne faut PAS générer les sources 3.2 par dessus des sources 3.1
existantes !
BaseSqlDao
Toutes les méthodes de cette classe sont passées en statiques.
Ainsi si avant on avait :
BaseSqlDao dao = new BaseSqlDao(SorcererModel.EntityName);
dao.Update(entity, context.DbContext);
Maintenant on pourra écrire directement :
BaseSqlDao.Update(entity, context.DbContext);
Les seules exceptions sont les méthodes ReadByKey et DeleteByKey, pour utiliser ces méthodes, il faut spécifier
l’entité concernée.
C’est possible soit en passant le nom de l’entité en premier paramètre et en castant le retour :
Sorcerer s = (Sorcerer)BaseSqlDao.ReadByKey(”Sorcerer”, k, context.DbContext);
Soit en utilisant la méthode générique :
Sorcerer s = BaseSqlDao.ReadByKey<Sorcerer>(k, context.DbContext);
Page 4 - dernière modification par Sébastien Schmitt De Rekeneire le 2014/11/25 11:47
AppDevelopment - Migration 3.1 vers 3.2
Entity Logics
•
•
La signature de la méthode doCustomAction a été totalement modifiée. Le dernier paramètre
IEnumerable<Model> entities a été supprimé.
A charge au code custom de charger les entités au besoin à partir des Key reçues en utilisant la méthode
BaseSqlDao.ReadByKey.
A COMPLETER
Page 5 - dernière modification par Sébastien Schmitt De Rekeneire le 2014/11/25 11:47