Grille de saisie coté client

Question

Salut à tous, pas très au point en ASP.Net, et en dev web en général, je rencontre un petit soucis sur un intranet.

J'ai besoin d'avoir, coté client une grille de saisie non liée à une source de données.

Je sais pas trop comment faire.

J'étais parti sur une gridview vierge et un panel avec quelques contrôles de saisie et un bouton pour rajouter la saisie en tant que ligne de la gridview, le tout par le code-behind. Mais je ne sais pas comment rajouter une ligne à une gridview.

Auriez-vous quelques conseils ou une idée de comment faire ma page?


[i][b]---- Sevyc64  (alias Casy) ----
[hr]# LE PARTAGE EST NOTRE FORCE #/b/i

Mayzz · Answer

Salut Casy !

Ton post date de plus de 15j donc j&#8217;espère que tu as progressé depuis. Si ce n'est pas le cas :

Lorsque tu dis "Coté client" tu veux dire que le code des contrôles devra être exécuté coté client ou bien tu parles de l'affichage ?

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_casy · Answer

Oui, j'ai progressé, j'ai abandonné la grille pour un formulaire simple de saisie en direct sur la base et sans grille de saisie. Les lenteurs de la base ne se voient pas trop, ça passe comme ça.

Sinon, l'idée était une grille, avec, en dessous un formulaire de saisie et un bouton pour rajouter la saisie dans la grille. Tout ça aurait été bien coté client pour éviter les aller-retours client/serveur.
Ensuite un autre bouton pour, là, balancer la grille au code-behind coté serveur qui devait faire un traitement des données pour les stockées en base.
Parce qu'à cause des lenteurs de la base, j'avais peur qu'un traitement en direct soit trop lourd. J'imaginais donc un traitement par bloc de plusieurs données.

Mais finalement sans la grille, ça marche pas trop mal. Le traitement et l'enregistrement en base est fait coté serveur à chaque saisie. Si la base et le réseau ne sont pas trop surchargés, c'est parfaitement exploitable.

Surtout que ça ne serait peut-être jamais exploité 


[i][b]---- Sevyc64  (alias Casy) ----
[hr]# LE PARTAGE EST NOTRE FORCE #/b/i

Mayzz · Answer

C'est si lent que ça ? Ça vient de quoi ? Ton hébergement ?

Quoi qu'il en soit tu aurais pu aussi utiliser Ajax avec une requête post et un fichier gestionnaire générique.

En gros coté client tu envois une requête vers un handler, qui ajoute la ligne à la base et te retourne le résultat dans la réponse HTTP. Après tu n'aurais qu'à ajouter les infos au tableau HTML de ta page. Le temps de la requête tu ajoute une GIF pour faire patienter.

Mais bon si tu as solutionné ton problème, que tout fonctionne parfaitement et que cela te convient alors c'est très bien comme ça =)

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_casy · Answer

Oui c'est lent, la connexion surtout et cela vient du driver ODBC (qui est une daube sans nom) necessaire pour accéder à la base.

Concernant ta solution, c'est en gros ce que je fais (sans la grille) pas en ajax, directement en asp.net.

L'idée de la grille était de ne pas enregistrer saisie par saisie mais d'enregistrer (et donc d'envoyer au code coté serveur) les saisies par bloc de 10, 15, 100,... La grille ne servait qu'à stocker temporairement les données saisies en attendant de les envoyer au serveur et de les enregistrer en base, d'où le "coté client".

A partir du moment ou j'enregistre en base, je n'ai pas besoin de conserver les données en grille, au contraire il faut que je la vide.

Donc, si j'enregistre la saisie directement en base, la grille devient totalement inutile.


[i][b]---- Sevyc64  (alias Casy) ----
[hr]# LE PARTAGE EST NOTRE FORCE #/b/i

Mayzz · Answer

Ok, je comprends mieux le besoin. La grille stock simplement les données de la future requête et n'est pas la pour afficher les données présentes en base.

Par contre Ajax n'est pas une mauvaise chose et peux te faire gagner quelques millisecondes car il évite le postback. De plus c'est plus beau visuellement.

En même temps du coup si tu envois tes données ligne par ligne, tu peux utiliser un UpdatePanel/UpdateProgress c'est simple à mettre en place t'en as pour 30 secondes.

Par contre ta première idée reste tout à fait valable sur un plan technique.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_casy · Answer

Les updatepanel, j'en ai mis sur quelques pages mais c'est un peu galère à gérer notamment les postback qui ne se font plus pareil, les réponses qui sont filtrées par de l'updatepanel, etc (je suis débutant de chez débutant en prog web).

J'ai par exemple eu le problème d'une action un peu longue qui retournait un pdf en pièce jointe. J'ai donc tenter de mettre un updatepanel avec un updateprogress, mais alors le pdf, semble-t-il bien retourné, n'était pas visible/accessible/existant coté client.
J'ai donc dû viré l'updatepanel/updateprogress, ne sachant pas où chercher le problème.


Ceci dit, il y aurait des améliorations à apporté à l'ensemble du site intranet, mais mon contrat se terminant à priori demain soir, ils se contenteront de ce qu'ils ont, qui est probablement moins que ce qu'ils espéraient, mais largement plus que ce qu'ils avaient demandé.

J'approfondirais probablement plus tard sur un autre poste ou à titre personnel.

Connaitrais-tu de bon tutos pour bien progresser en dev web en général, ainsi qu'en ASP.NET/AJAX ?


[i][b]---- Sevyc64  (alias Casy) ----
[hr]# LE PARTAGE EST NOTRE FORCE #/b/i

Mayzz · Answer

Pour l'UpdatePanel tu peux exclure des contrôles et les laisser en mode postback car comme tu as pu l'expérimenter le téléchargement de fichier n'est pas possible en Ajax. C'est assez simple à mettre en place de mémoire il faut ajouter Tiggers synchrones pour les contrôles souhaités à partir des propriétés de l'UpdatPanel. 

Pour les tutos ASP.Net voici un site qui m'a beaucoup aidé. C'est assez bien expliqué. 

Après je pense qu'il faut vraiment connaitre le web en apprenant les choses dans l&#8217;ordre. D&#8217;abord le réseau, les sockets et la communication entre deux PC. En suite les couches protocolaires comme le HTTP et enfin les couches logicielles comme le HTML et le JS. C'est essentiel. 

Car tout langage web même coté serveur est dans l'obligation de suivre la norme et de communiquer via HTTP/HTML. Que tu prennes le PHP ou l'ASP c'est le même principe, tous deux renvoient du code HTML au final, donc il vaut mieux connaitre les bases =)

ASP.Net est un peu plus complexe quand on le regarde de près car il utilise le Javascript et travaille aussi bien coté client que serveur. C'est pourquoi il est essentiel de connaitre les bases du web pour comprendre le fonctionnement interne d'ASP.Net. Pour ma part j'ai attaqué le web via ASP.Net car je fais du VB.Net et je ne connaissais aucun langage web et n'avais aucune base en HTML. Alors lors ce que j'ai appris qu'on pouvait développer un site web en VB j'ai sauté sur l'occasion. L'apprentissage à été dur et j'ai du tout réapprendre mais aujourd'hui je ne conçois pas un seul site sans Visual Studio. Il faut dire que les contrôles serveur sont tellement pratiques et puis il y a aussi la gestion des utilisateurs, rôles et profils qui nous mâchent le travail c'est vraiment bien fait. Le seul point négatif c'est les bus intempestifs de Visual Studio, il faut plus de temps pour s'adapter et comprendre les bugs qu'il n'en faut pour apprendre le .Net ^^


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_casy · Answer

Pour ma part j'ai attaqué le web via ASP.Net car je fais du VB.Net et je ne connaissais aucun langage web et n'avais aucune base en HTML.

C'est mon cas. Plus de 10ans d'expé en VB6.VB.Net, C# et divers autres langages, essentiellement en Winform, tant en info indus qu'en info de gestion.
+ quelques maigres rudiments en HTML.

Par contre, aucune connaissance en PHP, Javascript ou autres langages web. Donc devant un problème, je réagis, certes en .Net, mais j'ai plutôt tendance à réfléchir en Winform. Donc en dev web, j'ai des idées, mais je ne sais pas forcément si c'est réalisable, ni avec quoi (code-behind, javascript, css, ...).
Le css semble aussi très puissant et est très attirant.


Par contre, la façon de gérer l'ihm avec les contrôles serveur me donne envie aussi d'explorer du coté du WPF, même c'est certainement très différent. 

Bref tant des choses à apprendre encore pour le papy développeur que je deviens 
Reste plus qu'à retrouver un boulot dans mon trou de campagne perdu.


[i][b]---- Sevyc64  (alias Casy) ----
[hr]# LE PARTAGE EST NOTRE FORCE #/b/i

Grille de saisie coté client

8 réponses

Votre réponse

Discussions similaires