Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pb passge parametres Datalist

23 réponses
Avatar
Rogério Altman
Bonjour à tous,

J'essaie de récupérer par un evenement les donneés d'une balise "Label"n
venant d'un datalist, en cliquant sur un imagebutton.
En faisant un findcontrol je n'y arrive pas ...:

mapage.aspx
--------------

<asp:DataList id="DataList1" runat="server" RepeatColumns="3"
RepeatDirection="Horizontal" OnPreRender="Page_Load">
<itemtemplate>
<asp:Image ID="Image1" runat="server" ImageUrl='<%#
DataBinder.Eval(Container.DataItem, "chemin_image") %>' /><br />
<asp:Label ID="Label1" runat="server" Text='<%#
DataBinder.Eval(Container.DataItem, "nom_image") %>' ></asp:Label><br />
<asp:ImageButton ID="ImageButton1" runat="server"
ImageUrl="~/images/icone-ajouter.gif" OnClick="ImageButton1_Click" />
</itemtemplate>


mapage.aspx.cs
----------------
protected void ImageButton1_Click(object sender, ImageClickEventArgs e)
{
string nom_image=
((Label)(Page.FindControl("DataList1").FindControl("Label1") )). Text ; //
JE SOUHAITE RECUPERER L'ITEM CLIQUé

SqlConnection myConnection = new
SqlConnection("server=localhost;database=zoom;Trusted_Connection=Yes");
myConnection.Open();

string chemin_image = "~/zoomimages/" + numero_zoom + @"/" +
Session["valeur"] + @"/BR/" + nom_image ;
SqlCommand myCommand = new SqlCommand("INSERT INTO panier_client
(nom_image)" +
" VALUES ('" + nom_image + "')", myConnection);
myCommand.ExecuteNonQuery();
}

Merci de vos conseils,
A+

3 réponses

1 2 3
Avatar
Dolten Altgor
> Tout dépend de comment tu veux structurer tes pages...
C'est vrai que l'avantage du SqlDataSource, c'est le gain de temps énorme
à realiser les pages et de tout faire à la souris...
Cela évite beaucoup de code et de bug !

L'inconvénient d'un tel procédé c'est que (par exemple) tu ancres toutes
les requêtes SQL directement les pages ASP...
Tu n'as donc plus une architecture classique couches (Métier, Accès aux
données et IHM) ! Il suffit qu'un jour tu changes de SGBD (ou un renomage
de table par exemple) pour te rendre compte que c'est un vrai bazarre à
modifier (sur 5 pages ça va encore... Mais sur 50 c'est horrible)

Personellement, pour les développements ASP .NET, je (nous) utilise
uniquement l'ObjectDataSource car :
- il est possible avec celui-ci d'avoir un rendu visuel en Mode Design des
tes colonnes,...etc
- d'appeler des méthodes qui se chargeront de récupérer les données...
- de réduire un peu le codage en passant les paramètres des pages GET,
POST,...etc directement dans les méthodes sans avoir à les traiter dans le
Page_Load()
- On a des pages qui sont ancrés directement via la couche métier et non
via à un SGBD (ou à une source de données) quelconque !

Si tu veux utiliser l'objet ObjectDataSource je pourrais te donner
quelques conseils concernant l'organisation de ton code...



Intéressant!
Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par
des dataset pour accéder à mes données et leur traitement?
Mais si le traitement dans page_load n'est plus nécessaire je peux donc
passer des parametres à mes requetes directement via ObjectDataSource comme
je le fais avec SqlDataSource?

Je vais me lancer sur cette voie, donc evidemment tes conseils sont les
bienvenus!

merci encore
Avatar
Gilles TOURREAU
Le Tue, 31 Jul 2007 17:55:45 +0200, Dolten Altgor a écrit:


Intéressant!
Cela me paraît bien pertinent. Avec ObjectDataSource je passerai donc par
des dataset pour accéder à mes données et leur traitement?
Mais si le traitement dans page_load n'est plus nécessaire je peux donc
passer des parametres à mes requetes directement via ObjectDataSource
comme
je le fais avec SqlDataSource?



Oui, car avec ObjectDataSource les paramètres de la page que tu passes
(GET, POST...etc) sont envoyés à des méthodes d'une classe :

Dans ton ObjectDataSource tu associe :
- la classe : MaClasse
- La méthode Select : MaMéthode
- Le paramètre param1 récupère la valeur du paramètre GET appelé
"identifiant"
- Le paramètre param2 récupère la valeur du paramètre POST appelé "toto"
...etc

Voici le code de la méthode que tu devras mettre dans la classe MaMéthode

public void MaMéthode(int param1, string param2,...etc)
{
...
}


Je vais me lancer sur cette voie, donc evidemment tes conseils sont les
bienvenus!

merci encore





Un exemple d'une bonne organisation que je te recommande (au niveau couche
métier/IHM)

On suppose que tu as dans ta couche métier 3 objets comme ceci :

- Chien (Classe classique)
- Voiture (DataSet)
- BusinessManager (Classe classique)

La classe Chien comporte que des propriété Get/Set (Nombre de papattes,
race,...etc)
Le DataSet Voiture contient une table Voiture, Marque avec des champs
adéquats...etc

Et ta classe BusinessManager contient 2 méthodes par exemple :

public Chien[] GetToutoux(string race);
public Voiture GetVoitures_A_LaCasse(int numéroSérie);

Du coté de ton projet ASP .NET on suppose une page appelé Altgor.aspx, je
te conseille de créer une classe (soit incluse dans le code Behind, soit à
part mais dans le même projet) appelé AltgorDataManager (par exemple).

Dans cette classe tu créer 2 méthodes (statiques ou non) :

public Chien[] GetToutoux(string race)
{
BusinessManager b;
Chien[] toutoux;

b = new BusinessManager();
toutoux = b.GetToutoux(race);

//Inverser l'ordre des toutoux
Array.Inverse(toutoux);

return toutoux;
}

public Voiture GetVoitures_A_LaCasse(string numéroSérie)
{
//Formater le n° de série
int temp;
temp = Formater(numéroSérie);
if (temp == null) //Mauvais format
return null;

BusinessManager b;
b = new BusinessManager();
return b.GetVoitures_A_LaCasse(numéroSérie);
}

Tu n'a plus qu'assocer les DataObjectSource à ces méthodes...

Cela peut te sembler lourd en voyant un tel code qui "repetent" les appels
à la couche métier, mais cela permet au développeur de la partie IHM de
contrôler les saisies utilisateurs, d'ordonner différements les données
(cf. Array.Inverse(toutoux)) avant d'afficher les données... C'est ici
qu'il faut aussi contrôler les risques de faille dû à la saisie de
l'utilisateur...

Du coté graphique, l'infographiste n'a aucune idée de comment sont
récupérés les toutoux, il sait juste qu'il appelle une méthode qui
récupère des toutoux et qu'il devra les afficher dans des colonnes avec
tel couleur... etc.

Tu remarquera que la création de la classe AltgorDataManager sépare le
codage de l'accès aux données, et le codage qui manipule les objets (par
ex : "MonControl.Color = ...")

Tu remarquera aussi qu'au niveau de la classe AltgorDataManager il n'y
aucun accès physique à une source de données, on ne sait pas d'où viennent
les données ! WebService ? SGBD ? Fichier XML ? C'est le développeur de la
couche métier/accès aux données qui s'arrachera les cheveux pour çà !

Tu peux créer une classe de base regroupant des méthodes communes pour
chaque DataManager de chaque page...

Regardes bien la doc du ObjectDataSource, car Microsoft explique très
clairement comment ASP .NET instancie la classe associée (ici
AltgorDataManager)? Tu peux personnaliser l'instanciation de la classe
AltgorDataManager.

ATTENTION : En utilisant un ObjectDataSource associé à la
AltgorDataManager, à chaque appel d'une méthode Select, Insert,...etc, il
réinstancie ta classe ! Ce qui signifie que si l'allocation des ressources
de ton BusinessManager coûte cher cela peut poser des problèmes... Il faut
isoler garder quelque part ton BusinessManager instancié afin qu'il puisse
être utilisé durant toute la requête HTTP.

Tu peux te passer de cette classe intermédiaire et appeler ton
BusinessManager directement, cependant tu n'auras pas le contrôle des
paramètres récupérer sur la page ASP, ni des données exploitée...

Si tu as encore des questions...

Cordialement

--
Gilles TOURREAU


S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Avatar
Gilles TOURREAU
Le Tue, 31 Jul 2007 18:44:42 +0200, Gilles TOURREAU
a écrit:

Est-ce que tu peux me passer ton adresse e-mail à catte adresse :



Cordialement

--
Gilles TOURREAU


S.A.R.L. P.O.S
Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
1 2 3