tu aies besoin de stocker autant, c’est colossal (question de point de vue du coup)
dans ce champ: un tag doit faire probablement faire max 10 caractères; avoir 10 tags ca semble déjà beaucoup et pas exploitable mais au total ca ne fera qu’une centaine de caractères; même si mon évaluation est ridicule et qu’on fait encore x10 on arrive à 1000… alors 6000 ?!?
Est ce que tu détournes ce champs pour un autre usage?
Oui, c’est pour un usage détourné que je voulais utiliser ce champ.
Pour le développement de mon plugin, mon besoin est d’invoquer la méthode d’instance eqLogic.->toHtml(‹ dashboard ›).
Si j’ai bien compris, c’est une méthode:
qui n’accepte le passage que d’un argument ($_version)
qui est utilisable à partir du plugin (sinon utilisée par le Core)
Je souhaite y passer une liste constituée de nom de fonction et de leur ID.
Donc, je pensais utiliser le champ tag pour passer cette liste … voila.
J’ai cherché et je n’ai pas trouvé ou et comment le Core choisit de basculer sur la méthode toHtml lorsqu’elle est définie dans la class du plugin ?
Du coup, je n’ai pas encore osé modifier la liste des arguments passés à cette méthode dans le plugin de peur de rencontrer (un jour ?) un retour d’erreur.
Je cherche continuellement la robustesse de mon code.
Le core utilise la fonction toHtml lorsque celle-ci existe de mémoire.
Le champ tag est modifiable par l’utilisateur donc je n’y mettrais pas une info de config que tu veux contrôler. De plus le champ est utilisé pour recherche/filtre à l’affichage; l’utiliser risque de casser l’affichage.
Tant qu’ils ont des valeurs par défaut aucun risque mais vu que c’est le core qui appelle la méthode et pas toi, je n’en vois pas l’intérêt
Je n’ai pas trop compris ce qu’est
Mais ca ressemble à une configuration pour modifier le widget?
Pourquoi ne pas stocker la config que tu veux dans la « configuration » de l’éqLogic?
Oui, la fonction toHtml est appelée par le Core mais elle est paramétrable (utilisable) dans le template du plugin.
Tu peux donc modifier son code selon ton besoin.
Dans ce cas, c’est cette version qui est appelée et c’est « ou c’est décidé » dans le Core que je n’ai pas trouvé, mais cette question est secondaire.
Oui, comme le champ tag, c’est un autre champ de l’eqLogic.
Plus adapté à des données de configuration, tu as entièrement raison.
J’espère que celui ci n’est pas trop limité au niveau de sa taille dans la DB.
Je vais essayer cette solution.
Utiliser le champ Configuration pour passer mes paramètres … de configuration est effectivement plus logique et plus propre.
Comme on dit, je me suis fait des noeuds au cerveau à vouloir utiliser le champ tag.
De nouveau, je te remercie pour ton aide et pour m’avoir remis sur le bon chemin
Il est toujours interessant de tirer un enseignement et donc j’ai mis le doigt sur la contrainte des limites de taille des champs de la DB.
Tu aurais une idée de l’endroit ou on peut avoir accès cette info ?
Sinon, pas grave et nous pouvons donc fermer ce post avec sa solution.
Il faut juste faire attention à la configuration : lors de l’enregistrement de l’eqLogic, ce champs est mis à jour et il y a un risque d’effacer ce qui est utile pour le widget surtout si c’est spécifique comme ça…
Je ne dis pas que vous allez forcément vous planter, j’attire juste votre attention sur le fait que la configuration est un peu particulière pour les eqLogic et les commandes et le fait d’y ajouter des informations qui ne sont pas dans la page de configuration demande de les ajouter volontairement (eqLogic.preSave() par exemple).
Et merci pour la remarque.
Oui, je suis conscient qu’il faut bien faire attention à ne pas effacer les infos déja existantes dans le champ Configuration lorsque l’on ajoute d’autres.
Par contre, la mention à (eqLogic.preSave() par exemple), je ne comprends pas trop ?