PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WEBDEV 2024 → Approche pour partager des éléments entre 2 projets
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