|
Approche pour partager des éléments entre 2 projets |
Débuté par benicourt, 09 oct. 2017 10:35 - 5 réponses |
| |
| | | |
|
| |
Membre enregistré 48 messages |
|
Posté le 09 octobre 2017 - 10:35 |
Bonjour, Je m'interrogeais sur l'approche la plus pertinente pour partager des éléments entre 2 projets, sachant que l'interface graphique change considérablement d'un projet à l'autre. De fait, il me semble que c'est surtout le code lié aux pages et la base de données. Cependant, le code est aussi très proche des objets contenus dans une page (tables, autres champs, etc.) ...
Le coté composant ne me semble donc pas approprié.
Comment verriez-vous les choses de votre coté ? Quels sont les meilleurs moyens de tenir à jour 2 sites ayant sensiblement des codes sources similaires, mais avec une interface graphique totalement repensée ?
Par avance, merci.
-- Mes blogs: www.benicourt.com |
| |
| |
| | | |
|
| | |
| |
Posté le 09 octobre 2017 - 11:35 |
benicourt avait énoncé :
Bonjour,
Je m'interrogeais sur l'approche la plus pertinente pour partager des éléments entre 2 projets, sachant que l'interface graphique change considérablement d'un projet à l'autre. De fait, il me semble que c'est surtout le code lié aux pages et la base de données. Cependant, le code est aussi très proche des objets contenus dans une page (tables, autres champs, etc.) ...
Le coté composant ne me semble donc pas approprié.
Comment verriez-vous les choses de votre coté ? Quels sont les meilleurs moyens de tenir à jour 2 sites ayant sensiblement des codes sources similaires, mais avec une interface graphique totalement repensée ?
Par avance, merci.
Bonjour,
pb evidemment récurrent
Basiquement, nous utilisons le GDS pour partager les collections de procédures et les classes.
Après nous avons créé des projets modules, plus pour des fonctions de back office, et on les appelle avec des sitesDynamiquesAffiche
Un peu compliqué les allers et retours entre sites appelés et appelants On a des feuilles de css personnalisés pour changer certains aspects graphiques.
Mais on a invariablement des soucis sur des projets qui ne sont pas au même niveau que d'autres.
Il y a très très longtemps, on avait essayé de toujours tout gérer avec le même projet. TRES TRES mauvaise idée. Webdev n'aime pas les gros projets, trop de plantages. La mise en prod qui a alors trop d'impacts. Sachant que les mises en prod à la page ça fonctionne quand ça veut. Et sur les gros projets, souvent ça ne veut pas fonctionner du tout. Nous avons des projets où nous savons qu'il est impossible de compter sur les prods à la page.
Donc créer des petits projets est préférable pour la maintenance
et les composants, c'est pire que tout. Pour avoir été une fois obligé de tout redévelopper en 1 we, plus jamais je n'utiliserais cela.
--- Cet email a fait l'objet d'une analyse antivirus par AVG. http://www.avg.com |
| |
| |
| | | |
|
| | |
| |
Posté le 09 octobre 2017 - 15:08 |
Bonjour,
Je rejoins Eric pour la plus part de sa réponse. La différence se situant sur la non viabilité des "gros" projets sous Webdev. la majeure partie de nos projets peuvent être considérés comme "gros" et aucun plantage récurrent ne subsiste longtemps.
Pour répondre à la question initiale, je dirais que ce genre de préoccupations impose une réflexion en amont. Très en amont. Au delà des facilités offertes par entre autre le GDS ,en particulier sur l'architecture des projets. Nous sommes justement en train de travailler sur le sujet et la meilleure réponse que nous ayons trouvé se résumé à SOA. C'est une architecture qui va séparer tout ce qui est traitement des données du traitement IHM. Ainsi, dans l'objectif de pouvoir mutualiser des collections de procédures ou des classes, via le GDS, il n'y a pas mieux à mon avis.
Cordialement |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 48 messages |
|
Posté le 11 octobre 2017 - 09:07 |
Merci à vous deux pour ces réponses, je crains d'en être arrivé également aux même conclusions. Il manque peut-être à Webdev cette facilité à implémenter une architecture séparant l'interface, le code et les données. Rien ne l'empêche en effet, on peut passer par des abstractions au travers des classes, faire des procédures prenant l'interface en entrée, etc. Mais, ça manque d'automatisme... Je reste preneur de conseils à ce sujet, merci encore.
-- Mes blogs: www.benicourt.com |
| |
| |
| | | |
|
| | |
| |
Posté le 11 octobre 2017 - 09:47 |
benicourt avait énoncé :
Merci à vous deux pour ces réponses, je crains d'en être arrivé également aux même conclusions. Il manque peut-être à Webdev cette facilité à implémenter une architecture séparant l'interface, le code et les données. Rien ne l'empêche en effet, on peut passer par des abstractions au travers des classes, faire des procédures prenant l'interface en entrée, etc. Mais, ça manque d'automatisme... Je reste preneur de conseils à ce sujet, merci encore.
oui mais ne nous y trompons pas le plus gros du travail dans un site est la mise en place des éléments,les positionnements, la présentation bref tout le jolibô comme disait un de mes anciens acolytes.
Tout ce que l'on peut appeler "l'intelligence" ou les règles métiers, c'est certes important, mais cela va se retrouver dans assez peu d'endroits. Et là, il est facile si besoin d'externaliser ce code, dans un webservice par exemple.
Donc c'est assez difficile de trouver la bonne approche. Moi je cherche et j'expérimente des solutions depuis 15 ans sur ces produits... pas encore trouvé la panacée
--- Cet email a fait l'objet d'une analyse antivirus par AVG. http://www.avg.com |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 265 messages Popularité : +14 (16 votes) |
|
Posté le 11 octobre 2017 - 17:59 |
Bonsoir à vous deux,
Je viens de tomber sur ça dans le doc WB, qui m'a fait penser au sujet de ce topic :
"De plus, les modèles de champs sont un fichier au format ".WDT" qui peuvent être facilement transférés d'un projet à un autre."
Ici : http://doc.pcsoft.fr/fr-FR/?9000095
Bon Dev !!
-- René MALKA |
| |
| |
| | | |
|
| | | | |
| | |
|