Créer du code html à partir d'objets

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008 - 27 mai 2007 à 14:43
cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008 - 8 juin 2007 à 17:30

Bonjour,

Je cherche en ASP.net le meilleur moyen pour produire du HTML à partir
d'objets. Je crois qu'aucune des solutions actuelle n'est vraiment
satisfaisante :

    - l'utilisation contrôles ASP.net ne permet pas d'avoir le
contrôle sur le HTML produit. L'utilisation des feuilles de styles et la
manipulation du DOM via JavaScript deviennent alors fastidieuses, la seule
solution étant de compiler et exécuter le projet puis de regarder le code source
généré. Bien sûr il y a les CSS friendly adapters, mais leur utilisation
revient à redéfinir les méthodes de rendu des contrôles ce qui n'est vraiment
pas productif. Je pense donc que les contrôles sont réservés à la production de
pages simples ou de formulaire. J'ai par exemple récemment crée cette page
(http://fra.orkos.com/Products/PriceList). Je vois difficilement comment
j'aurais pu la faire rien qu'avec des contrôle ASP.net...

     - La deuxième solution consiste à construire le code
html dans une variable de type string directement dans le code behind. Cela
permet de résoudre pas mal de problèmes de la solution précédente. On peut
produire exactement le code html que l'on veut et on a la possibilité de le
construire avec toutes les instructions de logique du langage de programmation
(conditions, boucle, appelle de fonction, récursivité,...). Je vois néanmoins
de très gros inconvénients dans l'application de cette méthode :

          - Il n'y a pas d'IntelliSense donc
le code est plus long à écrire et souvent sujet à erreurs. Une balise non
fermée ne sera par exemple détectée qu'à l'exécution.

          - A l'origine le principe du code
behind est là pour permettre une séparation entre la couche de logique et la
couche de présentation. En mettant tout dans le code behind, on casse cette
séparation et on perd la vue d'ensemble que l'on avait sur chacune de ces deux
couches.

    - Une troisième solution consiste à faire un mix des deux
solutions précédentes. Écrire le html dans la page ASPX et utiliser au maximum
les contrôles ASP.net. Quand ce n'est pas possible ou vraiment trop fastidieux,
écrire le code html dans le code behind puis l'insérer dans la page ASPX à
l'aide de la propriété InnerHtml. Je pense que c'est sûrement la solution la
plus mauvaise. Le code HTML se trouve alors à deux endroits différents et l'on
perd complètement la vue d'ensemble sur celui ci. L'étape de construction de la
feuille CSS ou de manipulation du DOM devient un enfer...

    - Enfin, la dernière solution que je vois et l'utilisation
de feuilles XSLT. Mais comme celle-ci n'est pas applicable sur les objets, il
faut auparavant les sérialiser au format XML. C'est ce que j'ai fais pour créer
ma page (http://fra.orkos.com/Products/PriceList). Je trouve très agréable de bénéficier
d'instructions logiques au format xml (templates, boucle foreach,
conditions,...). Cela permet de les mélanger avec du code XHTML. On bénéficie
ainsi de l'IntelliSense, d'une parfaite séparation entre la logique objet et la
présentation et d'un parfait contrôle sur le html tout en restant productif
grâce à une logique qui permet de factoriser le code. Il y a cependant deux inconvénients
majeurs :

          - l'étape XML est non seulement
inutile mais contre-productive. Il faut faire une sérialisation à chaque fois
que les objets changent.

          - cette méthode ne peut pas
convenir dès que le client souhaite mettre à jour des données.

Pour conclure je dirais que l'idéal serait une sorte de feuille XSLT mais qui
s'applique directement sur les objets. Va-t-il falloir attendre ASP.net 3.0… ?


Voilà, j'aimerais avoir votre avis sur la question. N'hésitez pas à me faire
part de vos remarques et conseils.

Merci d'avance.

Mathmax

A voir également:

Créer du code html à partir d'objets
Html array - Conseils pratiques -PHP
Emploi du temps a créer en ligne - Forum Java
'La référence d'objet n'est pas définie à une instance d'un objet.' - Forum C# / .NET
Mot caché à créer - Forum C# / .NET
Mots mélés à créer - Forum Java

47 réponses

Réponse 21 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
31 mai 2007 à 20:51

En fait, c'est un retour en arrière (mfff. est-ce qu'un retour en avant est possible ? ) car c'est la manière de faire en ASP 3.0, plus en .NET.

Microsoft a laissé cette option pour les développeurs qui n'arriveraient pas à faire le pas, pour façiliter le passge de ASP 3.0 à ASP.NET (conversion automatique du code plus façile).

De plus, avec cette manière de faire, tu ne peux pas profiter des focniotnnalités de controles aspx.

yopyop

Réponse 22 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
31 mai 2007 à 21:12

En fait, c'est un retour en arrière (mfff. est-ce qu'un retour en avant est possible ? ) car c'est la manière de faire en ASP 3.0, plus en .NET.

Comment aurais-tu fais cette page (http://de.orkos.com/Default.aspx?tabid=57) à la manière ASP.net ? Avec des contrôles ? Conviens que ça aurait pris du temps et que de plus les contrôles développés auraient étés difficilement réutilisables... non ?
Et surtout, je ne vois pas pourquoi ce serait plus un retour en arrière que l'idée du contrôle proposé par jesusonline.
Je pense que cette méthode se prète bien à la construction de certains type de pages. Le développement de contrôles peut aussi avoir d'énormes avantages dans d'autres cas. En fait je pense que ces 2 méthodes ne sont pas en concurrence mais on des utilités bien distinctes. Qu'en pensez-vous ?

De plus, avec cette manière de faire, tu ne peux pas profiter des focniotnnalités de controles aspx.

Pourquoi ? Qu'est ce qui empêche d'insérer un contrôle dans la page aspx ? C'est justement ce qui me parait fort : des 2 méthodes précédentes, il me semble que l'on n'est pas obligé de choisir l'une ou l'autre, on peut utiliser les 2 conjointement.
Mathmax

Réponse 23 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
31 mai 2007 à 22:21

RE,

Cela n'aurait pas pris plus de temps... ta page pourrait être faite avec des repeaters par example (donc, pas besoin de créer un nouveau composant).
Et comme je l'ai cité plus, lors de l'événement OnItemDataBound, tu peux y ajouter la logique que tu veux...

Je ne critique pas ta manière de faire... Chacun son "truc", et puis, comme je l'ai dis plus haut, l'essentiel c'est que le client soit content...
Ce qu'il désire, c'est une application qui fonctionne avec un look qui lui plait... ce qu'il y a derrière, il s'en fout royalement...

Et surtout, je ne vois pas pourquoi ce serait plus un retour en arrière que l'idée du contrôle proposé par jesusonline
C'est également ce que j'ai dit dans un post précédent ...

Pour ma part, j'utilise toujours les contrôles .NET, mais je n'en crée pas forcément un par page...

Il faut toujours prendre en compte l'investissement sur le contrôle... créer un custom contrôle que tu ne réutilisera jamais, c'est bien pour apprendre, mais à part cela, c'est inutle.

yopyop

Réponse 24 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
1 juin 2007 à 03:23

Il faut que je me renseigne d'avantage sur ces contrôles. Je ne connais pas bien les repeaters, mais il me semble que l'on ne peut pas tout faire avec. Peux t-on par exemple faire des appels récursifs ? Sinon utilises-tu d'autres contrôles de ce type ou arrives-tu a tout faire avec cela, les users et customs contrôles et les contrôles classiques d'asp.net (gridview, button,...) ?

Je ne comprends pas trop également ce que cela apporte de travailler avec de tels contrôles plutôt que de mettre directement des instructions dans la page aspx. Quels avantages y vois-tu ?

Mathmax

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question

Réponse 25 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
1 juin 2007 à 10:24

Re,

Pour moi, cela sépare mieux le layout et la logique qui va avec.
De plus, la grande majorité des développeurs (pour ainsi dire tous) font ainsi et c'est donc préférable de se mettre dans le bain.
Les contrôles ne parraissent pas très évidents à utiliser de prime abord, mais on trouve pleins d'examples sur le web et petit à petit on arrive à en faire ce que l'on veut.

Dans la majorités des cas, une combinaison de contrôles (par example un repeater contenant de datagrids, un repeater de repeater, ... les combinaisons sont infinies) serveurs suffisent à faire ce que tu veux.
J'utilise fréquemment tous les contrôles, et j'en ai crées quelques uns qui me sont bien utiles... Au finale, le temps inversti dans l'apprentissage de l'utilisation des contrôles et dans la création de custom controls est rentable.
La création d'un user/custom control n'est nécessaire que s'il te manque un tel contrôle... typiquement une dropdown liste telle que celle sur ce site....

Voici quelques url de sociétés qui créent des customs controls... sans vouloir faire de la pub, cela peut te donner une idée de ce que l'on arrive à faire une fois que l'on sait maîtriser les contrôles ou en créer des nouveaux:

http://www.infragistics.com/dotnet/netadvantage/aspnet.aspx#Overview

http://ajax.asp.net/toolkit/default.aspx

Que veux-tu dire par "appel récursif" ? ... appel de quoi ?

yopyop

Réponse 26 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
1 juin 2007 à 12:35

Par "appel récursif", je veux dire une fonction qui se rappelle elle même. Quand tu a un objet qui contient une propriété qui est une liste d'objet de même type que lui et dont chacun des bojets peuvent à nouveau contenir une liste d'objet toujours du même type etc... comment ferais-tu pour afficher une hierrarchie de tous ces objets (un peu comme je l'ai fais avec ma liste d'objets) ? Y a t'il un contrôle qui permette cela ? Les repaters peuvent-ils se répéter eux même de la sorte ?

Mathmax

Réponse 27 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
1 juin 2007 à 13:36

euh... merci mais je sais ce qu'est la récursivité... c'était juste le contexte de la phrase...

Donc pour la récursivité, il existe un control tree view.

Mais tu peux également utiliser un repeater (ou une datagrid, une datalist, ...) qui, lors du binding, s'ajoute des sous repeaters ( et ainsi de suite).

Par example pour un repeater, au moment du binding de ton objet, tu va checker s'il contient des sous objets... si c'est le cas, tu ajoutes dynamiquement un nouveau repeater en lui passant le sous objet en paramètre et ainsi de suite...

Bref, il il y a pas mal de façons de faire cela (dont le treeview)...

Donc oui, c'est possible (même si je suis contre la récursivité )

yopyop

Réponse 28 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
1 juin 2007 à 15:52

Je me suis un peu documenté sur les repeaters et je suis notament tombé sur cette page :

http://msdn2.microsoft.com/fr-fr/library/aa478959.aspx

Il montre un exemple d'affichage d'une hierrarchie à un, puis deux, puis trois niveaux et en conclusion il est écrit ceci :
Limitations and Efficiency
It is important to keep in mind that the data binding mechanism in ASP.NET
was designed for binding to flat data sources, and although it can be used to
bind hierarchically, it may not always be the best choice for rendering data
that is truly hierarchical in nature. The data source must be regular in
shape—it is not feasible to bind to a data source that is 2 levels deep in some
places and 4 or 5 levels deep in others. XSL is much better suited to perform
rendering of data with arbitrary hierarchical shape, so converting your data to
XML and using XSL transforms with the ASP Xml control is probably your best
option.

Donc à prioris ce n'est pas l'idéal pour construire ma liste de prix.... et finalement je suis moi aussi passé par une transformation xsl.
Bien sûr, on peut ajouter dynamiquement un repeater dans un repeater, mais en faisant cela, on met de l'affichage dans la partie code-behind. Finalement, il me semble qu'à trop vouloir éviter de mettre de la logique dans la page aspx, on finit par être contraint de contruire des éléments de type aspx dans la page code behind...

Mathmax

Réponse 29 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
1 juin 2007 à 17:50

Oui,

Ou alors comme expliqué, et comme je l'ai cité X fois précédemment, tu peux utiliser le contrôle XML...
ou alors, dans le cas d'une hiérarchie, le contrôle treeview...
ou alors, utliser une technique que te retourne tout dans un tableaux avec un valeur indiquant la profondeur de l'élément

http://blogs.conchango.com/christianwade/archive/2004/11/09/234.aspx

de plus, tes pages ne sont pas si complexes que cela (sans vouloir de vexer).

Finalement, il me semble qu'à trop vouloir éviter de mettre de la
logique dans la page aspx, on finit par être contraint de contruire des
éléments de type aspx dans la page code behind...
Oui, mais cela reste de la logique d'affichage

yopyop

Réponse 30 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
1 juin 2007 à 18:08

Ou alors comme expliqué, et comme je l'ai cité X fois précédemment, tu peux utiliser le contrôle XML...

Cela n'a pas beaucoup d'interêt car alors tu utilises du xslt qui mélange autant l'affichage et la logique que d'écrire avec des instructions c# ou vb dans des <% %> mais qui demande en plus une sérialisation et empêche en plus toute édition des données côté client (on revient à l'idée de contrôle de jususonline).

Sinon, j'ai essayé d'écrire cela :

    <form id="form1" runat="server">


        <%
            private void DisplayHierrarchy(Item item)
            {
                foreach(Item subitem in item.SubItems)
                {
                    DisplayHierrarchy(subitem);
                }
                %>
                    ' />
                <%
            }
        %>

        <% DisplayHierrarchy(MyItem); %>


    </form>

mais ça ne marche pas. N'est-il pas possible d'utiliser des fonctions comme cela ?

Mathmax

Réponse 31 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
2 juin 2007 à 01:55

Salut,

Je pense que tu devrais consulter les sites expliquant rendering de ASP.net afin d'en comprendre son fonctionnement.
(sur google: asp.net quickstart, asp.net databinding, asp.net rendering).

Cela te permettra de mieux comprendre les méchanismes d' ASP.NET, et surtout des contrôles car apparemment il te manque certaines connaissances de bases concernant ceux-ci (je te dis cela sans aucune méchanceté).

pour info, xslt "mélange" bien l'affichage et la logique, mais uniquement la logique "d'affichage".
Le xslt ne devrait rien faire de plus.

yopyop

Réponse 32 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
2 juin 2007 à 11:31

pour info, xslt "mélange" bien l'affichage et la logique, mais uniquement la logique "d'affichage".

C'est ce que je me tue à vous dire depuis le départ... Pour moi ce n'est pas grave de mélanger la logique d'affichage et l'affichage lui même. Pour vous ça semble l'être. Alors j'essaie de comprendre comment vous pouvez arriver à toujours vous satisfaire des contrôles et quels avantages vous y voyez, mais j'apprends que dans certains cas le xslt est la solution couramment utilisée. Ce que je dis depuis le début, c'est qu'il est avantageux de développer des contrôles quand on les réutilises ( j'ai d'ailleurs fais les menus de mon site avec des custom-controls), mais sinon ça prends du temps et je cherchais donc un moyen plus rentable pour les autre cas.
C'est pour ça que la technique de mélanger des instructions for, if,... avec du code aspx me conviens très bien pour certains cas. Cala fait exactement la même chose que le code xslt (mais avec des instructions c# ou vb au lieu d'instruction xslt) pour peu que l'on se restreigne à ne mettre que de la logique d'affichage dans le code aspx. Je n'arrive pas à comprendre pourquoi vous êtes foncièrement contre cette technique, mais pas contre l'utilisation du xslt. Est-ce par principe ? Au risque de me répéter, je dirais qu'au niveau mélange "logique affichage" et affichage c'est équivalent, mais avec le xslt il reste deux inconvénients majeurs :
    - la sérialisation xslt toujours nécessaire ;
    - impossibilité d'utiliser des contrôles aspx;
Si je me trompe à ce niveau, n'hésitez pas à me le dire car je ne vois vraiment ce qui tend à vous faire préférer xslt à la "technique des <% %>".

Maintenant il y a un truc que je n'arrive pas à faire, c'est écrire :

    <form id="form1" runat="server">


        <%
            private void DisplayHierrarchy(Item item)
            {
                foreach(Item subitem in item.SubItems)
                {
                    DisplayHierrarchy(subitem);
                }
                %>
                    ' />
                <%
            }
        %>

        <% DisplayHierrarchy(MyItem); %>


    </form>

Si l'on ne peut pas écrire de telles fonctions mélangées à de l'affichage alors oui le xslt est plus puissant sur un point : il a les templates qui sont en gros équivalents.

Mathmax

Réponse 33 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
3 juin 2007 à 15:56

Disons que c'est uniquement par principe

Plus sérieusement, l'un des avantages de ne pas tout mettre dans la page aspx et c'est que pour plusieurs pages, tu peux utiliser le même code behind.

Admettons que tu dois faire une présentation à un client.
Tu dois lui proposer 3 layouts (disposition des contrôles, css) différents.
Dans ce cas, tu peux faire 3 pages aspx différentes, mais qui partagent le mêmes code behind.

Ok, il faut que les 3 pages utilisent exactement les mêmes contrôles, avec les mêmes noms, ... mais tu peux les disposer complètement différemment et utiliser des css différentes.

Donc pas besoin de rettaper tout le code pour chacune des pages (chargement des données, logiques d'affichages, gestion des événements).
Tandis que dans ton cas (si tu mets tout dans l'aspx) , tu devrais retaper tout le code. Non ?

Je ne suis pas opposé à ta manière de faire (d'autant plus que les pages que tu crées sont relativement "simples"), mais je préfère passer par le code behind, simplement pour l'exemple cité ci-dessus, car il démontre qu'utiliser le code behind a ses avantages...

Je ne sais pas, mais pour cela me semble intuitif...
De plus, en utilisant le code behind, Visual Studio t'épargnes pas mal de code... (tu places un bouton, double click dessous et hop, le code behind avec l'événement correspondant t'attendent...).
Pour moi, c'est plus logique, et en plus tu te retrouve avec une zolie dll, tandis que si tu mets tout dans le code inline, tu dois mettre lecode sur le serveur et non la dll (tu mets les pages qui contiennent le code).

Voici quelques discussions sur le sujet:
http://www.eggheadcafe.com/articles/20030518.asp
http://www.codeproject.com/aspnet/InlineCodeVSCodeBehind.asp

En ce qui concerne ton code ci-dessus, je ne pense pas que tu devrais faire cela comme ca...
Tu dois créer un repeater et mettre ta checkbox dans l'itemTemplate.... ou utiliser une datalist.

Voici un example, avec du code inline
http://www.w3schools.com/aspnet/aspnet_datalist.asp

Je tiens juste à te signaler que, expérience faite, si un jour tu dois créer une page avec énormément de code, si tu compares la version code inline et la version code behind, la 2ème sera beaucoup plus façile à créer et beaucoup plus clair à comprendre...

De plus, il me semble qu'une page sans code behind herite de System.Web.Page, tandis qu'une page avec code behind peut hériter d'autre chose.
Ce qui veux dire que tu peux par example (en passant par le code behind) créer une classe qui hérite de System.Web.Page et que tes pages aspx hériteront de cette page.
Dans cette classe tu peux y mettre toute la gestino de la sécurité par example (ou autre)...

Bref, plus les pages (applications) que tu fais seront complexes, plus le code behind deviendra une évidence...

yopyop

Réponse 34 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
3 juin 2007 à 16:51

Plus sérieusement, l'un des avantages de ne pas tout mettre dans la
page aspx et c'est que pour plusieurs pages, tu peux utiliser le même
code behind.

Je ne doute pas des avantages du code behind. Mon but n'est pas de mettre toute la logique dans la page aspx. En fait ma question était : pourquoi préférer le XSLT au malange code aspx + instructions d'affichages (instruction identiques à celle du xslt : seulement des if, des boucles,... c.a.d ni plus ni moins que ce que fais le xslt mais avec un syntaxe différente. J'insiste sur ce point car c'est là, je pense, que je ne suis pas compris (ou que je ne comprends pas )) ?

En ce qui concerne ton code ci-dessus, je ne pense pas que tu devrais faire cela comme ca...
Tu dois créer un repeater et mettre ta checkbox dans l'itemTemplate.... ou utiliser une datalist.

Comme je te le disais plus, sur msdn il disent : tant que l'on à une hierrarchie à plat, les repeaters conviennent très bien, mais dès lors que le hierrarchie n'est plus de forme régulière (par ex à 2 niveaux à certains endroits, et à 4 ou 5 niveaux ailleurs), ça n'est plus une bonne solution. Il est donc conseillé de faire du xslt qui permet de parcourir la hierrarchie recursivement.
Maintenant, de mon point de vue (et ça rejoint ma première question), faire un mélange aspx + instruction d'affichage équivaut à faire du xslt, mais directement sur les objets (sans faire de sérialisation et en ayant en plus la possiblité d'insérer des controles comme une checkbox). D'où le code que j'ai essayé de faire ci-dessus et dont je me demande toujours pourquoi la syntaxe n'est pas bonne.
Mathmax

Réponse 35 / 47

jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
3 juin 2007 à 19:33

YopYop, je me permet de te corriger sur certains points. Une page sans code behind hérite du type définit de l'attribut pagebasetype définit dans la section Page. A partir de ASP.net 2.0 il est possible de compiler la partie .aspx d'une page pour n'avoir qu'une seule dll, lors du publish il suffit de décocher la case "allow this site to be updatable" la partie aspx sera alors vide.

mathmax normal que ton code ne fonctionne pas, il faut bien avoir en tête que lorsque tu execute une page celle ci est d'abord parsé par ASP.net puis compilé. Comment voudrais tu qu'ASP.net se débrouille avec ton code ?

Ce que j'aime pas dans l'approche ASP3 c'est qu'au final on a une soupe de code imbuvable et on se retrouve vite perdu dans tous cet amas inutile de code. Et surtout on a vite envie de faire des fonctions qui génére du code HTML (on en a la preuve) alors qu'ASP.net permet justement d'avoir des controles qui générent du HTML mais surtout qui gèrent leur état, leurs events, leur cycle de vie, etc... Dans ton cas tes pages sont "simple" il n'y a que de l'affichage, pas de postback ni quoi que ce soit, tu peux donc être tenté de créer des fonctions qui générent du code HTML, mais lorsque tu as des pages avec un peu de logique cette approche n'est pas jouable.

Personnellement j'ai énormement investis dans la création de custom control, et dès que j'en ai besoin j'hésite pas une seconde car ca simplifie énormement la relecture du code ...
Je pense que tu devrais faire de même, au moins pour les template, ca te permettrais surement de faire un controle qui t'affiche des datasource "recursive"
meme si le repeater peut très bien le faire quand on sait bien le manier :-)

<hr />Cyril - MSP - MCTS ASP.net & SQL

Réponse 36 / 47

cs_Yopyop Messages postés 586 Date d'inscription lundi 7 janvier 2002 Statut Membre Dernière intervention 10 février 2010 1
3 juin 2007 à 20:01

Merci pour la précision (je suis toujours en 1.1).

Quand à l'utilisation du repeater pour une structure hiérachique, c'est possible (de même que la datalist, la datagrid, ...), même si à priori, il vaut mieux utiliser le contrôle treeview.

Pour ce qui est de ta question code behind/xslt:
Les 2 approches sont possbiles, voici un article qui donne un excellent example (et qui explique pourquoi ton code ne fonctionne pas)..
http://www.dnzone.com/showDetail.asp?TypeId=2&NewsId=151

Mais de nouveau, cela fonctionne pour les pages "simples"...

Donc si tes pages ne font que de l'affichage ou que les évenements associés sont simples, ok pour le xsl (par example un rss reader). Mais dès que tu veux y ajouter de la logique "complexe" cela devient vite galère.

yopyop

Réponse 37 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
4 juin 2007 à 18:46

mathmax normal que ton code ne fonctionne pas, il faut bien avoir
en tête que lorsque tu execute une page celle ci est d'abord parsé par
ASP.net puis compilé.

Ok, donc si je ne peux pas faire ça, je comprends que je doive m'orienter vers les contrôles.

Je pense que tu devrais faire de même, au moins pour les template, ca
te permettrais surement de faire un controle qui t'affiche des
datasource "recursive"

J'ai trouvé ce contrôle (http://www.codeproject.com/aspnet/nestedrepeater.asp). Il répond exactement à mon problème à ceci prêt qu'il prend un dataset en datasource alors que je souhaite travailler sur des objets.
Je me demande d'ailleurs pourquoi on trouve toujours des contrôles qui prennent en datasource des datasets et presque jamais des objets. Pour moi les contrôles se bind toujours sur des objets. C'est eux qui se chargent à partir d'une source xml, base de donnée, dataset... J'ai l'impression que bien souvent on saute l'étape "objet" pour directement afficher les données, la logique métier s'appliquant alors directement sur les dataset. Cela ne me parait pas pratique et non-évolutif. Qu'en pensez-vous ?

Bref, j'ai donc adapté ce contrôle pour qu'il prenne en datasource un objet. Je n'ai alors plus qu'à binder mon contrôle dans ma méthode Page_Load comme ceci :

        rptCateg.DataSource = monObjetParent;
        rptCateg.ChildsPropertyName = "SousObjets";
        rptCateg.DataBind();

J'ai ajouté la propriété ChildsPropertyName qui est le nom de la propriété qui contient la liste des élément fils (de même type que l'objet parent), puis j'utilise la réflexion pour découvrir ces sous objets et faire faire ma récurrence dessus. Ca marche nickel.
Et c'est vrai que c'est assez propre à écrire dans ma page aspx. Ici j'affiche mes catégories de produits et les produits qu'elle contiennent :



                "><%# DataBinder.GetPropertyValue(Container.DataItem,"Name") %>

                '>
                   <HeaderTemplate>
                                       </HeaderTemplate>

                     ----

                        <%# DataBinder.GetPropertyValue(Container.DataItem,"Name") %>,
                        <%# DataBinder.GetPropertyValue(Container.DataItem,"Price") %>,


                   <FooterTemplate>


                   </FooterTemplate>




Si les sources de mon contrôle vous interesse, je les posterai.

Merci pour vos conseils.
Mathmax

Réponse 38 / 47

jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
4 juin 2007 à 22:02

Beaucoup de monde bind directement avec un dataset car ils sont faineant ... mais normalement une bonne approche utilise un datareader qui va charger une collection d'objet métier ... mais le dataset est tellement rapide a prendre en main ...

Par contre je ne comprend pas l'interet du repeater à l'interieur .. il ne fait que générer un tableau ? donc gridview ce sera encore plus joli

avec mon pifomètre ca donne :

"><%# Container.DataItem.Name%>

http://blogs.codes-sources.com/cyril/archive/2007/05/06/l-interface-itemplate-lors-de-la-compilation-d-une-page-en-asp-net.aspx)

Bienvenue dans le monde fabuleux d'ASP.net

<hr />Cyril - MSP - MCTS ASP.net & SQL

Réponse 39 / 47

cs_mathmax Messages postés 403 Date d'inscription vendredi 28 octobre 2005 Statut Membre Dernière intervention 31 août 2008
5 juin 2007 à 04:19

Merci pour ta réponse.

Par contre je ne comprend pas l'interetdu repeater à l'interieur .. il ne fait que générer un tableau ? donc gridview ce seraencore plus joli

Le problème c'est que la GridView me génère tout un tas de html inutile :

        ----

              |  |Price |Name |
        ----

            item 2_1, price 2_1, price 2_1, item 2_1,



C'est pour ça que je préfère écrire moi même le code. La solution que tu va me proposer, je le sens venir , est de créer mon propre custom contrôle ou de redéfinir la méthode render de GridView dans une classe héritée. Mais si je dois ajouter une classe ou un événement javscript à ma table ou à un élément de mon tableau... ça ne sera pas évident à faire avec un contrôle personnalisé, non ?

si tu fais du C# soit tu cast Container.DataItem dans le type souhaité mais puisque tu fais ton propre custom control tu peux utiliser l'attribut TemplateContainer sur ta propriété ItemTemplate

J'ai fais comme tu m'a dit, mais en faisant un cast. J'aurais aimé pouvoir"typer" l'objet DataItem de ma classe NestedRepeaterItem (type de ItemTemplate), mais je veux que mon contrôle puisse être utilisable pour tout type d'objet alors j'ai laissé le type objet. L'idéal, et je sais pas si c'est possible, serait que mon contrôle soit générique. Je pourrais ainsi passer le type de mon objet en paramètre et typer ainsi ma propriété DataItem. Mais comment faire pour initialiser un contrôle générique ? On ne pourra pas le faire en insérant un tag dans la page aspx, il faudra forcément l'instancier dynamiquement, non ?

Mathmax

Réponse 40 / 47

jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
5 juin 2007 à 08:57

>> http://www.asp.net/cssadapters/

on ne peut pas malheureusement pas avoir des controles generic

<hr />Cyril - MSP - MCTS ASP.net & SQL

Discussions similaires

la référence d'objet n'est pas définie à une instance d'un objet

la reference d'objet n'est pas définie a une instance d'un objet

Erreur "La référence d'objet n'est pas définie à une instance d'un objet."

exemple de page d'accueil avec la balise div et css

La référence d'objet n'est pas définie à une instance d'un objet.

Votre réponse

Discussions similaires