Bonjour,

Je vais avoir la chance de disposer d'un stagiaire pendant 2 mois pour redévelopper certaines applications de notre intranet et notamment une GMAO que j'ai développé grâce à des scripts "faits-maison". L'idée est d'harmoniser le code source de l'application, de le rendre "exportable" et en profiter pour rajouter les fonctionnalités dont les services sont demandeurs et qu'il est difficile aujourd'hui d'implémenter vue la quantité de "bricolages" que j'ai du rajouter au fil des années.

Le stage ne commence qu'en février, il me reste donc un peu de temps pour préparer les docs pour que le stagiaire soit le plus autonome possible.

J'ai néanmoins quelques questions concernant l'utilisation de Jelix comme framework et j'aimerai vos conseils.

Par exemple, notre GMAO a besoin de connaitre les interventions (avec des actions pour chacune des interventions), de la documentation et des équipements.

Comment organiser mon applicatif ?

Je pensai utiliser :

• un module "interventions" avec tout ce qui concerne en détail une intervention (et notamment les actions liés à chacune des interventions).
• un module "documentation" avec tout ce qui concerne les docs (ajout/suppression/...)
• un module "équipements" pour ce qui concerne ... les équipements

Est-ce judicieux ? Vaut-il mieux un gros module (ce dont je doute) ? Vaut-il mieux découper encore plus (un module spécifique pour les actions par exemple) ?

En gros, quel est le champ d'application idéal d'un module ?

Questions subsidiaires, si vous connaissez glpi, j'adore leur back-end d'authentification et la possibilité de rajouter des serveurs CAS ou LDAP, les prioriser ou n'utiliser que la base de données. Je comptai faire faire ça au stagiaire comme "premier TP" en ne mettant que la base de données et la possibilité de mettre un ou plusieurs serveurs LDAP. Est-ce que ça existe déjà ? Je préfère nettement utiliser quelque chose d'existant, quitte à retoucher la mise en page, plutôt que de réinventer la roue et refaire les mêmes erreurs qu'un éventuel prédecesseur ;)

Merci

Bonjour,

pour le découpage en module, tout va dépendre de l'importance de tes modules. Si chaque module que tu prevois de développer ne contient qu'un pauvre controleur avec deux actions, peut-être vaut-il mieux faire qu'un module. Sauf si tu prevois assez rapidement de faire de gros développement.

Si tes trois modules vont contenir chacun beaucoup de contrôleurs ou actions, peut être vaut il mieux découper encore plus.

Le découpage, se fait donc en fonction de ton appli. il n'y a pas de recette magique.

Je dirais juste que là, vu l'exemple que tu as donné, tu as bien compris le principe des modules, et c'est le plus important :)

Un autre conseil : en général, on séparera frontend et backend dans des modules différents. Par ex, un module news pour l'affichage, mais pour gérer les news, on fera un module admin_news. Cela facilite la gestion des droits et surtout la configuration de la sécurité d'accés aux modules dans la conf de chaque point d'entrée.

Pour l'authentification ldap et cie, il y a un plugin ldap pour jAuth, mais il ne gère pas les ldaps multiples ou autres. Il y a bien sûr aussi un plugin db pour jAuth. Tu peux donc activer l'un ou l'autre des plugins, mais tu ne peux pas les utiliser en même temps.

Si tu as des besoins spécifiques comme tu viens de citer, rien n'empêche à mon avis de faire ton propre plugin pour jAuth (quitte à reprendre le code d'un plugin existant), qui ira chercher dans plusieurs ldap ou autre.

Bonjour,

samche65 écrivait:

Vaut-il mieux découper encore plus (un module spécifique pour les actions par
exemple) ?

Je plussois laurentj et j'ajouterai ...

Si les contrôleurs deviennent très volumineux, il faudra songer à créer une (des) classe(s) "métier" qui se chargeront de tout ce qui n'est pas spécifique à une action (telle une règle de calcul financier par exemple) et dans chacune des actions concernées appelée la classe métier à bon escient genre :

 if ( jClasses::getService('interventions~check')->CeciCela() ) {... }

samche65 écrivait:

En gros, quel est le champ d'application idéal d'un module ?

Il faut essayer de garder en tête une petite chose :

si demain j'ai besoin d'un seul de ces 3 modules ailleurs (dans une autre application), pourra-t-il être utilisé indépendamment des autres ?

Si oui alors c'est un vrai beau module, sinon il est dépendant d'autres modules et là soit on n'a pas le choix (et ça peut arriver), soit on peut l'améliorer pour le rendre indépendant (donc +souple donc +maintenable), et jelix a tout ce qu'il faut pour cela , comme par exemple jEvent pour assouplir les communications inter modules.

cdt.

Il faut procéder à une petite gymnastique que j'ai décrite dans 2 articles ci dessous

• Création de Modules Génériques "Jelix" (1/2)
• Création de Modules Génériques "Jelix" (2/2)

ainsi l'une des 2 tables on aura 2 colonnes supplémentaires

`id_source` (contenant l'id de l'autre table) `source` (contenant une string, si besoin, de l'autre table toujours)

ca peut aussi etre une 3 ieme tables qui fait la jointure entre les 2 mais l'idée reste la même lors des manipulations des données (cf methode save décrite dans le 1ier article )

Bonne continuation ;)

en fait, un module en général, correspond à un domaine fonctionnel. pour afficher des news, tu vas faire un module, mais dedans, tu ne vas en principe pas afficher un annuaire en plus, tu feras pour ça un module annuaire.

comme dis foxmask, penser à la reutilisabilité. Cependant, il arrive, pour tes domaines fonctionnels complexes, pour une application complexes, que l'on ne puisse pas rendre indépendant un module, et ça peut être normal. dans ce cas, il faut plusieurs modules pour couvrir un domaine fonctionnel. cependant, on s'attachera à découper ce domaine en plusieurs partie -> ça te fait tes modules.