Bonjour,

dans mon application de forum, j'aimerai greffer un portail.

Donc je suis partag entre 2 approches :

• faire un module "portal" que j'ajouterai a mon application forum, ce qui reclamerait le moins de reflexion sur l'archi, mais qui la rendrait trop rigide il me semble,

ce qui donnerait par exemple :

• /app/forum/forum
• /app/forum/portal
• /app/forum/searchengine
• /app/forum/admin
• /app/forum/install
• /app/lib
• /app/modules/jcommunity
• /app/modules/jtags
• /app/temp

• refactorer mon application forum en plusieurs petits modules (qui iraient dans le pot commun "modules" )

ce qui donnerait par exemple :

• /app/forum/admin
• /app/forum/install
• /app/lib
• /app/modules/forum
• /app/modules/portal
• /app/modules/searchengine
• /app/modules/jcommunity
• /app/modules/jtags
• /app/temp

Quel serait votre choix et pourquoi ?

Et surtout comment passer de l'un l'autre sans casser les 3/4 de ce qui est dj fait si le choix etait le 2nd?.

merci pour vos reponses ;)

j'ai fait 2 tests :

1) 2 applications : forum / portal dans 2 rep distinct avec pour but ; utiliser le max de ce que "forum" sait faire pour reutiliser sur "portal".

ca se passe bien jusqu'au moment où j'utilise une zone de l'application forum.

Si cette zone génère une URL celle ci est relative au host de portal donc il echoue à trouver les lien vers le forum.

2) 1 application forum avec tous les modules du forum dans un repertoire commun à tout module

aucun soucis !

sauf pour les plugin utilisant des classes métiers ; je n'ai rien trouver de mieux que de mettre lesdites classes métier dans le meme rep que celui du plugin coord. precedement je faisais un require JELIx_APP_PATH. '/modules/forum/class/maclass.class.php' qui echoue si je ne change pas le path et ne copie pas la class dans le rep du plugin donc.

pour ce cas là soit

• on a de la facilité de gestion de ses modules mais la contrainte est l'installation manuelle des "responses" et plug coord propre à l'application qu'il faut ajoute dans les repertoire respectif

• on a moins de souplesse mais au moins l'arborescence établi, evite qu'on perde du temps à remettre la config d'équerre avec une installation automatique

Donc pour le moment je me vois bien mettre le portal dans le rep "commun à tout module" et garder l'appli forum "as is"

Qu'en dites vous ?

Je ne comprend pas à quoi correspondent tout les repertoires que tu as enoncé dans ton premier message. Si ce sont tous des modules, je ne vois pas où il y a problème. Si tu as bien fait tes modules forum, portal et cie, en principe tu peux les mettre où tu veux, sans que quelque chose soit cassé. C'est justement l'un des objectifs des modules.

Pour ton deuxieme message : je vois pas l'interet de faire deux applis différentes, si tu veux pouvoir utiliser tes modules forum et portal en même temps.

sauf pour les plugin utilisant des classes métiers ; je n'ai rien trouver de mieux que de mettre lesdites classes métier dans le meme rep que celui du plugin coord.

pourquoi donc ? Tu ne peux pas utiliser jClasses dans tes plugins ? et mettre donc les classes dans les modules ?

Qu'en dites vous ?

retravailler tes modules pour qu'ils puissent fonctionner de manière indépendante, et pour qu'on puisse les mettre où que l'on veuille. Il y a tout les mecanismes dans jelix pour le faire.

precedement je faisais un require JELIx_APP_PATH. '/modules/forum/class/maclass.class.php' qui echoue

ba ouai, c'est contraire à la philosophie des modules et plugins. On devrait pouvoir mettre les plugins et modules où que l'on veut sans que ça pete quelque part.

Bonjour et merci pour ces infos

Je n'imaginais pas pouvoir utiliser jClasses dans les plugins ;) donc ceci c'est corrigé.

A présent je me demande quel est "l'usage" en matière de livrable de modules/applications.

Je suis partagé entre :

• livrer une appli avec son arbo et sa config quasiment prete à l'emploi : on copie le contenue de l'archive de son appli sur son serveur web, on lance l'installation depuis son browser et c'est prêt .
• fournir les modules "seuls" et indiquer dans une longue doc comment les installer

Sachant que cette etape est très nettement plus longue puisque manuelle et sujette à erreur.

une possible alternative serait de fournir 2 types de livrable :

• un livrable entier pour toute l'appli
• un livrable par module

Comment faites/feriez vous ?

cdt.