[Glpi-dev] Possibilitées du reloadTab

2011-09-20 Thread Damien Touraine

Bonjour,
Il est possible d'utiliser le reloadTab pour faire des modifications 
dans l'onglet sans pour autant imposer le rechargement de la page en 
entier (et donc, sans perdre les données saisies dans la partie commune 
de l'item). Cela permet, en outre, de mettre à jours la base de donnée 
lors de l'appel de la méthode displayTabContentForItem. Ainsi, la mise à 
jours de la base de donnée est dans la même méthode que le formulaire 
qui vise à la modifier.


Par exemple, dans le patch ci-joint, cela permet d'ajouter ou de retirer 
un composant plus simplement (avec, au passage, un contrôle plus fin de 
la multiplicité des composants). Ainsi, la mise à jour de la base de 
donnée se passe en tête de la méthode showForComputer, alors que les 
clics de modification son 85 et 99 lignes plus bas).


C'est un mode de procéder que je n'ai pas rencontrer précédemment. Cela 
me semble facilité par le nouveau mode de fonctionnement des onglets 
(gestion des onglets par les classes elle-même et non par des appels AJAX).


* Doit-on éviter d'utiliser ce type de mécanisme ?
* Est-ce acceptable comme manière de procéder ?
* Est-ce une piste d'évolution souhaitable/souhaitée pour l'avenir ?

Damien

--

Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS
Groupe de RVA VENISE, (http://www.limsi.fr/venise/)
Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64


Index: computer_device.class.php
===
--- computer_device.class.php   (revision 15701)
+++ computer_device.class.php   (working copy)
@@ -187,6 +187,23 @@
static function showForComputer(Computer $computer, $withtemplate='') {
   global $DB, $LANG;
 
+  if (isset($_POST['deviceAction'])  isset($_POST['devicetype'])){
+$compdev = new Computer_Device();
+if (($_POST['deviceAction'] == 'add') 
+isset($_POST['computer']) 
+isset($_POST['devices_id'])) {
+   $input = array('computers_id' = $_POST['computer'],
+  'itemtype' = $_POST['devicetype'],
+  'items_id' = $_POST['devices_id']);
+   if ($compdev-can(-1, 'w', $input)) {
+  $compdev-add($input);
+   }
+} else if (($_POST['deviceAction'] == 'remove') 
+   isset($_POST['computerdevice_id'])) {
+   $compdev-removeComputerDevice($_POST['devicetype'], 
$_POST['computerdevice_id']);
+}
+  }
+
   $devtypes = self::getDeviceTypes();
 
   $ID = $computer-getField('id');
@@ -201,8 +218,9 @@
 ' method='post';
  echo input type='hidden' name='computers_id' value='$ID';
   }
+  $global_colspan = 64;
   echo table class='tab_cadre_fixe' ;
-  echo trth 
colspan='63'.Toolbox::ucfirst($LANG['log'][18])./th/tr;
+  echo trth 
colspan='$global_colspan'.Toolbox::ucfirst($LANG['log'][18])./th/tr;
   $nb = 0;
 
   $specificity_units = array('DeviceProcessor'   = $LANG['setup'][35],
@@ -210,6 +228,7 @@
  'DeviceHardDrive'   = $LANG['common'][82],
  'DeviceGraphicCard' = $LANG['common'][82]);
 
+  $numberOfPreviousItem = 0;
   foreach ($devtypes as $itemtype) {
  Session::initNavigateListItems($itemtype,
 $computer-getTypeName(). = 
.$computer-getName());
@@ -226,74 +245,96 @@
  $fk= 
getForeignKeyFieldForTable(getTableForItemType($itemtype));
 
  $query = SELECT COUNT(*) AS NB,
-  `id`,
   `$fk`
-  $specif_text
FROM `$linktable`
WHERE `computers_id` = '$ID'
-   GROUP BY `$fk` $specif_text;
+   GROUP BY `$fk`;
+foreach ($DB-request($query) as $deviceFromSQL) {
+   if ($numberOfPreviousItem * $deviceFromSQL['NB']  1)
+  echo trtd colspan='$global_colspan'hr/td/tr;
+   $numberOfPreviousItem = $deviceFromSQL['NB'];
+   $query = SELECT `id`,
+`$fk`
+$specif_text
+  FROM `$linktable`
+  WHERE `$fk` = '.$deviceFromSQL[$fk].'
+  ORDER BY id;
+   $first = true;
+   foreach ($DB-request($query) as $data) {
+  Session::addToNavigateListItems($itemtype, $data[$fk]);
 
- $prev = '';
- foreach ($DB-request($query) as $data) {
-Session::addToNavigateListItems($itemtype, $data[$fk]);
-
-if ($device-getFromDB($data[$fk])) {
-   echo tr class='tab_bg_2';
-   echo td class='center';
-   Dropdown::showInteger(quantity_.$itemtype._.$data['id'], 
$data['NB']);
- 

Re: [Glpi-dev] Possibilitées du reloadTab

2011-09-20 Thread Remi Collet
Le 20/09/2011 16:07, Damien Touraine a écrit :
 Bonjour,
 Il est possible d'utiliser le reloadTab pour faire des modifications
 dans l'onglet sans pour autant imposer le rechargement de la page en
 entier (et donc, sans perdre les données saisies dans la partie commune
 de l'item). Cela permet, en outre, de mettre à jours la base de donnée
 lors de l'appel de la méthode displayTabContentForItem. Ainsi, la mise à
 jours de la base de donnée est dans la même méthode que le formulaire
 qui vise à la modifier.
 
 Par exemple, dans le patch ci-joint, cela permet d'ajouter ou de retirer
 un composant plus simplement (avec, au passage, un contrôle plus fin de
 la multiplicité des composants). Ainsi, la mise à jour de la base de
 donnée se passe en tête de la méthode showForComputer, alors que les
 clics de modification son 85 et 99 lignes plus bas).
 
 C'est un mode de procéder que je n'ai pas rencontrer précédemment. Cela
 me semble facilité par le nouveau mode de fonctionnement des onglets
 (gestion des onglets par les classes elle-même et non par des appels AJAX).
 
 * Doit-on éviter d'utiliser ce type de mécanisme ?
 * Est-ce acceptable comme manière de procéder ?
 * Est-ce une piste d'évolution souhaitable/souhaitée pour l'avenir ?

Au départ, le reloadTab a été ajouté essentiellement pour gérer le
pager, et/ou pour la navigation.

Autant, l'idée de ne pas recharger la page complète me semble
intéressante (à part de pbm de maj des compteurs sur les onglets),
l'implémentation me dérange un peu.

En particulier le traitement du formulaire dans le showForComputer.

J'aurais plutôt vu un traitement générique dans le common.tabs, genre

si ($_POST['execute']
 method_exists('classegérantlonglet', $_POST['execute'])) {
call_user_func(array('classegérantlonglet', $_POST['execute']),
   $_POST)
}

Comme c'est déjà le cas pour les dropdown

MoYo a déjà beaucoup réfléchit vers la bascule sur un modèle MVC, où
beaucoup de choses devront être génériques et décrites dans les classes.


P.S. d'ailleurs, faudrait mettre un prefixe pour éviter les appels non
prévus...



 
 Damien
 
 
 
 ___
 Glpi-dev mailing list
 Glpi-dev@gna.org
 https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] Possibilitées du reloadTab

2011-09-20 Thread Remi Collet
Le 20/09/2011 19:17, Remi Collet a écrit :

 Au départ, le reloadTab a été ajouté essentiellement pour gérer le
 pager, et/ou pour la navigation.

Autre petit soucis, le reloadTab() permet uniquement d'ajouter des
options. Donc l'option deviceAction sera conservée. Tu risques de
faire plusieurs fois la même action... ou d'avoir des paramètres pas
prévu :(

Et récupérer les données d'un formulaire plus compliqué pour les
envoyer... (donc, en javascript)

+

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev