Modification d'un composant et dev client/serveur

Je ne suis pas familier de l’utilisation des composants. Plutôt que d’installer le composant lui-même, on peut le remplacer par un alias.
La doc dit “Cette possibilité est particulièrement utile en phase de développement du composant car toute modification effectuée dans la base matrice est immédiatement reportée dans toutes les bases hôtes.”
C’est vrai aussi en développement c/s ? J’ai l’impression que je suis obligé de relancer le serveur pour bénéficier des modifications. On peut faire moins ?

Bonjour Eric,

De part expérience, il est effectivement nécessaire de redémarrer le serveur (ou l’application) qui utilise le composant.
SI il y a une astuce, je n’ai pas trouvé

Patrick

: Patrick EMANUEL

Si il y a une astuce, je n’ai pas trouvé
Moi non plus et je ne crois pas qu’il y en ait une, d’après ce que j’ai compris du fonctionnement. Quand le serveur 4D ouvre un 4DB, il examine le dossier “Components” et en compacte les éléments un par un dans “Components/cache” sous la forme “monComposant.4darchive”, puis il liste tout ça dans le fichier “Components/cache/Cache.xml”. Après quoi il “sert” ces éléments au client qui se connecte, lequel se charge de les décompresser dans ses ressources locales. Les dossiers “Resources” et “Plugins” marchent de la même façon.

Quand aux alias, je m’en sers mais dans un autre but (puisque de toutes façons on doit redémarrer) : avec un alias du composant dans “Components”, je peux facilement avec “Lire les informations” rediriger mon alias vers telle ou telle version d’un composant (plus récent, compilé/interprété, etc). Ça évite également de multiplier les copies d’un composant utilisé par plusieurs bases - un seul machin pour les rassembler tous, quoi.

: Eric TROTTA

La doc dit “Cette possibilité est particulièrement utile en phase de
développement du composant car toute modification effectuée dans la
base matrice est immédiatement reportée dans toutes les bases hôtes.”
PS
c’est mal formulé : en monoposte il faut aussi ré ouvrir la base hôte pour qu’elle prenne en compte les modifications du composant. Et encore, pas toujours : pour être certain que la modification du composant soit prise en compte, je compile le composant avant de relancer l’hôte.

Le code d’un composant est sans doute lu une fois pour toute au démarrage de l’hôte car il m’arrive souvent de remplacer un composant par un autre alors que l’hôte est lancée, ça ne lui fait ni chaud ni froid.

si je déplace le 4DD il réagit nettement plus :mrgreen:

Oui il te faut relance 4D Server en C/S et 4D quand tu es en monoposte, après avoir modifié ton composant.

Et celà peu importe que le composant soit compilé ou interprété sous forme d’alias ou pas.

: Arnaud DE MONTARD
: Eric TROTTA
c'est mal formulé : en monoposte il faut aussi ré ouvrir la base hôte pour qu'elle prenne en compte les modifications du composant. Et encore, pas toujours : pour être certain que la modification du composant soit prise en compte, je compile le composant avant de relancer l'hôte.

Ah ben ok, si même en monoposte faut quitter et relancer ! Et là, du coup, c’est plus que mal formulé !
Pour utiliser en compilé, faut juste compiler (…) ou quand tu déplaces le composant, y’a des choses à enlever ou autre ? (dit autrement, comment on sait qu’on est bien en compilé ?)
Merci à tous les 2, je voulais pas passer à côté d’un truc bête. Et donc, s’il faut relancer le serveur, si on veut bouger le composant, c’est pas là qu’il faut le debugger…

Si tu veux debugger, il faut utiliser trace car le point d’arrêt ne fonctionne pas en tant que tel.
C’est donc une partie de plaisir dans laquelle tu entre car à chaque modification, tu redémarres.

Ce que je fais, c’est avoir le composant ouvert à côté (je le lance en premier), puis je lance en mono (ou serveur) après. Mais dès que j’ai modifié un ou deux trucs qui me bloquaient, là, je redémarre.
En mode C/S, il faut tout de même faire attention au trace qui peut se lancer sur le serveur et non sur le client.