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
