Evolution #1988

Wikitty pre-loading field

Added by Benjamin Poussin over 1 year ago. Updated over 1 year ago.

Status:RésoluStart date:02/29/2012
Priority:NormalDue date:
Assignee:Benjamin Poussin% Done:

100%

Category:APIEstimated time:5.00 hours
Target version:3.5Spent time:12.00 hours

Description

Il serait agreable de pouvoir faire un pre-loading de certain champs Wikitty.

client.restore(id, "Company.employee")
client.restore(id, "Company.employee,Employee.person;Company.address")

Dans le 1er cas, on preload seulement le un champs de l'objet qui va etre chargé.

Dans le 2eme cas on preload 2 champs Company.employee et Company.address. Puis pour employee on re-preload Employee.person.

Pour cela ajouter sur le WikittyImpl une map <id, wikitty> qui permette de stocker les wikitty preloader.

on ajoute la méthode sur le Wikitty:

get&lt;FieldName&gt;AsWikitty(String extName, String fieldName, boolean exceptionIfNotLoader):Wikitty

lors d'un set<FieldName>(...) si la value est un Wikitty alors on le met dans la map des objets preloaded

on ajoute la méthode sur les objets metiers:

get&lt;FieldName&gt;(boolean exceptionIfNotLoader): ObjectMetier

Si le boolean est false, alors au lieu d'une exception, on retourne null si l'objet est pas preloader.

History

#1 Updated by Benjamin Poussin over 1 year ago

  • implantation cote serveur
    + centralise
    + commun a tout les clients/langage
    - couteux en transfert (on renvoie tout meme si deja dans le cache, il faut que le pattern du preload soit aussi une condition du cache :()
    - modifie la signature de WikittyService
  • implantation cote Client
    + pas de transfert couteux
    + possibilite de reutiliser le cache
    + lors d'un store pas besoin d'envoyer et recevoir les preload
    - pas de mutualisation entre langage (mais c'est peut-etre mieux ?)
    • dans les methodes restore et store
      + plus transparent
      + permet de gerer un tag/value preload
      - invisible a l'utilisateur et pourra ne pas le vouloir
      - on re-preload apres un store alors que l'utilisateur pourrait ne plus avoir besoin de l'objet (mais normalement en cache)
    • dans une methode specifique preload
      + l'utilisateur maitrise exactement ce qu'il veut
      - pas possible de force du preload sur tagvalue (il faut que l'utilisateur le fasse lui meme)
      - apres un store il faut penser a refaire le preload si on veut continuer avec l'objet
      - incompatible avec un toString qui utiliserait des objets pointer (fonctionnalité tres interessante)

La bonne solution a priori est donc d'implanter le mécanisme cote client dans les methodes store et restore. Restore prenant un argument supplémentaire.

lors d'un clone la collection des objets preloaded est copiee mais pas en deep (seul la collection est clone, mais ses elements).

Il faut en plus de la map<id, wikitty> de preload, un champs texte qui retiennent le preload demande par l'utilisateur, elle servira lors du store a refaire le preload tel que demande lors du restore.

#2 Updated by Benjamin Poussin over 1 year ago

Creer un nouveau tagvalue 'preload' qui permette de force (si le client le supporte) le prechargement automatique de lien vers des wikitties. Couplé avec le tagvalue toString, cela permettra d'avoir toujours des objets qui ont une representation convenable pour l'homme (certain objet n'ont aucun champs propre et ne sert que de liaison entre 2 wikitties sont inaffichable facilement actuellement)

#3 Updated by Benjamin Poussin over 1 year ago

  • Status changed from Nouveau to Assigné
  • Assignee set to Benjamin Poussin
  • % Done changed from 0 to 70

#4 Updated by Benjamin Poussin over 1 year ago

  • Status changed from Assigné to Résolu
  • % Done changed from 70 to 100

Also available in: Atom PDF