Le 28/01/2015 08:11, Alexandre Delaunay a écrit : > Bonjour. > Comme l'a indiqué Yllen, cf Appliances
Ce plugin utilise PDF pour ses objets ET pour les onglets ajoutés aux objets du coeur. Remi. > Pour faire avancer le sujet. > > Non, on ne peux justement pas utiliser le hook $PLUGIN_HOOKS['plugin_pdf'], > le plugin customfields ajoute des champs supplémentaires à des objets du cœur > (ordinateur, moniteur, etc). > Il ne possède pas d'objets propres, enfin pas un seul qui soit intéressant > d'exposer au plugin pdf. > > De façon plus générale, cela se produit quand on étend un objet du cœur via > le hook plugin_##pluginname##_getAddSearchOptions. > Ces champs ne sont pas "exposable" au plugin pdf. > > Il faudrait que les classes du plugin pdf, prenons par exemple computer, > vérifient les champs apportés par les plugins. > via une clef de la searchaction ou via un hook supplémentaire comme indiqué > par thierry. > > + > Alexandre > > ----- Mail original ----- > >> De: "nini.lasson" <nini.las...@orange.fr> >> À: "Liste de diffusion des developpeurs GLPI" <glpi-dev@gna.org> >> Envoyé: Mardi 27 Janvier 2015 17:47:17 >> Objet: Re: [Glpi-dev] GLPI 0.84 : création par un plugin d'un nouveau hook, >> pour d'autres plugins > >> Bonjour, > >> Comme je te le disais c'est à customfield de gérer le PDF. > >> Tu créées ta class PDF et tu déclares le HOOK du plugin PDF dans ton setup >> $PLUGIN_HOOKS['plugin_pdf']['NomDeTonPlugin'] = 'NomDeTaClass'; > >> Regardes le plugin Appliances, ses données sont imprimées avec le plugin PDF. > >> Cordialement, >> Yllen > >> Le 26/01/2015 14:17, thierry DeTheGeek a écrit : > >>> Bonjour >> > >>> Je recherche une solution pour l'interopérabilité entre les plugins PDF et >>> CustomFields. >> >>> Sur le forum il y a environ 6 mois, Yllen a dit que le plugin PDF >>> fonctionne >>> avec d'autres plugins et que CustomFields a besoin d'une amélioration pour >>> que PDF puisse l'exploiter. >> > >>> Or, dans PDF je ne vois pas de mécanisme lui permettant de prendre >>> connaissance d'onglets supplémentaires apportés par CustomFields (ou >>> n'importe quel autre plugin). >> > >>> Si cela est confirmé (et c'est pour ça que j'écris à la liste), je pense >>> apporter à PDF de quoi gérer un nouveau hook que d'autres plugins pourront >>> utiliser. Reste à voir si c'est possible, car je ne trouve pas de >>> documentation où il est décrit comment déclarer un nouveau hook, et à >>> défaut, je ne connais pas de plugin offrant déjà cette fonctionnalité. >> > >>> En gros j'imagine le fonctionnement suivant : >> > >>> PDF s'initialise et déclare un hook. Dans le postinit de CustomFields, ce >>> dernier enregistre une méthode sur ce hook. Quand PDF voudra générer une >>> vue >>> d'un objet, il déclenchera le hook, ce qui donnera l'occasion à >>> CustomFields >>> de générer la vue pour les champs personnalisés. >> > >>> les méthodes recevront le type ainsi que l'ID de l'élément à traiter. >> > >>> Ca me parait être une bonne approche, en particulier pour Custom Fields, >>> dont >>> le contenu ne peut pas être connu par PDF, contrairement aux objets figés >>> et >>> gérés par GLPI lui-même. >> > >>> _______________________________________________ >> >>> 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 > > > > _______________________________________________ > 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
