Discussion :

[law56100]

Bonjour

Expert en windev, confirmé en windev mobile et programmation orienté objet.

Je m’autoforme en webdev pour de nouveaux projets.

Je voudrais faire un modèle, liste fiche en mode programmation objet comme pour windev et windev mobile.

Ma problématique

Une page liste qui affiche la liste des clients avec les boutons voir/Ajouter/modifier/supprimer pour communiquer avec une page Fiche client.


Windev

BTN_Modifier

1 – déclare un objet client.

2 – récupère la ligne sélectionnée dans la table.

3 – charge l’objet client.

4 – ouvre la fenêtre client en mode modifié et l’objet client chargé.

4.1 – si la fenêtre renvoie vrai => mise à jour de la ligne dans la table avec l’objet client


Windev mobile

1 – déclare un objet client // Objet déclaré globale à la fenêtre au lieu du bouton car besoin l’événement de fermeture d’une fenêtre fille.

2 – récupère la ligne sélectionnée dans la table.

3 – charge l’objet client.

4 – ouvre la fenêtre client en mode modifié et l’objet client chargé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
//Évènement fermeture fenêtre fille
 
Si MaFenêtreFille= fen_client _et_ MaFenêtreFille..valeurRenvoyé=vrai alors
 
        5 => mise à jour de la table avec l’objet client

fin

Webdev

Si je comprends bien si je passe de la page liste à la page fiche et que je reviens sur la page Liste => les pages sont de nouveau recharger. => Chargement du tableau d’objet (appel à la BDD) => chargement de la page.

Du coup, j’ai juste à savoir sur lequel enregistrement, il travaillait pour me repositionner dessus.


- Rad webdev

J’ai réalisé un projet webdev avec un fichier client et utiliser le rad pour voir comment webdev réalisait leur communication.

Ils ont créé une collection de procédures gérant le RAD « procedures_globales_de_pattern_RAD_AWP »



Question n°1 : comment avez fait pour communiquer entre vaux pages ?

Question n°2 : en windev et windev mobile, je travaille beaucoup sur l’objet pour faire le moins d’appel possible à la base de données. Ici en Webdev, j’ai la sensation qu’à chaque page je suis obligé de recharger la page bien sûr mais aussi d’aller chercher les données en base. Hormis de déclarer en global les tableaux d’objet.

Cordialement Law

[Ry_Yo]

Bienvenu dans le monde merveileux de WebDev
Ca faisait bien 1-2 ans si ce n'est plus que je n'avais pas remis les pieds ici ^^

Concernant tes questions, tu as forcément plusieurs possibilités pour résoudre tes soucis....

Mais avant toute chose :
Dév. Windev qui se met au Web, ça veut dire : je fais faire comme en Windev mais en Web --> mauvaise idée ! très mauvaise idée ^^
Dév POO sur WebDev --> Bonne idée quelque soit la plateforme cible ^^

Donc de manière globale, il faut arrêter de penser en terme d'application qui est "un site web"
L'approche serait plutôt d'imaginer 2 programmes Windev qui vont se retrouver sur le web (le côté serveur et le côté client)
et j'aurais encore énormément de prérequis à étaler pour les dév Windev qui se mettent au Web....
- l'abus de champ masqué (parce qu'on ne comprends pas pourquoi ça marche pas mais que quand je mets un champ invisible ça marche...)
- la cyber-sécurité ou contrôle uniquement côté client
- etc...^^

Concernant tes remarques, les dev WD,WM ne se rendent pas compte qu'ils utilisaient mal le modèle 3-tiers ou MVP. Car la limite est fine entre la couche métier et la couche présentation... la couche Data est évidente par contre....
Avec WB, ces 3 couches prennent tout leurs sens... Data / métier / présentation --> BDD / côté serveur / côté client
Donc pour éviter des "clignotements", des aller/retour inutile, etc... t'as intérêt à bien ranger tes objets et appels....

Bref... Pour revenir sur ta question initiale, ça va dépendre du besoin. Mais généralement je préfère mettre en place une page de type SPA (Single Page Application)
Dans notre jargon WLangage, ça correspond à l'utilisation de plan : un plan liste et un plan fiche avec chargement différé
Concernant la page liste, j'ai une préférence pour les ZoneRépétée elles permettent plus de souplesse s'il doit y avoir bcp d'interaction. Si c'est une simple liste, alors un champ table est largement suffisant...

Si tu préfères rester sur un concept de page liste / fiche alors par simple passage de paramètres à la page pour conserver le contexte....

Le sujet est vaste... on pourrait discuter des choix techniques longuement...