Bonjour,

Je vais peut-être passer pour l'idiot de service...

J'ai fait un premier site web dont j'aimerai réutiliser en grande partie le code pour faire un deuxième site similaire. Pour ce faire j'essaye d'utiliser en grande partie le mécanisme de surcharge ce qui me permet de ne pas toucher au code d'origine et donc de pouvoir faire des mises à jour uniformément sur les deux versions sans trop de risques.

Dans mon code, j'ai créé plusieurs classes métier pour externaliser des fonctions et alléger le code du contrôleur par exemple. Entre autre, j'y place des fonctions qui appellent la BDD et que je ne peux pas faire par DAO (requêtes complexes). Le problème c'est que j'avais hâtivement étendu le mécanisme de surcharge aux classes et que depuis une petite heure (Ok je ne suis pas un vif) je m'escrime à comprendre pourquoi mon code ne marche pas...

Est-ce que je me trompe de concept ? Comment peut-on modifier le comportement d'une classe existante sans toucher au code d'origine ? Je pense que le mécanisme d'héritage de la POO permet ça facilement mais par contre je ne vois pas concrètement comment faire...

Si quelqu'un à une idée...

Merci, Yan.

Je pense que c'est plus un cas de POO en effet. Que souhaites-tu faire concrètement ? Et pourquoi surcharger l'ancienne classe ? J'aurai plutôt tendance à faire une classe globale réutilisable partout, quitte à faire hériter cette classe par une autre qui fait des trucs spécifiques pour un site spécifique, non ?

Le but c'est de ne pas avoir à toucher au répertoire de mon module (qui s'appelle "public" en l'occurrence). Dans l'idéal ce répertoire serait le même pour les deux sites web, avec un symlink de l'un vers l'autre. Tous les fichiers "propres" au deuxième site seraient dans un template ou un le var/overload. Ca a aussi l'avantage de permettre un inventaire rapide des fichiers qui demandent une mise à jour spécifique.

Je peux peut-être m'en sortir en mettant des constantes ou des variables "globales" (pas nécessairement dans le sens de PHP) dans un fichier de config ou un include dans le var. Je vais creuser.

Merci, Yan.

J'entendais plus faire des classes métiers de base. Si tu en as besoin, tu les copie sur ton application et tu fait hériter d'autres classes spécifiques à ton application. Ainsi, tes classes métiers de base ne sont jamais modifiées.

Lors d'une mise à jour, il faut alors recopier ces fichiers dans ton appli.

Le problème c'est que je ne vois pas ce que tu fais côté prog, pourquoi un tel besoin ? Peux-tu donner un exemple concret ?

La solution avec Jelix en découlera, ce que tu expliques c'est déjà la solution à laquelle tu penses, pas ton problème de départ :)

Bonjour à tous,

J'ai enfin eu un peu de temps pour me consacrer à ce problème. J'ai trouvé mon bonheur avec jIniFileModifier . J'ai modifié mes classes pour qu'elles fasse appel à un fichier de configuration et ca y est, l'intégralité de mon module est commun à mes deux sites (deux applis), les différences sont situées dans le /var de l'appli, en particulier dans le var/config, var/overload et var/themes . Même mes répertoires "plugins" et "response" sont communs aux deux applis.

La doc de jIniFileModifier était un peu ambigüe sur l'info à fournir comme nom de fichier (base du chemin d'accès), je l'ai donc enrichie (avec un exemple) pour clarifier.

Yannick.

Il faut éviter d'utiliser jIniFileModifier pour simplement lire un fichier ini. Il faut dans ce cas plutôt utiliser parse_ini_file. C'est bien plus performant.