Permettre la gestion de plusieurs items pour les actions massives » History » Version 5

webmyster, 07/10/2013 02:29 PM

1 1 webmyster
h1. Permettre la gestion de plusieurs items pour les actions massives
2 1 webmyster
3 1 webmyster
En passant les items actifs à la fenêtre de choix des actions, on peut filtrer plus précisémment les actions à effectuer.
4 1 webmyster
5 1 webmyster
Par exemple, pour les liens élément<->composant, la modification 'update' n'est pas utile sur certains type de devices. Ainsi, si on ne coche que des @Item_DeviceCase@, on n'affiche que le "delete" et le "unaffect" dans la fenêtre modale.
6 1 webmyster
De plus, lorsque l'on coche plusieurs types de devices, le update est spécifique alors que la suppression ou la désaffectation est commune. Par exemple, si on coche des processeurs et des mémoires, on pourrait choisir comment action :
7 1 webmyster
* Désaffectation des composants ;
8 1 webmyster
* Suppression des composants ;
9 1 webmyster
* Mise à jours de la mémoire ;
10 1 webmyster
* Mise à jours du processeur.
11 1 webmyster
12 1 webmyster
Cela serait beaucoup plus simple pour gérer la suite de l'affichage. En effet, pour la mise à jours, on a besoin de savoir exactement sur quel type d'objet on travail, pour connaître les champs disponibles. Alors que pour les deux autres actions, on peut l'appliquer à tous les types d'items.
13 1 webmyster
14 1 webmyster
Webmyster: _personnellement, je trouve que la classe @CommonDBTM@ est énorme (près de 5000 lignes de code). Je galère toujours pour retrouver ce que je recherche dedans. Donc, je propose de transférer tous les éléments génériques concernant les massives action dans une classe MassiveAction (showMassiveActionsParameters, executeMassiveActions, doMassiveActions, getAllMassiveActions ...). Après tout, on a besoin d'un objet item dans les méthodes de gestion des MassiveActions. Mais ce n'est pas spécifique à un item particulier. Les méthodes spécifiques (showSpecificMassiveActionsParameters, doSpecificMassiveActions, getForbiddenStandardMassiveAction, getSpecificMassiveActions ...) resteraient dans la classe CommonDBTM._
15 1 webmyster
16 1 webmyster
-Pour dissocier les actions "communes" des actions "spécifiques", je propose d'ajouter une méthode @MassiveAction::getCommonActions@ qui renverrait un tableau des actions qui sont communes. Par définition, les actions "communes" sont au moins définies dans la classe @MassiveAction@. Donc, il me semble plus simple de les indiquer plutôt que d'indiquer celles qui sont spécifiques.- Cela est invalidé par la section _Comment gérer les actions spécifiques ?'_ ci-dessous.
17 1 webmyster
18 1 webmyster
h1. Suppression de @itemtype@ ?
19 1 webmyster
20 1 webmyster
Après réflexion (et quelques tests), je me rend compte que le champs @itemtype@, défini dans @Html::showMassiveActions()@ n'est plus utile dans tout le traitement des actions massives. En effet, ce champs @itemtype@ serait dynamique avec la liste des champs choisis. Et certaines actions spécifiques, ou non, n'en ont l'utilité qu'au dernier moment.
21 1 webmyster
22 1 webmyster
*Ce champs me semble même problèmatique :* quel @itemtype@ définir si nous proposons les actions massives pour une recherche globale (_front/allassets.php_) avec des @Printer@, des @Computer@ ... dans le résultat ?
23 1 webmyster
24 2 moyo
MoYo : Il me semble qu'on peut effectivement le virer en basculant sur la nouvelle architecture.
25 2 moyo
26 1 webmyster
h2. Qu'en est-il des actions qui en ont besoin ?
27 1 webmyster
28 1 webmyster
Certains actions ont besoin de savoir à quel type d'item elles doivent s'appliquer, notamment @update@ (pour savoir quels sont les champs modifiables). Lorsque l'utilisateur a coché des cases de nature différente, l'action peut afficher un _dropdown_ de choix de l'itemtype (affichage centralisé dans la classe @MassiveActions@). Dès que l'@itemtype@ est défini ou si l'utilisateur n'a coché qu'un seul type d'item, elle peut afficher ses informations spécifiques (liste des champs à modifier pour l'action @update@).
29 2 moyo
30 2 moyo
MoYo : Là j'ai quelques doutes. On peut aussi simplement proposer les entrées  "Mise à jours de la mémoire / Mise à jours du processeur." comme tu l'indiques au début ?
31 1 webmyster
32 1 webmyster
h2. Comment gérer les actions spécifiques ?
33 1 webmyster
34 1 webmyster
Lorsqu'il s'agit d'actions spécifiques (ie. non gérées par la classe MassiveActions), nous pourrions associer une classe à chaque action. Cette classe contiendrait les méthodes @showSpecificMassiveActionsParameters@ et @doSpecificMassiveActions@.
35 1 webmyster
Par exemple, les actions @add_document@ et @remove_document@ renverraient la classe @Document@, toutes les actions @unlock_*@ (réunies sous la même appellation @unlock@) concerneraient la classe @Lock@. On voit que certaines actions définies dans les méthodes communes @showMassiveActionsParameters@ et @executeMassiveActions@ peuvent en sortir pour intégrer d'autres classes plus appropriées.
36 1 webmyster
Au passage, on pourrait unifier le mécanisme pour les classes du coeur et celles des plugins (avec un @Plugin::registerClass@). Nous pouvons conserver le mécanisme actuel en parallèle de ce nouveau mécanisme.
37 1 webmyster
 
38 3 moyo
MoYo ; je crois qu'au final je ne vois vraiment pas ce que tu proposes. Tu pourrai proposer une maquette même simpliste de ce que tu proposes ? 
39 3 moyo
MoYo : une idée peut-être fausse de ce que je comprend. Au lieu de mettre add_document tu veux mettre comme clé d'action Document/add par exemple (action massive add de Document) ? 
40 4 webmyster
Web : J'ai ajouté un diff (pas à jour par rapport au tronc commun car j'ai commencé ce prototype la semaine dernière). Dans ce proto, seules les actions de mise à jours et les actions liées au lock sont actives. Mais l'idée générale est là.
41 3 moyo
42 1 webmyster
_aparté_: le plugin @example@ me semble invalide car il déclare une action @do_nothing@ qui n'est pas interprétée comme l'action d'un plugin (cf. test ligne 3566 de @inc/commondbtm.class.php@).
43 1 webmyster
44 3 moyo
MoYo : normal on est pas aller jusqu'à proposer une action complète (c'est pour ca quelle s'appelle do_nothing d'ailleurs)
45 3 moyo
46 1 webmyster
Après avoir essayer de gratter un peu, je me suis rendu que dans certaines classes, certaines actions n'étaient de que des proxy vers les vraies classes. Par exemple, la vraie classe gérant @connect@ et @disconnect@ est @Computer_Item@, les autres classes (@Phone@, @Printer@ ...) n'ont défini @doSpecificMassiveActions@ que pour faire un proxy vers @Computer_Item@.
47 1 webmyster
48 3 moyo
MoYo : oui dans l'architecture actuelle cela permettait simplement de centraliser le code. Car dans les moteurs de recherche on a pas accès à l'item Computer_Item. Cf. remarque plus haut sur l'intérêt d'une maquette je pense.
49 3 moyo
50 1 webmyster
h2. Passage des méthodes en @static@ ?
51 1 webmyster
52 1 webmyster
Les méthodes de la classe @MassiveActions@ doivent être static. Ne pourrions-nous pas faire pareille pour les méthodes spécifiques (@showSpecificMassiveActionsParameters@ et @doSpecificMassiveActions@) dans les différentes classes ?
53 3 moyo
54 3 moyo
MoYo : pourquoi pas. A voir avec une proposition concrète.
55 5 webmyster
56 5 webmyster
h2. Est-il possible de supprimer l'utilisation de checkitem ?
57 5 webmyster
58 5 webmyster
Avec le mécanisme proposé, je sens qu'il est possible de se passer de @checkitem@. En fait, j'ai du mal à comprendre son utilisation ...