Créer du code html à partir d'objets

Signaler
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008
-
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008
-
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… ?
<!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75"
o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
<v:stroke joinstyle="miter"/>
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0"/>
<v:f eqn="sum @0 1 0"/>
<v:f eqn="sum 0 0 @1"/>
<v:f eqn="prod @2 1 2"/>
<v:f eqn="prod @3 21600 pixelWidth"/>
<v:f eqn="prod @3 21600 pixelHeight"/>
<v:f eqn="sum @0 0 1"/>
<v:f eqn="prod @6 1 2"/>
<v:f eqn="prod @7 21600 pixelWidth"/>
<v:f eqn="sum @8 21600 0"/>
<v:f eqn="prod @7 21600 pixelHeight"/>
<v:f eqn="sum @10 21600 0"/>
</v:formulas>
<v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
<o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" alt="" style='width:11.25pt;
height:11.25pt'>
<v:imagedata src="file:///C:\DOCUME~1\MAA~1.ORK\LOCALS~1\Temp\msohtml1\01\clip_image001.gif"
o:href="http://www.aspfr.com/imgs2/smile_shy.gif"/>
</v:shape><![endif]--><!--[if !vml]--><!--[endif]-->


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

47 réponses

Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Modérateur
Dernière intervention
13 octobre 2010
28
Bonjour,

Alors là je ne comprend pas, le fonctionnement d'ASP.net repose sur des objets qui génére du code HTML : les contrôles ...

Pourquoi ne pas faire un controle qui prend en datasource un produit ou une liste de produit ? et ensuite utiliser les templates pour les parties génériques ?

Par exemple sur CodeS-SourceS j'ai fait un contrôle CodeList qui prend une List<Code> (en fait un PaginateList<Code>) et ensuite dans la partie .aspx j'ai par exemple :

<cs:CodeList ID="CodeList1" runat="server">
   
        <%#Container.DataItem.Title %>

   
</cs:CodeList>

le contrôle gère la pagination, et tout ce qui va avec, tout ce que j'ai à faire c'est le code html pour un élément.

Je comprend néanmoins ce que tu veux dire par "feuille XSLT sur les objets" mais si tu créer ton propre controle ce sera beaucoup plus riche. Comment ferais tu pour gérer des événements avec ton xslt ? tu ne peux pas inclure de button, ni quoi que ce soit.

Sinon, tu peux très facilement faire un contrôle de transformation d'objet métier en HTML avec du XSLT.

<toto:DAOToXML id="toto" runat="server">
      <xsltTemplate>
           ici ton template XSLT
      </xsltTemplate
</toto>

et ensuite dans le code behind tu lui donne en datasource ton objet, ton controle va se charger de serializer ton objet en XML et ensuite faire la transformation XSLT. Par contre niveau perf c'est pas génial faudrais prévoir un système de mis en cache du XML sérializer.

On peut aller plus loin en faisant son propre buildProvider qui va se charger de transformer ton flux XSLT en vrai code .net via CodeDOM (ce que fait déjà le PageBuildProvider pour créer le type Page final mais avec du HTML) et ainsi pouvoir gérer des controles dans notre flux XSLT. (j'avoue, ca nécessite un peu de boulot, faire un analyseur XSLT ne doit pas être super simple :))

en ce qui concerne ASP.net 3 il est sortis il y a 6 mois avec le "truc" qu'ils ont appellé .net 3, mais y'a aucun changement pour ASP.net, ASP.net 3.5 est prévu pour fin de l'année et intégrera nativement ASP.net Ajax ainsi que de nouveaux contrôles mais aucune modification des base de ASP.net 2.0

<hr />Cyril - MSP - MCTS ASP.net & SQL
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008

Pourquoi ne pas faire un controle qui prend en datasource un produit ou
une liste de produit ? et ensuite utiliser les templates pour les
parties génériques ?

Je suis conscient que c'est possible d'utiliser des contrôles. Mais créer un contrôle personnalisé en écrivant en dur la méthode de rendu HTML n'est pas productif alors qu'avec XSLT l'écriture de la page se fait très aisément (c'est aussi simple que d'écrire une page html, mais plus rapide encore). Il faut savoir que si je crée des contrôles, je vais très rarement les réutiliser car je les veux très spécifiques au niveau du HTML rendu. Donc je ne veux pas perdre de temps à développer un contrôle juste pour la page sur laquelle je travaille.

Comment ferais tu pour gérer des événements avec ton xslt ? tu ne peux pas inclure de button, ni quoi que ce soit.

Pour les boutons, j'écris directement le tag html, ça ne me pose aucun problème. .Pour les événements, je me sert actuellement des événements javascript qui soit appelle une fonction côté client (comme mon filtre) soit une fonction côté serveur. Je suis d'accord que ce n'est pas idéal. La solution XSLT à des inconvénients majeurs, mais on pourrais très bien imaginer une sorte de feuille XSLT sur les objets qui gèrent les événements. Je reste persuadé que ça serait l'idéal. En attendant, je cherche la meilleure solution possible.

utiliser les templates pour les parties génériques ?

Je ne connais pas les templates. Permettent t-il de faire de la récursivité ou sont-il juste fait pour parcourir une liste d'objets ? Je peux les appeler plusieurs fois, à différent endroits de ma  page ASPX ?
Mathmax
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
Salut,

Tout d'abord, il est vrai que la création d'un contrôle peut prendre du temps, mais il faut voir cela comme un investissement, car le but est de pouvoir réutiliser/partager ce contrôle.

Ce n'est apparemment pas ton cas, donc tu considères le temps passé sur ton contrôle comme une perte de temps (plus ou moins).
Mais, imagine qu'un autre client voit ta page et qu'il désire exactement la même (les données changent bien sûr, ainsi que la CSS, mais les fonctionnalités restent).

De plus, créer un contrôle n'implique pas forcément écrire en dur le rendu html (en tous cas pas plus qu'en passant par xml et xsl), il suffit de bien séparer le traitement des données, des événements et de l'affichage.

Pour info, il existe un controle (System.Web.UI.WebControls.Xml) qui permet de faire ce que tu fais (il faut simplement lui associer un fichier xsl via la propriété TransformSource="news.xsl" et lui associer un document xml via XMLDocument
).

Et oui, il faut toujours passer par une conversion XML ...

En ce qui concerne la meilleure solution possible, c'est celle qui convient au client

Plus sérieusement, il faut peser le pour et le contre de chacune des méthodes que tu as décrites en introduction (il y en a d'autres) et choisir la plus adaptée (et il y a une question de préférence personnelle également, apparemment tu aimes bien le xml/xslt).Typiquement, pour un simple "Hello Word", la méthode employée ne sera pas la même que si tu fais une page qui affiche le résutat d'un rapport, avec drill-down, filtres etc.. etc...

yopyop
PS:
ta page me plaît bien
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008

En fait, ce qu'il faudrait c'est avoir la possiblité d'ajouter des instructions logiques dans le cade de la page ASPX.

Je sais que l'on peut mettre du code c# à l'interieur d'une balise html dans la page aspx en écrivant :
<% Response.Write(maString); %>
Je voudrais maintenant faire l'inverse : écrire du code html  à  l'intérieur d'une insctruction ou fonction c# dans la page aspx. N'est-ce vraiment pas possible ?

Mathmax
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Modérateur
Dernière intervention
13 octobre 2010
28
l'inverse ?

Je pense que tu gagnerais à regarder le fonctionnement du rendering d'ASP.net ... t'y gagnerais beaucoup.

<hr />Cyril - MSP - MCTS ASP.net & SQL
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008

J'aimerais en connaitre plus sur le fonctionnement du rendering d'ASP.net. Pourrais-tu m'endiquer ou je peux trouver des informations le concernant ?

Mathmax
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
Euh, mathmax,

moi pas comprendre ??????

tu veux :

Ecrire du code HTML à l'intérieur d'une instruction ou fonction c# ...
ou
Ecrire du code HTML via une instruction ou fonction c# ...

Parce que pour info... si je ne dis pas de bêtise, le but d'asp/asp.net/java/php et autres, c'est justement de pouvoir ajouter des instructions logiques lors du rendering (côté server) de la page... non ?

PS:
1/ On utilise plus tellement le Response.Write en .NET.
2/ Il est préférable de ne plus mettre le code directement dans la page, mais de mettre la logique dans le code behind.

yopyop
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008

Il est préférable de ne plus mettre le code directement dans la page, mais de mettre la logique dans le code behind.


Pour moi, il y a deux choses. La logique métier et la logique d'affichage. Je voudrais pouvoir mettre toute la logique métier dans le code behind et toute la logique d'affichage dans la page aspx.

Voilà en gros le genre de chôse que j'aimerais pouvoir écrire :

            ----

            foreach (Product product in pruductList)
            {
                <%Response.Write(product.Name); %>,
                <%Response.Write(product.Price); %>,            
            }
       
   

Bon, je sais que ça n'est pas possible, mais je recherche une méthode qui équivaudrait à cela.
En fait, je ne fais ni plus, ni moins que reprendre le concept xslt. En xslt cela donnerais :

            ----

            <xsl:foreach select=\"Products/Product\">

                <xsl:value-of select="Name" />,

                <xsl:value-of select="Price" />,            

            </xsl:foreach

       

   

J'ai pris l'exemple, d'une boucle foreach, mais j'aimerais pouvoir faire des appels récursif, des conditions,....

Ce que je ne veux pas, c'est construire mon code html dans une string dans le code behind. Je le veux entièrement dans la page aspx.

Y a t'il des solutions avec les templates (dont parlais jesusonline plus haut) ou autre ?
Mathmax
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Modérateur
Dernière intervention
13 octobre 2010
28
oui les templates permet de faire en partie cela.

les templates c'est "juste" les propriétés "ItemTemplate" & co donc il faudra quand meme avoir une logique métier "d'affichage" au niveau du custom control.

par contre on peut imaginer des choses ...

un controle du genre

<toto:displayer runat="server">
  
        <condition test="truc = chose" />
        <trueTemplate>
             blabla
        </trueTemplate>
        <falseTemplate>
            bliblibli
        </falseTemplate>
  
</toto>

que tu bind avec un objet, ce genre de controle est vraiment sympa à faire .... ahhh si j'avais le temps :)

<hr />Cyril - MSP - MCTS ASP.net & SQL
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
re,

foreach (Product product in pruductList)
{
<%Response.Write(product.Name); %>,
<%Response.Write(product.Price); %>,           
}

c'est tout à fait possible de le mettre dans la page ASPX directement ...

http://www.codinghorror.com/blog/archives/000174.html

Pour moi, il y a deux choses. La logique métier et la logique
d'affichage. Je voudrais pouvoir mettre toute la logique métier dans le
code behind et toute la logique d'affichage dans la page aspx.

En ce qui me concerne, je mets la logique métier dans une dll séparée, donc les appels via le code behind sont très limités et il ne contient que la logique d'affichage, et propage les événements à ma couche métier (et parfois j'ajoute une couche entre les deux, si je dois par exemple faire une application dans une version web ET winform).
A ma connaissance, aucun language ne permet de faire une séparation complète...
les couches doivent bien communiquer entre elles.

Personnellement, je considère la page aspx comme un template (UI layout), et le code behind comme le moyen d'interagir avec ("logique" UI & appel à la logique métier).

D'ailleurs, 2 pages aspx peuvent partager le même code behind...

Bref, diffiçile de trouver une technologie qui nous convienne à 100%...

yopyop
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008

Je ne comprend pas. Ta page :

http://www.codinghorror.com/blog/archives/000174.html

n'explique pas comment encapsuler du code html mettre des instructions dans la page aspx. Il me semble qu'il est seulement indiquer comment se passer d'une page code-behind pour pouvoir recompiler dynamiquement, non ?
Mathmax
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
si,
en fait, ca explique comment se passer du code behind et donc de tout mettre dans la page aspx...
voici un example plus concret....
http://www.codeproject.com/aspnet/InlineCodeVSCodeBehind.asp

yopyop
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008

Dans les liens que tu m'envoie, le code c# ou vb est mis dans une balise <script runat=server></script>. Ce n'est pas ce que je veux faire. Ce n'est pas le fait que la logique se trouve dans la page code-behind qui me dérange. Je veux seulement pouvoir mettre des bouts de  code aspx ou html dans une boucle for, une condition, une fonction... mais sans avoir à les écrire dans une chaîne de caractère. Je ne suis pas sûr que tu ais bien compris quand tu m'as dit que c'est possible. Mais si ça l'est, je suis très intéressé de savoir comment.
Mathmax
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
Salut,

Voici un example ci-dessous...
J'espère que cela correspond à ce que tu désires faire (example en vb)

Dans la boucle j'ai mis un response.write, mais également une ligne entre une fermeture et une ouverture de tag script (ouverture <%, fermeture %>, comme en ASP 3.0).
Comme cette ligne est elle-même dans la boucle, elle sera écrite X fois.

De plus, dans cette ligne HTML, j'ai mis <%= i%>, de manière à te montrer comment récupérer la valeur d'une variable sans faire de response.write (en fait <%= est équivalent à Response.Write).

J'utilise souvent cette manière de faire en ASP (3.0)...
========================================================
<%@ Page Language="VB" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Page sans titre</title>
</head>

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

    <% 
 
        Dim iPreferedNumber As Integer = 3
        Dim sPreferedColor As String = "PaleTurquoise"
       
        For i As Integer = 1 To 10
            Response.Write("Line using Response.Write
")
            %>
            Line in HTML<% =i%>

            <%
        Next
     %>
     <hr />
          <%
         For i As Integer = 1 To 5
             If i = iPreferedNumber Then
             %>
             ----
">Mon utlisateur adore ce numéro: <%=i%>,
             <%
             Else
             %>
             ----
Mon utilisateur n'aime pas ce numéro: <%=i%>,
             <%
             End If
         Next
     %>
       

   

    </form>

</html>
========================================================

yopyop
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Modérateur
Dernière intervention
13 octobre 2010
28
YopYop, ton exemple est quand meme un sacré retour en arriere, un des buts de ASP.net est quand meme de plus avoir un mélange de code et de HTML ...

Mais si on fait des custom control on a rarement de problème ...

Mais c'est vrai que les 2 idées de controles que j'ai évoqué peut être sympa :

<toto:XSLTDisplayer runat="server" id="displayer1">
<xsltTemplate>
<xsl: ....
</xsltTemplate>
</toto:XSLTDisplayer>

et ensuite binder ce controle avec un objet métier, le contrôle se charge alors de serializer l'objet en XML puis d'appliquer le XSLT présent dans le template, niveau perf ca risque de pas etre top :/

l'autre idée

<toto:truc ...>

<condition test="" />
<trueTemplate>c'est vrai</trueTemplate>
<falseTemplate>c'est faux</falseTemplate>

</toto:truc>

c'est encore plus sexy mais ca nécessite "un peu" plus de boulot.

Enfin la derniere solution est de faire un BuildProvider qui parsera le XSLT et  générera le code de la page final ... mais là ca nécessite de refaire un parseur XSLT et de bien comprendre la compilation ASP.net. Pour info je connais très peu de BuildProvider, celui pour les pages ASP.net se trouve ici System.Web.Compilation.PageBuildProvider (tu peux t'amuser avec Reflector)
quoi que le BuilderProvider n'est peut etre pas forcement nécessaire, on peut très bien imaginer un controle qui à partir du XSLT génére du DOM ...

En tout cas la question est interessante, car oui il existe des soltuions natives dans ASP.net mais en cherchant un peu, on peut imaginer des controles vraiment sympa.

<hr />Cyril - MSP - MCTS ASP.net & SQL
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
yop,
je suis tout à fait d'accord avec toi...
comme je l'ai dit J'utilise souvent cette manière de faire en ASP (3.0)...

C'est lui qui veut mettre son code directement dans la page aspx, pas moi.

Le contrôle dont tu parles
<toto:XSLTDisplayer runat="server" id="displayer1">
<xsltTemplate>
<xsl: ....
</xsltTemplate>
</toto:XSLTDisplayer>

Existe (presque) déjà sauf qu'il ne sérialise pas l'objet, il faut lui passer un fichier xml... tiens, j'ai jamais essayé avec un dataset?! )
C'est System.Web.UI.WebControls.Xml (a force d'en parler on va croire que je rêve de ce contrôle ).

Pour l'autre
<toto:truc ...>

<condition test="" />
<trueTemplate>c'est vrai</trueTemplate>
<falseTemplate>c'est faux</falseTemplate>

</toto:truc>

Un "bête" Repeater et la logique (condition, etc...) dans le OnItemDataBound et c'est bon...
Faire un composant est certainement techniquement intéressant à faire, mais je ne pense pas que cela aurait une quelconque valeur ajoutée...
Au final tu te retrouverais dans une situtation identiquement à mon example "old school", la logique serait dans la page ASPX et non dans le code behind...

et je te cite:
ton exemple est quand meme un sacré retour en arriere, un des buts de
ASP.net est quand meme de plus avoir un mélange de code et de HTML ...

yopyop
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Modérateur
Dernière intervention
13 octobre 2010
28
vivi le premier type de controle est "simple" à faire, il suffit d'hériter du composant XML. Le problème est que cela ne gérera pas les controles ASP.net, ce sera seulement du HTML :-/  la deuxieme solution avec le controle "truc"permet d'avoir des controles ASP.net au millieu de boucle, condition, etc.... La meilleure solution consisterais selon moi à un composant qui génére du code (via CodeDom) à partir de XSLT, lors de la compilation des pages ASP.net.

Mais je suis d'accord que ce que je propose ressemble à un mélange de code et de HTML, mais contrairement à la classique solution ASP3, on ne peut faire que de l'affichage, on ne peut pas meme pas récupérer l'objet sur lequel on travail puisque le binding se fait via le code behind, ou via un controle d'accès aux données (xxxDataSource)

<hr />Cyril - MSP - MCTS ASP.net & SQL
Messages postés
586
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 février 2010
1
En fait, si tu fais de l'aspx à la façon asp 3.0, tu peux faire exactement la même chsoe qu'avec des contrôles... mais sans pouvoir utiliser les contrôles ....

donc autant faire de l'asp 3.0 et non du .NET

yopyop
Messages postés
403
Date d'inscription
vendredi 28 octobre 2005
Statut
Membre
Dernière intervention
31 août 2008

Yopyop, merci beaucoup pour ton exemple. Je crois que c'est la technique qui me parait la plus adaptée à la plupart des créations de mes pages.

Je ne trouve pas que cette technique soit un retour en arrière. Certes il  y a de la logique mélangée au code aspx, mais c'est de la logique d'affichage (comme pour le xslt). Et d'ailleurs si cette technique était fondamentalement moins bonne, pourquoi microsoft aurait-il laissé la possibilité de l'appliquer ?

Jesusonline, je ne vois pas l'intérêt de créer un contrôle dans lequel on écrit du xslt, le contrôle se chargeant de faire la sérialisation de l'objet auquel il est lié. Autant écrire ce qu'a écrit yopyop, ça fait la même chose que le xslt (c'est juste la syntaxe qui change), mais en plus rapide et tout en permettant de mettre des contrôles aspx en non plus seulement du code html. C'est vrai qu'on peut être tenté d'y ajouter de la logique qui devrait normalement se trouver dans la page aspx, mais rien ne nous oblige à le faire...
Mathmax