Bonjour à tous,
Petit soucis de dev:
Je veux écrire des données dans le champ « tag » d’une instance eqLogic.
Mes données sont un peu longues (OK ?) soit 5790 caractères mais je me récupère un message d’erreur du core qui indique « Data too long … »
Je suis un peu surpris 
Parce 5790 à notre époque, c’est pas si colossal …
Quelqu’un aurait des infos sur les limitations de ce coté et peut être comment les contourner ?
Merci d’avance
Salut,
Moi je suis doublement surpris pas qu’un peu que
Est ce que tu détournes ce champs pour un autre usage?
Bonjour @Mips ,
Je te remercie pour ton retour.
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:
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.
Tu aurais une idée sur cette question ?
La fonction toHtml n’est pas appelée par le plugin en principe mais uniquement par le core; je ne comprends pas ce que tu veux dire ici:
Y a un peu de doc à ce propos: https://doc.jeedom.com/fr_FR/dev/widget_plugin
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.
Je te remercie pour ton aide 
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.
Encore merci et bonne fin de journée.
L’info de la taille du champ?
Le fichier décrivant l’état est dans le répertoire install je dirais
Ou via sql en db évidemment
Bonjour,
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).
A+
Michel
Bonjour @Michel_F ,
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 ?
J’aurais tendance à répondre : vous verrez quand vous ferez vos premiers tests
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.