[ASPNET MVC] View engines alternatifs
8 views
Skip to first unread message
Yann Schwartz
Mar 2, 2009, 7:20:34 AM3/2/09
to paris.alt.net
Bonjour bonjour,
Histoire de varier un peu et de parler d'autre chose que de
calendriers (sujet hautement estimable cela dit) voici une petite
question.
J'aime bien ASP.Net MVC, mais je suis allergique au view engine
proposé par défaut. Chaque fois que je vois un <% } %> mes yeux
saignent.
Du temps de MonoRail, j'étais allergique à (N)Velocity (j'aime pas la
syntaxe et mon exécrable expérience de l'extensibilité de
CruiseControl.Net m'a définitivement vacciné contre ce view engine) et
j'utilisais Brail.
Bon, je sais que Brail existe vaguement pour ASPNET MVC mais ça a
l'air plus d'une preuve de concept qu'autre chose et il n'y a
pratiquement pas d'activité dessus.
J'aime pas (N)HAML qui à mon sens prend le problème à l'envers.
Et j'aime beaucoup Spark.
Mais voilà, Spark c'est essentiellement une personne (Louis Dejardin)
et certaines possibilités du view engine par défaut manquent
(intégration de certains WebControls - graphes par exemple) et
scaffolding (qui pourrait être reproduit sans trop de mal avec du T4
spécifique je suppose).
Je sais qu'il y a ici pas mal de gens qui font vraiment du ASPNET MVC
(contrairement à moi qui fait des petits sites perso ou des trucs en
douce dans mes projets pro) et même certains qui utilisent Spark (j'ai
des noms). Je voudrais donc savoir votre expérience sur l'usage de
view engines alternatifs ou vos conseils pour limiter la laideur du
view engine par défaut.
Histoire de varier un peu et de parler d'autre chose que de
calendriers (sujet hautement estimable cela dit) voici une petite
question.
J'aime bien ASP.Net MVC, mais je suis allergique au view engine
proposé par défaut. Chaque fois que je vois un <% } %> mes yeux
saignent.
Du temps de MonoRail, j'étais allergique à (N)Velocity (j'aime pas la
syntaxe et mon exécrable expérience de l'extensibilité de
CruiseControl.Net m'a définitivement vacciné contre ce view engine) et
j'utilisais Brail.
Bon, je sais que Brail existe vaguement pour ASPNET MVC mais ça a
l'air plus d'une preuve de concept qu'autre chose et il n'y a
pratiquement pas d'activité dessus.
J'aime pas (N)HAML qui à mon sens prend le problème à l'envers.
Et j'aime beaucoup Spark.
Mais voilà, Spark c'est essentiellement une personne (Louis Dejardin)
et certaines possibilités du view engine par défaut manquent
(intégration de certains WebControls - graphes par exemple) et
scaffolding (qui pourrait être reproduit sans trop de mal avec du T4
spécifique je suppose).
Je sais qu'il y a ici pas mal de gens qui font vraiment du ASPNET MVC
(contrairement à moi qui fait des petits sites perso ou des trucs en
douce dans mes projets pro) et même certains qui utilisent Spark (j'ai
des noms). Je voudrais donc savoir votre expérience sur l'usage de
view engines alternatifs ou vos conseils pour limiter la laideur du
view engine par défaut.
Vincent Bourdon
Mar 2, 2009, 7:44:30 AM3/2/09
to paris...@googlegroups.com
Salut,
Je te rejoins dans le fait que le <% } %> ça pique les yeux.
Cependant je continue à utiliser le view engine de base de MS.
Je ne connais pas bien spark, de ce que j'en ai vue, je n'aime pas trop le mélange entre attribut html/xhtml et attribut spark.
Finalement le view engine de MS permet de bien voir les blocs serveur et les blocs client, et visual comprend ce que l'on tape :)
Je voudrais savoir pourquoi tu veux mettre des Web controls dans tes pages ? pour le scaffolding à mon avis ça va venir, si ce n'est déjà le cas avec ADO.net data services.
@+ Vincent
Julien
Mar 2, 2009, 8:00:33 AM3/2/09
to paris.alt.net
Je vous rejoins tout les deux sur le fait que ce genre de choses est
assez désagréable : <% } %>.
Je ne fais plus d'asp.net mvc actuellement mais quand c'était mon taff
à plein temps, j'avais appris à vivre avec. A l'époque, l'intellisense
était inexistant ou quasi-inexistant dans spark et ce fut suffisant
pour me décourager. C'est mieux aujourd'hui, mais je crois qu'il est
nécessaire de désactiver l'intellisense de resharper (hmm...).
Le seul avis que je peux offrir, c'est qu'il est possible de faire
diminuer significativement le nombre de <% } %>, et autre if/while en
ayant une utilisation un peu *extreme* des différentes fonctionnalités
du framework. Si bien qu'on se retrouve a avoir quasiment uniquement
des choses de ce style :
<% Html.RenderMyCustomPageOrControl(params); %>
Julien
On 2 mar, 13:44, Vincent Bourdon <evilz...@gmail.com> wrote:
> Salut,
> Je te rejoins dans le fait que le <% } %> ça pique les yeux.
> Cependant je continue à utiliser le view engine de base de MS.
>
> Je ne connais pas bien spark, de ce que j'en ai vue, je n'aime pas trop le
> mélange entre attribut html/xhtml et attribut spark.
>
> Finalement le view engine de MS permet de bien voir les blocs serveur et les
> blocs client, et visual comprend ce que l'on tape :)
>
> Je voudrais savoir pourquoi tu veux mettre des Web controls dans tes pages ?
> pour le scaffolding à mon avis ça va venir, si ce n'est déjà le cas avec
> ADO.net data services.**
>
> @+ Vincent
>
> 2009/3/2 Yann Schwartz <abolibibe...@gmail.com>
assez désagréable : <% } %>.
Je ne fais plus d'asp.net mvc actuellement mais quand c'était mon taff
à plein temps, j'avais appris à vivre avec. A l'époque, l'intellisense
était inexistant ou quasi-inexistant dans spark et ce fut suffisant
pour me décourager. C'est mieux aujourd'hui, mais je crois qu'il est
nécessaire de désactiver l'intellisense de resharper (hmm...).
Le seul avis que je peux offrir, c'est qu'il est possible de faire
diminuer significativement le nombre de <% } %>, et autre if/while en
ayant une utilisation un peu *extreme* des différentes fonctionnalités
du framework. Si bien qu'on se retrouve a avoir quasiment uniquement
des choses de ce style :
<% Html.RenderMyCustomPageOrControl(params); %>
Julien
On 2 mar, 13:44, Vincent Bourdon <evilz...@gmail.com> wrote:
> Salut,
> Je te rejoins dans le fait que le <% } %> ça pique les yeux.
> Cependant je continue à utiliser le view engine de base de MS.
>
> Je ne connais pas bien spark, de ce que j'en ai vue, je n'aime pas trop le
> mélange entre attribut html/xhtml et attribut spark.
>
> Finalement le view engine de MS permet de bien voir les blocs serveur et les
> blocs client, et visual comprend ce que l'on tape :)
>
> Je voudrais savoir pourquoi tu veux mettre des Web controls dans tes pages ?
> pour le scaffolding à mon avis ça va venir, si ce n'est déjà le cas avec
>
> @+ Vincent
>
> 2009/3/2 Yann Schwartz <abolibibe...@gmail.com>
Gauthier Segay
Mar 2, 2009, 8:31:38 AM3/2/09
to paris.alt.net
disclaimer: entre un datagrid et un repeater je préfère le repeater,
entre le repeater et le foreach, je préfère le foreach ;)
juste pour rebondir, un thread précédent était passé sur ce sujet de
"maintenabilité" des vues
http://groups.google.com/group/parisaltnet/browse_frm/thread/50af35e70f30eb65/48ef5284f66f69cf
pour revenir sur la question, pour ma part, j'utilise aspview sous
monorail qui est un clone du viewengine webform (avec quelques
limitations) et donc une syntaxe identique pour le code serveur,
l'avantage est que la syntaxe est connue de tous (php, ruby, asp) et
si l'on prend le temps de décomposer le code des vues cela reste amha
plus acceptable qu'une bouillie illisible de tag runat="server" (ont
comprend "l'interêt" du designer webform visuel...).
je pense que les choses du genre <
%=Html.MethodNameThatDoesntEndOrIsNotReadable()%> vont à l'encontre de
ce que j'attends dans le code de la vue: que ce soit lisible/
modifiable par un designer html (qui ne fait pas de c# ou de php ou
autre langage) sans tout casser.
entre le repeater et le foreach, je préfère le foreach ;)
juste pour rebondir, un thread précédent était passé sur ce sujet de
"maintenabilité" des vues
http://groups.google.com/group/parisaltnet/browse_frm/thread/50af35e70f30eb65/48ef5284f66f69cf
pour revenir sur la question, pour ma part, j'utilise aspview sous
monorail qui est un clone du viewengine webform (avec quelques
limitations) et donc une syntaxe identique pour le code serveur,
l'avantage est que la syntaxe est connue de tous (php, ruby, asp) et
si l'on prend le temps de décomposer le code des vues cela reste amha
plus acceptable qu'une bouillie illisible de tag runat="server" (ont
comprend "l'interêt" du designer webform visuel...).
je pense que les choses du genre <
%=Html.MethodNameThatDoesntEndOrIsNotReadable()%> vont à l'encontre de
ce que j'attends dans le code de la vue: que ce soit lisible/
modifiable par un designer html (qui ne fait pas de c# ou de php ou
autre langage) sans tout casser.
Vincent Bourdon
Mar 2, 2009, 8:34:42 AM3/2/09
to paris...@googlegroups.com
En fait y 2 moyens qui reviennent souvent:
- Les user controls : <%= Html.RenderPartial("mavue") %>
- Les Helper : <% Html.CreateUlMenu(mes params ...) %>
Dans les 2 cas, ça évite les copier coller de code, et ça peut rendre testable certaines parties, mais surtout c'est très simple et claire dans la page.
pour moi un truc du genre
<div if='montest()' > c'est bien mais pas top ..
Une réunion sur le sujet me dit bien. Sur tout ce qui tourne autour de MVC dans toute les techno.
Pourquoi ne pas faire des rencontres dans un bar ou autre pour discuter 1 fois par mois en plus des réunions avec présentation , puisque souvent on manque de temps après les présentations ?
@+
2009/3/2 Julien <julien....@gmail.com>
Julien
Mar 2, 2009, 8:42:46 AM3/2/09
to paris.alt.net
l'autre problème du "<div if='montest()' >" c'est qu'on a aucun moyen
simple de detecter une erreur de syntaxe avant l'execution.
Avec le view engine par défaut, on peut compiler les vues dans nant/
msbuild (http://www.thedotnetfrog.fr/2008/09/12/precompilation-des-
fichiers-aspx/)
On 2 mar, 14:34, Vincent Bourdon <evilz...@gmail.com> wrote:
> En fait y 2 moyens qui reviennent souvent:
> - Les user controls : <%= Html.RenderPartial("mavue") %>
> - Les Helper : <% Html.CreateUlMenu(mes params ...) %>
>
> Dans les 2 cas, ça évite les copier coller de code, et ça peut rendre
> testable certaines parties, mais surtout c'est très simple et claire dans la
> page.
>
> pour moi un truc du genre
>
> <div if='montest()' > c'est bien mais pas top ..
>
> Une réunion sur le sujet me dit bien. Sur tout ce qui tourne autour de MVC
> dans toute les techno.
>
> Pourquoi ne pas faire des rencontres dans un bar ou autre pour discuter 1
> fois par mois en plus des réunions avec présentation , puisque souvent on
> manque de temps après les présentations ?
>
> @+
>
> 2009/3/2 Julien <julien.lavi...@gmail.com>
simple de detecter une erreur de syntaxe avant l'execution.
Avec le view engine par défaut, on peut compiler les vues dans nant/
msbuild (http://www.thedotnetfrog.fr/2008/09/12/precompilation-des-
fichiers-aspx/)
On 2 mar, 14:34, Vincent Bourdon <evilz...@gmail.com> wrote:
> En fait y 2 moyens qui reviennent souvent:
> - Les user controls : <%= Html.RenderPartial("mavue") %>
> - Les Helper : <% Html.CreateUlMenu(mes params ...) %>
>
> Dans les 2 cas, ça évite les copier coller de code, et ça peut rendre
> testable certaines parties, mais surtout c'est très simple et claire dans la
> page.
>
> pour moi un truc du genre
>
> <div if='montest()' > c'est bien mais pas top ..
>
> Une réunion sur le sujet me dit bien. Sur tout ce qui tourne autour de MVC
> dans toute les techno.
>
> Pourquoi ne pas faire des rencontres dans un bar ou autre pour discuter 1
> fois par mois en plus des réunions avec présentation , puisque souvent on
> manque de temps après les présentations ?
>
> @+
>
Gauthier Segay
Mar 2, 2009, 8:55:26 AM3/2/09
to paris.alt.net
je crois que spark est précompilé, il doit donc être possible de faire
une vérification statique des vues (possible avec aspview)
une vérification statique des vues (possible avec aspview)
Vincent Bourdon
Mar 2, 2009, 8:56:51 AM3/2/09
to paris...@googlegroups.com
Salut,
Je ne pense pas qu'il soit possible de n'avoir aucun code dans une vue ! A partir du moment ou tu fais des pages dynamiques y a forcement du code, sinon faut faire des pages html toute simples.
Pour le coup je ne suis pas d'accord avec
je pense que les choses du genre <
%=Html.MethodNameThatDoesntEndOrIsNotReadable()%> vont à l'encontre de
ce que j'attends dans le code de la vue: que ce soit lisible/
modifiable par un designer html (qui ne fait pas de c# ou de php ou
autre langage) sans tout casser.
Je suis tout à fait en accord sur le fait qu'un foreach c'est le top !
2009/3/2 Gauthier Segay <gauthie...@gmail.com>
Gauthier Segay
Mar 2, 2009, 9:06:56 AM3/2/09
to paris...@googlegroups.com
je pense avoir mélangé 2 sujets:
- les helpers pour écrire 2 lignes de html :
je trouve que les helpers du genre Html.Img(src) sont moins lisible
que la balise elle même, j'utilise il est vrai le form helper de MR
car cela génère du code de validation jquery mais c'est vraiment le
seuil endroit ou je préfère perdre un peu la main
- des bouts de code plus compliqués pour remplacer les 300 lignes de
code préalablement dans le ondatabound:
ici je pense qu'il vaut mieux faire des viewcomponents (concept
monorail) spécifiques que d'essayer de tout mettre dans la même vue,
il faut également "dénormaliser" son modèle "domaine" pour un modèle
"vue" dans le controller afin que des opérations de lookup/condition
soient écrites facilement dans le code de la vue -> on supprime
généralement le code compliqué
2009/3/2 Vincent Bourdon <evil...@gmail.com>:
Julien
Mar 2, 2009, 9:07:45 AM3/2/09
to paris.alt.net
Au temps pour moi alors :-)
Vincent Bourdon
Mar 2, 2009, 9:21:20 AM3/2/09
to paris...@googlegroups.com
Je ne suis pas d'accord avec vous sur le Html.Img(src)
Cet helper permet de mettre un virtualPath avec le '~' ! Cela n'existe pas en html.
De plus on peut encore l'améliorer pour géré les chemins cassé avec du js : onerror="this.style.display = 'none';"
De plus on peut encore l'améliorer pour géré les chemins cassé avec du js : onerror="this.style.display = 'none';"
ça Vous dit pas d'en discuter la semaine prochaine ou celle d'après de vive voix ? On pourra en résumer un bon morceau sur le wiki !
++ Vincent
Gauthier Segay
Mar 2, 2009, 9:32:34 AM3/2/09
to paris...@googlegroups.com
pour le ~/ je ne fais plus attention car aspview le gère nativement
(pas besoin de faire un resolveurl ou autre).
(pas besoin de faire un resolveurl ou autre).
pour l'autre exemple, je pense qu'un selecteur jquery sera plus joli
(une seule ligne de code non répétée plutôt qu'un attribut sur chaque
image...)
il existe bien sur des cas ou il vaut mieux utiliser le helper, mais
selon moi c'est loin d'être pour la majorité et cela ne correspond pas
à la tendance ou il faut un helper pour chaque balise.
pour les rdv "off" je suis partant car je pars toujours sur ma faim
après nos réunions, je pense qu'on va bientôt avoir de quoi faire une
page "helper vs helperless" :)
2009/3/2 Vincent Bourdon <evil...@gmail.com>:
Vincent Bourdon
Mar 2, 2009, 9:55:48 AM3/2/09
to paris...@googlegroups.com
lol
Pour le cas de aspview je ne savais pas.
Pour le cas de jquery c'est aussi ce que j'aurais fait, mais je ne trouvais pas d'autre exemple ;)
Alors est ce que l'on fixe une date pour notre MVC meeting ? Qui d'autre est pour ?
2009/3/2 Gauthier Segay <gauthie...@gmail.com>
Yann Schwartz
Mar 2, 2009, 12:37:25 PM3/2/09
to paris.alt.net
@Vincent:
Pourquoi des WebControls ? Pour pouvoir réutiliser des choses pas trop
mal, le nouveau contrôle de Graphs d'Asp.net, par exemple.
Refuser des structures de contrôle dans la vue est estimable, mais ça
revient à les pousser soit dans la sous-vue (ou component view) et le
même problème se pose (il faut bien les mettre quelque part les
structures de contrôles), soit dans du code (et on risque vite de
tricoter du HTML dans du code, mmh, retour à la case départ).
Au risque de me faire taper dessus, je trouve le concept de contrôles
d'ASP.Net plutôt bien. Bon, les gros désavantages :
* Modèle événementiel : non-sens rapidement ingérable. Utile pour
donner l'impression que c'est comme du winforms.
* ViewState : abomination
* Code HTML dégueulasse : pas une fatalité, on peut écrire un contrôle
css friendly et donner la possibilité de personnaliser.
Maintenant les avantages :
* Bon niveau d'abstraction
* bonne découvrabilité
* modèle déclaratif
* Databinding (en se débarrassant des scories liées au modèle
événementiel)
Quand je vois certains helpers aux paramètres d'appel abominables et
impossibles à découvrir, implémentés comme une suite étourdissante de
concaténations de chaînes, j'ai l'impression qu'on jette le bébé avec
l'eau du bain. Je préfère un modèle MVC au modèle WebForms, mais ça ne
m'empêche pas de trouver sympathique que la notion de contrôle dans
une vue.
Pourquoi des WebControls ? Pour pouvoir réutiliser des choses pas trop
mal, le nouveau contrôle de Graphs d'Asp.net, par exemple.
Refuser des structures de contrôle dans la vue est estimable, mais ça
revient à les pousser soit dans la sous-vue (ou component view) et le
même problème se pose (il faut bien les mettre quelque part les
structures de contrôles), soit dans du code (et on risque vite de
tricoter du HTML dans du code, mmh, retour à la case départ).
Au risque de me faire taper dessus, je trouve le concept de contrôles
d'ASP.Net plutôt bien. Bon, les gros désavantages :
* Modèle événementiel : non-sens rapidement ingérable. Utile pour
donner l'impression que c'est comme du winforms.
* ViewState : abomination
* Code HTML dégueulasse : pas une fatalité, on peut écrire un contrôle
css friendly et donner la possibilité de personnaliser.
Maintenant les avantages :
* Bon niveau d'abstraction
* bonne découvrabilité
* modèle déclaratif
* Databinding (en se débarrassant des scories liées au modèle
événementiel)
Quand je vois certains helpers aux paramètres d'appel abominables et
impossibles à découvrir, implémentés comme une suite étourdissante de
concaténations de chaînes, j'ai l'impression qu'on jette le bébé avec
l'eau du bain. Je préfère un modèle MVC au modèle WebForms, mais ça ne
m'empêche pas de trouver sympathique que la notion de contrôle dans
une vue.
Clément
Mar 3, 2009, 3:33:37 AM3/3/09
to paris.alt.net
Je suis un nioub sur le sujet mais le sujet discuté m'intéresse
fortement :). Je suis aussi pour un meeting MVC en off --> peut-être
que ça pourrait donner lieu à une présentation par la suite, après
synthèse sur le wiki.
Clément
On 2 mar, 15:55, Vincent Bourdon <evilz...@gmail.com> wrote:
> lol
> Pour le cas de aspview je ne savais pas.
> Pour le cas de jquery c'est aussi ce que j'aurais fait, mais je ne trouvais
> pas d'autre exemple ;)
>
> Alors est ce que l'on fixe une date pour notre MVC meeting ? Qui d'autre est
> pour ?
>
> 2009/3/2 Gauthier Segay <gauthier.se...@gmail.com>
fortement :). Je suis aussi pour un meeting MVC en off --> peut-être
que ça pourrait donner lieu à une présentation par la suite, après
synthèse sur le wiki.
Clément
On 2 mar, 15:55, Vincent Bourdon <evilz...@gmail.com> wrote:
> lol
> Pour le cas de aspview je ne savais pas.
> Pour le cas de jquery c'est aussi ce que j'aurais fait, mais je ne trouvais
> pas d'autre exemple ;)
>
> Alors est ce que l'on fixe une date pour notre MVC meeting ? Qui d'autre est
> pour ?
>
>
>
>
> > pour le ~/ je ne fais plus attention car aspview le gère nativement
> > (pas besoin de faire un resolveurl ou autre).
>
> > pour l'autre exemple, je pense qu'un selecteur jquery sera plus joli
> > (une seule ligne de code non répétée plutôt qu'un attribut sur chaque
> > image...)
>
> > il existe bien sur des cas ou il vaut mieux utiliser le helper, mais
> > selon moi c'est loin d'être pour la majorité et cela ne correspond pas
> > à la tendance ou il faut un helper pour chaque balise.
>
> > pour les rdv "off" je suis partant car je pars toujours sur ma faim
> > après nos réunions, je pense qu'on va bientôt avoir de quoi faire une
> > page "helper vs helperless" :)
>
> > 2009/3/2 Vincent Bourdon <evilz...@gmail.com>:
>
>
> > pour le ~/ je ne fais plus attention car aspview le gère nativement
> > (pas besoin de faire un resolveurl ou autre).
>
> > pour l'autre exemple, je pense qu'un selecteur jquery sera plus joli
> > (une seule ligne de code non répétée plutôt qu'un attribut sur chaque
> > image...)
>
> > il existe bien sur des cas ou il vaut mieux utiliser le helper, mais
> > selon moi c'est loin d'être pour la majorité et cela ne correspond pas
> > à la tendance ou il faut un helper pour chaque balise.
>
> > pour les rdv "off" je suis partant car je pars toujours sur ma faim
> > après nos réunions, je pense qu'on va bientôt avoir de quoi faire une
> > page "helper vs helperless" :)
>
> > > Je ne suis pas d'accord avec vous sur le Html.Img(src)
> > > Cet helper permet de mettre un virtualPath avec le '~' ! Cela n'existe
> > > pas en html.
> > > De plus on peut encore l'améliorer pour géré les chemins cassé avec du
> > js
> > > : onerror="this.style.display = 'none';"
> > > ça Vous dit pas d'en discuter la semaine prochaine ou celle d'après de
> > vive
> > > voix ? On pourra en résumer un bon morceau sur le wiki !
> > > ++ Vincent
>
> > > 2009/3/2 Gauthier Segay <gauthier.se...@gmail.com>
> > > Cet helper permet de mettre un virtualPath avec le '~' ! Cela n'existe
> > > pas en html.
> > > De plus on peut encore l'améliorer pour géré les chemins cassé avec du
> > js
> > > : onerror="this.style.display = 'none';"
> > > ça Vous dit pas d'en discuter la semaine prochaine ou celle d'après de
> > vive
> > > voix ? On pourra en résumer un bon morceau sur le wiki !
> > > ++ Vincent
>
>
> > >> je pense avoir mélangé 2 sujets:
>
> > >> - les helpers pour écrire 2 lignes de html :
> > >> je trouve que les helpers du genre Html.Img(src) sont moins lisible
> > >> que la balise elle même, j'utilise il est vrai le form helper de MR
> > >> car cela génère du code de validation jquery mais c'est vraiment le
> > >> seuil endroit ou je préfère perdre un peu la main
>
> > >> - des bouts de code plus compliqués pour remplacer les 300 lignes de
> > >> code préalablement dans le ondatabound:
> > >> ici je pense qu'il vaut mieux faire des viewcomponents (concept
> > >> monorail) spécifiques que d'essayer de tout mettre dans la même vue,
> > >> il faut également "dénormaliser" son modèle "domaine" pour un modèle
> > >> "vue" dans le controller afin que des opérations de lookup/condition
> > >> soient écrites facilement dans le code de la vue -> on supprime
> > >> généralement le code compliqué
>
> > >> 2009/3/2 Vincent Bourdon <evilz...@gmail.com>:
> > >> je pense avoir mélangé 2 sujets:
>
> > >> - les helpers pour écrire 2 lignes de html :
> > >> je trouve que les helpers du genre Html.Img(src) sont moins lisible
> > >> que la balise elle même, j'utilise il est vrai le form helper de MR
> > >> car cela génère du code de validation jquery mais c'est vraiment le
> > >> seuil endroit ou je préfère perdre un peu la main
>
> > >> - des bouts de code plus compliqués pour remplacer les 300 lignes de
> > >> code préalablement dans le ondatabound:
> > >> ici je pense qu'il vaut mieux faire des viewcomponents (concept
> > >> monorail) spécifiques que d'essayer de tout mettre dans la même vue,
> > >> il faut également "dénormaliser" son modèle "domaine" pour un modèle
> > >> "vue" dans le controller afin que des opérations de lookup/condition
> > >> soient écrites facilement dans le code de la vue -> on supprime
> > >> généralement le code compliqué
>
> > >> > Salut,
> > >> > Pour le coup je ne suis pas d'accord avec
>
> > >> > je pense que les choses du genre <
> > >> > %=Html.MethodNameThatDoesntEndOrIsNotReadable()%> vont à l'encontre de
> > >> > ce que j'attends dans le code de la vue: que ce soit lisible/
> > >> > modifiable par un designer html (qui ne fait pas de c# ou de php ou
> > >> > autre langage) sans tout casser.
>
> > >> > Je ne pense pas qu'il soit possible de n'avoir aucun code dans une vue
> > !
> > >> > A
> > >> > partir du moment ou tu fais des pages dynamiques y a forcement du
> > code,
> > >> > sinon faut faire des pages html toute simples.
> > >> > Je suis tout à fait en accord sur le fait qu'un foreach c'est le top !
>
> > >> > 2009/3/2 Gauthier Segay <gauthier.se...@gmail.com>
> > >> > Pour le coup je ne suis pas d'accord avec
>
> > >> > je pense que les choses du genre <
> > >> > %=Html.MethodNameThatDoesntEndOrIsNotReadable()%> vont à l'encontre de
> > >> > ce que j'attends dans le code de la vue: que ce soit lisible/
> > >> > modifiable par un designer html (qui ne fait pas de c# ou de php ou
> > >> > autre langage) sans tout casser.
>
> > >> > Je ne pense pas qu'il soit possible de n'avoir aucun code dans une vue
> > !
> > >> > A
> > >> > partir du moment ou tu fais des pages dynamiques y a forcement du
> > code,
> > >> > sinon faut faire des pages html toute simples.
> > >> > Je suis tout à fait en accord sur le fait qu'un foreach c'est le top !
>
>
> > >> >> disclaimer: entre un datagrid et un repeater je préfère le repeater,
> > >> >> entre le repeater et le foreach, je préfère le foreach ;)
>
> > >> >> juste pour rebondir, un thread précédent était passé sur ce sujet de
> > >> >> "maintenabilité" des vues
>
> >http://groups.google.com/group/parisaltnet/browse_frm/thread/50af35e7...
> > >> >> disclaimer: entre un datagrid et un repeater je préfère le repeater,
> > >> >> entre le repeater et le foreach, je préfère le foreach ;)
>
> > >> >> juste pour rebondir, un thread précédent était passé sur ce sujet de
> > >> >> "maintenabilité" des vues
>
Gauthier Segay
Mar 3, 2009, 6:50:51 PM3/3/09
to paris.alt.net
Yann, peux-tu nous décrire le problème avec le WebControl "graphes"?
de mon côté je ne trouve pas de doc précise sur le net.
je suis étonné qu'il n'y ait pas de contournement pour faire ce que
ferais ce webcontrol, j'ai déjà utilisé des librairies js pour faire
des graphes simples (histo, pie...) mais je n'ai pas eu besoin de
webcontrol dans mon cas.
le problème des webcontrols asp.net c'est que, généralement, leur
implémentation ne prends pas du tout en compte la possibilité de
fonctionner sans form runat="server" / viewstate, sans .Page, et pour
la customisation du rendu, écrire un cssadapter relève du suplice
(tout en restant pas très flexible).
Bref, en dehors du designer webform et se plier aux contraintes citées
(pas possible pour un site public à mon sens), difficile d'utiliser le
framework webform, je crois que cela s'ameliore encore avec la v4 (en
poursuivants les efforts de la v2) mais les webforms (ou JSF)
resteront ce qu'ils sont.
l'idée avec les viewcomponents monorail c'est que le code du
viewcomponent (code behind) est découplé du template de rendu du
contrôle, de la même manière que controlleur l'est avec ses vues, je
ne sais pas si asp.net mvc supporte cela ou si il est limité aux
partialviews/subviews et "hacks" RenderUserControl.
de mon côté je ne trouve pas de doc précise sur le net.
je suis étonné qu'il n'y ait pas de contournement pour faire ce que
ferais ce webcontrol, j'ai déjà utilisé des librairies js pour faire
des graphes simples (histo, pie...) mais je n'ai pas eu besoin de
webcontrol dans mon cas.
le problème des webcontrols asp.net c'est que, généralement, leur
implémentation ne prends pas du tout en compte la possibilité de
fonctionner sans form runat="server" / viewstate, sans .Page, et pour
la customisation du rendu, écrire un cssadapter relève du suplice
(tout en restant pas très flexible).
Bref, en dehors du designer webform et se plier aux contraintes citées
(pas possible pour un site public à mon sens), difficile d'utiliser le
framework webform, je crois que cela s'ameliore encore avec la v4 (en
poursuivants les efforts de la v2) mais les webforms (ou JSF)
resteront ce qu'ils sont.
l'idée avec les viewcomponents monorail c'est que le code du
viewcomponent (code behind) est découplé du template de rendu du
contrôle, de la même manière que controlleur l'est avec ses vues, je
ne sais pas si asp.net mvc supporte cela ou si il est limité aux
partialviews/subviews et "hacks" RenderUserControl.
Gauthier Segay
Mar 3, 2009, 6:59:19 PM3/3/09
to paris.alt.net
j'ai remis la main sur ce post avec quelques tips pour que la soupe
pique moins:
http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/
On Mar 2, 1:44 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Salut,
> Je te rejoins dans le fait que le <% } %> ça pique les yeux.
> Cependant je continue à utiliser le view engine de base de MS.
>
> Je ne connais pas bien spark, de ce que j'en ai vue, je n'aime pas trop le
> mélange entre attribut html/xhtml et attribut spark.
>
> Finalement le view engine de MS permet de bien voir les blocs serveur et les
> blocs client, et visual comprend ce que l'on tape :)
>
> Je voudrais savoir pourquoi tu veux mettre des Web controls dans tes pages ?
> pour le scaffolding à mon avis ça va venir, si ce n'est déjà le cas avec
> ADO.net data services.**
>
> @+ Vincent
>
> 2009/3/2 Yann Schwartz <abolibibe...@gmail.com>
pique moins:
http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/
On Mar 2, 1:44 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Salut,
> Je te rejoins dans le fait que le <% } %> ça pique les yeux.
> Cependant je continue à utiliser le view engine de base de MS.
>
> Je ne connais pas bien spark, de ce que j'en ai vue, je n'aime pas trop le
> mélange entre attribut html/xhtml et attribut spark.
>
> Finalement le view engine de MS permet de bien voir les blocs serveur et les
> blocs client, et visual comprend ce que l'on tape :)
>
> Je voudrais savoir pourquoi tu veux mettre des Web controls dans tes pages ?
> pour le scaffolding à mon avis ça va venir, si ce n'est déjà le cas avec
>
> @+ Vincent
>
> 2009/3/2 Yann Schwartz <abolibibe...@gmail.com>
Yann Schwartz
Mar 3, 2009, 7:58:44 PM3/3/09
to paris.alt.net
C'est vrai, on peut toujours contourner.Pour de jolis graphes j'ai pas
mal utilisé Flot qui convenait à la plupart de mes besoins et repose
sur JQuery - ce qui ne gâte rien. Cependant, je devais à chaque fois
me retaper à la main l'intégration de mes données générées et le
passage par deux ou trois niveaux d'abstraction pour un résultat.
Marrant à faire la première fois, et ça m'a permis de me mettre un peu
plus sérieusement à JQuery, mais effroyable à maintenir pour mes
successeurs. Dans ces cas, la notion de WebControl (hors ViewState et
événements que j'abhorre) permet de rester au bon niveau d'abstraction
et je persiste à penser que le databinding est une bonne chose. Je
suis d'accord pour trouver grotesque un <a runat="server" /> cela dit.
Quant aux tips pour éviter le tag soup que tu as référencé, je les
avais lus et j'étais resté assez dubitatif. Déjà, quoi qu'il arrive,
on ne se débarasse pas des <% } %> (en vérité je vous le dis, Python/
Boo ou #light sont vos amis) ensuite il repousse le problème sous le
tapis soit dans un renderpartial soit - horreur - en concaténant dans
une méthode des chaînes qui devraient appartenir à la vue. Et ses
méthodes ressemblent furieusement à ce qu'on pourrait trouver dans un
WebControl qui ferait du RenderContent plutôt que de la composition
(le côté css-friendly en moins, suffit de regarder l'exemple du
NumericPager dans l'article...). Retour à la case départ. C'est pour
ça que je préfère Spark qui annote sans intrusion les balises et
utilise la structure en arbre des tags comme squelette naturel pour
les structures de contrôles (au passage, l'inverse exact de (N)HAML,
fétichisme rubyesque).
En terme de satisfaction esthétique (autrement dit, en terme de
moindre saignage des yeux et d'acceptation sereine du markup) je
préfère Spark à toutes les variantes d'Aspview ou viewengine par
défaut. Je préfère même à ces derniers les bizarreries que je tentais
dans une vie antérieure comme utiliser Python comme moteur de script
ActiveX pour faire du ASP classique (pas .Net...)
Bizarrement, un <% End If %> VB.Net me choque moins que ce <% } %> qui
doit sûrement être un smiley particulièrement obscène au Japon.
mal utilisé Flot qui convenait à la plupart de mes besoins et repose
sur JQuery - ce qui ne gâte rien. Cependant, je devais à chaque fois
me retaper à la main l'intégration de mes données générées et le
passage par deux ou trois niveaux d'abstraction pour un résultat.
Marrant à faire la première fois, et ça m'a permis de me mettre un peu
plus sérieusement à JQuery, mais effroyable à maintenir pour mes
successeurs. Dans ces cas, la notion de WebControl (hors ViewState et
événements que j'abhorre) permet de rester au bon niveau d'abstraction
et je persiste à penser que le databinding est une bonne chose. Je
suis d'accord pour trouver grotesque un <a runat="server" /> cela dit.
Quant aux tips pour éviter le tag soup que tu as référencé, je les
avais lus et j'étais resté assez dubitatif. Déjà, quoi qu'il arrive,
on ne se débarasse pas des <% } %> (en vérité je vous le dis, Python/
Boo ou #light sont vos amis) ensuite il repousse le problème sous le
tapis soit dans un renderpartial soit - horreur - en concaténant dans
une méthode des chaînes qui devraient appartenir à la vue. Et ses
méthodes ressemblent furieusement à ce qu'on pourrait trouver dans un
WebControl qui ferait du RenderContent plutôt que de la composition
(le côté css-friendly en moins, suffit de regarder l'exemple du
NumericPager dans l'article...). Retour à la case départ. C'est pour
ça que je préfère Spark qui annote sans intrusion les balises et
utilise la structure en arbre des tags comme squelette naturel pour
les structures de contrôles (au passage, l'inverse exact de (N)HAML,
fétichisme rubyesque).
En terme de satisfaction esthétique (autrement dit, en terme de
moindre saignage des yeux et d'acceptation sereine du markup) je
préfère Spark à toutes les variantes d'Aspview ou viewengine par
défaut. Je préfère même à ces derniers les bizarreries que je tentais
dans une vie antérieure comme utiliser Python comme moteur de script
ActiveX pour faire du ASP classique (pas .Net...)
Bizarrement, un <% End If %> VB.Net me choque moins que ce <% } %> qui
doit sûrement être un smiley particulièrement obscène au Japon.
Yann Schwartz
Mar 4, 2009, 5:06:56 AM3/4/09
to paris.alt.net
Tiens, je viens de tomber là-dessus :
http://weblogs.asp.net/leftslipper/archive/2009/03/03/asp-net-mvc-release-candidate-2-i-declare-myself-to-be-declarative.aspx
qui parle des, euh, "mvc controls", un machin dans aspnet mvc futures
et qui consiste à encapsuler les appels à des html helpers dans du
markup déclaratif. Back to square one.
http://weblogs.asp.net/leftslipper/archive/2009/03/03/asp-net-mvc-release-candidate-2-i-declare-myself-to-be-declarative.aspx
qui parle des, euh, "mvc controls", un machin dans aspnet mvc futures
et qui consiste à encapsuler les appels à des html helpers dans du
markup déclaratif. Back to square one.
Yann Schwartz
Mar 4, 2009, 6:09:36 AM3/4/09
to paris.alt.net
Désolé d'insister (et de répondre à mes messages), mais voici un bon
exemple de confusion délirante entre ce qui devrait être déclaratif et
ce qui devrait être impératif :
http://mvccontrib.codeplex.com/Wiki/View.aspx?title=Grid&referringTitle=Documentation
Il s'agit de la Grid dans MVC Contrib. L'usage de code n'ajoute
strictement rien (expressions et propriétés), c'est le triomphe de la
soupe aux balises et la lisibilité et la découvrabilité sont
catastrophiques. Franchement, <asp:gridview /> a l'air d'un top model
à côté de ce machin.
exemple de confusion délirante entre ce qui devrait être déclaratif et
ce qui devrait être impératif :
http://mvccontrib.codeplex.com/Wiki/View.aspx?title=Grid&referringTitle=Documentation
Il s'agit de la Grid dans MVC Contrib. L'usage de code n'ajoute
strictement rien (expressions et propriétés), c'est le triomphe de la
soupe aux balises et la lisibilité et la découvrabilité sont
catastrophiques. Franchement, <asp:gridview /> a l'air d'un top model
à côté de ce machin.
Vincent Bourdon
Mar 4, 2009, 7:36:12 AM3/4/09
to paris...@googlegroups.com
Absolument pas d'accord !!!!
la <asp:gridview /> néccéssite beaucoup de tag pour les template, plus du code <% %> pour le databing, plus du code behing toujours pour le databing.
Si on reprend un exemple de MVCContrib
pour l'équivalent en avec la asp:grid, ici y a moins de code, moins de fichier, c'est lisible, il y a peu de <% %>, c'est binder sur un objet, c'est découvrable grâce à l'intellisence de VS sur Html.
So what ?
2009/3/4 Yann Schwartz <abolib...@gmail.com>
Yann Schwartz
Mar 4, 2009, 10:06:44 AM3/4/09
to paris.alt.net
Oui mais ça se gâte franchement avec la pagination, etc.
Je tiens pas particulièrement au GridView asp.net, mais à son
abstraction et à son ancrage côté markup.
Ton code de rendu de grid, moi je l'écrirais comme ça :
<mvc:grid ViewModel="Person" />
Moins de code que dans ton exemple, moins de switch entre markup et
code, lisible.
Plus sérieusement :
* DRY et Convention over configuration : on affiche les propriétés du
ViewModel, pas du modèle. Ce qu'on passe à la vue ce sont les infos
utilisables par la vue, pas la totalité du modèle (ce qui est le
meilleur moyen pour éviter le tag soup). Pourquoi spécifier toujours
la même chose x => x.Prop si on veut afficher toutes les props ?
Pareil pour l'edit.
Au pire
<mvc:grid ViewModel="Person">
<mvc:autowire /> (1)
<mvc:column type="edit" /> (2)
</mvc:grid>
(1) CoC : on liste toutes les propriétés du ViewModel. Au pire
surchargeable par template (html, pas de lambdas et d'interfaces qui
n'ont de fluent que le nom : .For() ? .Do() ? pourquoi pas .Foo()
et .Bar() ?)
(2) CoC : on appelle l'action edit sur le contrôleur par défaut pour
le viewmodel, sinon on peut spécifier le contrôleur (mais pas
l'action, et pas avec en dur un href, à moins qu'on veuille tuer la
base au premier passage d'un googlebot). A priori le paramètre sera
toujours l'id, donc encore une fois CoC et pas besoin de préciser que
le param de chaîne de requête est p.Id.
On Mar 4, 1:36 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Absolument pas d'accord !!!!
> la <asp:gridview /> néccéssite beaucoup de tag pour les template, plus du
> code <% %> pour le databing, plus du code behing toujours pour le databing.
>
> Si on reprend un exemple de MVCContrib
>
> <%
> Html.Grid<Person>(
> "people",
> column => {
> column.For(p => p.Id);
> column.For(p => p.Name);
> column.For(p => p.Gender);
> column.For(p => p.RoleId);
> column.For("Edit").Do(p => { %>
> <td>
> <a href="/People/Edit/<%= p.Id %>">Edit</a>
> </td>
> %>});
> }
> );
> %>
>
> pour l'équivalent en avec la asp:grid, ici y a moins de code, moins de
> fichier, c'est lisible, il y a peu de <% %>, c'est binder sur un objet,
> c'est découvrable grâce à l'intellisence de VS sur Html.
>
> So what ?
>
> 2009/3/4 Yann Schwartz <abolibibe...@gmail.com>
Je tiens pas particulièrement au GridView asp.net, mais à son
abstraction et à son ancrage côté markup.
Ton code de rendu de grid, moi je l'écrirais comme ça :
<mvc:grid ViewModel="Person" />
Moins de code que dans ton exemple, moins de switch entre markup et
code, lisible.
Plus sérieusement :
* DRY et Convention over configuration : on affiche les propriétés du
ViewModel, pas du modèle. Ce qu'on passe à la vue ce sont les infos
utilisables par la vue, pas la totalité du modèle (ce qui est le
meilleur moyen pour éviter le tag soup). Pourquoi spécifier toujours
la même chose x => x.Prop si on veut afficher toutes les props ?
Pareil pour l'edit.
Au pire
<mvc:grid ViewModel="Person">
<mvc:autowire /> (1)
<mvc:column type="edit" /> (2)
</mvc:grid>
(1) CoC : on liste toutes les propriétés du ViewModel. Au pire
surchargeable par template (html, pas de lambdas et d'interfaces qui
n'ont de fluent que le nom : .For() ? .Do() ? pourquoi pas .Foo()
et .Bar() ?)
(2) CoC : on appelle l'action edit sur le contrôleur par défaut pour
le viewmodel, sinon on peut spécifier le contrôleur (mais pas
l'action, et pas avec en dur un href, à moins qu'on veuille tuer la
base au premier passage d'un googlebot). A priori le paramètre sera
toujours l'id, donc encore une fois CoC et pas besoin de préciser que
le param de chaîne de requête est p.Id.
On Mar 4, 1:36 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Absolument pas d'accord !!!!
> la <asp:gridview /> néccéssite beaucoup de tag pour les template, plus du
> code <% %> pour le databing, plus du code behing toujours pour le databing.
>
> Si on reprend un exemple de MVCContrib
>
> <%
> Html.Grid<Person>(
> "people",
> column => {
> column.For(p => p.Id);
> column.For(p => p.Name);
> column.For(p => p.Gender);
> column.For(p => p.RoleId);
> column.For("Edit").Do(p => { %>
> <td>
> <a href="/People/Edit/<%= p.Id %>">Edit</a>
> </td>
> %>});
> }
> );
> %>
>
> pour l'équivalent en avec la asp:grid, ici y a moins de code, moins de
> fichier, c'est lisible, il y a peu de <% %>, c'est binder sur un objet,
> c'est découvrable grâce à l'intellisence de VS sur Html.
>
> So what ?
>
>
>
>
> > Désolé d'insister (et de répondre à mes messages), mais voici un bon
> > exemple de confusion délirante entre ce qui devrait être déclaratif et
> > ce qui devrait être impératif :
>
> >http://mvccontrib.codeplex.com/Wiki/View.aspx?title=Grid&referringTit...
>
>
> > Désolé d'insister (et de répondre à mes messages), mais voici un bon
> > exemple de confusion délirante entre ce qui devrait être déclaratif et
> > ce qui devrait être impératif :
>
Vincent Bourdon
Mar 4, 2009, 2:34:19 PM3/4/09
to paris...@googlegroups.com
Oui et non
Oui pour CoC.
<mvc:grid ViewModel="Person">
<mvc:autowire /> (1)
<mvc:column type="edit" /> (2)
</mvc:grid>
<mvc:autowire /> (1)
<mvc:column type="edit" /> (2)
</mvc:grid>
ton exemple est intéressant, Ce qui me plait dans les helpers c'est la vérification syntaxique. Dans ton controle "Person" ne correspond a rien, c'est une string.
D'ailleurs quitte à faire de CoC si le ViewModel est typé on pourrait ne rien préciser.
Mais bon soyons réaliste, déjà les grids on ne les utilises pas tellement, et encore moins des grid avec toute les colonnes, donc au final tu auras plein de tag et il faudra définir les colonnes.
concernant le point (2), effectivement préciser le contrôleur et l'action devrait suffire, l'exemple de MVCContrib me surprend la dessus, ils écrivent même les <td> ... étrange.
Tu viens a la petite discussion le 12 ?
Gauthier Segay
Mar 4, 2009, 3:12:12 PM3/4/09
to paris.alt.net
de mon côté j'utilisais un [return:JsonReturnBinder] ou JsonSerializer
pour transformer mon résultat.
je n'ai eu à le faire qu'une paire de fois donc cela reste gérable,
mais il est surement possible de factoriser en fonction de ton besoin
pour que cela reste maintenable?
pour transformer mon résultat.
je n'ai eu à le faire qu'une paire de fois donc cela reste gérable,
mais il est surement possible de factoriser en fonction de ton besoin
pour que cela reste maintenable?
Gauthier Segay
Mar 4, 2009, 3:28:27 PM3/4/09
to paris.alt.net
Je vois que la discussion est animée :)
De mon côté, je n'ai jamais trouvé le gridview particulièrement adapté
à mes besoins (il se transformais + souvent en obstacle).
pour ton exemple, toujours en MonoRail, il existe un viewcomponent
Grid qui affiche effectivement toutes les propriétés ou une partie
seulement des items d'un enumerable, mais je ne crois pas qu'il
supporte le binding (j'ai d'ailleurs hate de voir le système
implémenté sous Aspectize web) pour la modification.
Quoi qu'il en soit le binding Form/Action est assez simple avec
MonoRail et je ne suis pas certain de voir l'avantage de ce contrôle
grid si ce n'est pour du scaffolding bête et méchant, dans les autres
cas je serais plus à l'aise pour customiser/maintenir qu'avec un
contrôle spécifique asp.net.
AMHA, les conventions du web font qu'il est plus compréhensible de
voir <table> etc, que <proprietary:tagsoup ruine_le="server"/>, les
composants sont a utiliser lorsque cela est adapté (datepicker,
checklist etc.):
- quand il est nécéssaire d'encapsuler du code html/css/js dans
quelquechose de réutilisable
- que ce quelquechose ne risque pas de devoir se contortionner de 1000
façons pour répondre à mon besoin.
- que l'on pris le temps au préalable de développer ou d'apprendre ce
contrôle pour ne pas être bloqué sur un projet.
sur les exemples proposés, pour l'instant je reste avec mon foreach et
mes balises ;)
On Mar 4, 8:34 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Oui et non
>
> Oui pour CoC.
>
> <mvc:grid ViewModel="Person">
> <mvc:autowire /> (1)
> <mvc:column type="edit" /> (2)
> </mvc:grid>
> ton exemple est intéressant, Ce qui me plait dans les helpers c'est la
> vérification syntaxique. Dans ton controle "Person" ne correspond a rien,
> c'est une string.
> D'ailleurs quitte à faire de CoC si le ViewModel est typé on pourrait ne
> rien préciser.
> Mais bon soyons réaliste, déjà les grids on ne les utilises pas tellement,
> et encore moins des grid avec toute les colonnes, donc au final tu auras
> plein de tag et il faudra définir les colonnes.
>
> concernant le point (2), effectivement préciser le contrôleur et l'action
> devrait suffire, l'exemple de MVCContrib me surprend la dessus, ils écrivent
> même les <td> ... étrange.
>
> Tu viens a la petite discussion le 12 ?
>
> 2009/3/4 Yann Schwartz <abolibibe...@gmail.com>
De mon côté, je n'ai jamais trouvé le gridview particulièrement adapté
à mes besoins (il se transformais + souvent en obstacle).
pour ton exemple, toujours en MonoRail, il existe un viewcomponent
Grid qui affiche effectivement toutes les propriétés ou une partie
seulement des items d'un enumerable, mais je ne crois pas qu'il
supporte le binding (j'ai d'ailleurs hate de voir le système
implémenté sous Aspectize web) pour la modification.
Quoi qu'il en soit le binding Form/Action est assez simple avec
MonoRail et je ne suis pas certain de voir l'avantage de ce contrôle
grid si ce n'est pour du scaffolding bête et méchant, dans les autres
cas je serais plus à l'aise pour customiser/maintenir qu'avec un
contrôle spécifique asp.net.
AMHA, les conventions du web font qu'il est plus compréhensible de
voir <table> etc, que <proprietary:tagsoup ruine_le="server"/>, les
composants sont a utiliser lorsque cela est adapté (datepicker,
checklist etc.):
- quand il est nécéssaire d'encapsuler du code html/css/js dans
quelquechose de réutilisable
- que ce quelquechose ne risque pas de devoir se contortionner de 1000
façons pour répondre à mon besoin.
- que l'on pris le temps au préalable de développer ou d'apprendre ce
contrôle pour ne pas être bloqué sur un projet.
sur les exemples proposés, pour l'instant je reste avec mon foreach et
mes balises ;)
On Mar 4, 8:34 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Oui et non
>
> Oui pour CoC.
>
> <mvc:grid ViewModel="Person">
> <mvc:autowire /> (1)
> <mvc:column type="edit" /> (2)
> </mvc:grid>
> ton exemple est intéressant, Ce qui me plait dans les helpers c'est la
> vérification syntaxique. Dans ton controle "Person" ne correspond a rien,
> c'est une string.
> D'ailleurs quitte à faire de CoC si le ViewModel est typé on pourrait ne
> rien préciser.
> Mais bon soyons réaliste, déjà les grids on ne les utilises pas tellement,
> et encore moins des grid avec toute les colonnes, donc au final tu auras
> plein de tag et il faudra définir les colonnes.
>
> concernant le point (2), effectivement préciser le contrôleur et l'action
> devrait suffire, l'exemple de MVCContrib me surprend la dessus, ils écrivent
> même les <td> ... étrange.
>
> Tu viens a la petite discussion le 12 ?
>
Yann Schwartz
Mar 4, 2009, 7:42:46 PM3/4/09
to paris.alt.net
@Vincent.
Oui en fait je fais à moitié semblant de pas être d'accord. A moitié.
Généralement on a besoin d'une grid dans un coin, pour du scaffolding
ou un peu mieux et devoir table-tr-td à chaque fois est pénible.
Encore plus pénibles les controles qui mettent en dur les attributs de
style ou oublient qu'on peut vouloir un thead. Mais dans une logique
DRY, je préfère que le markup indique la boucle ou le test (de toute
façon elle apparaîtra la balise, que ce soit une balise html ou une
balise spécifique). C'est pour ça que j'aime spark (ou que je concède
en maugréant de l'intérêt à HAML). En asp.net je me retrouvais à la
fin avec un repeater. Mon mockup de code c'était pour imaginer ce que
j'aimerais avoir, dans l'idéal, et je ne suis pas spécialement fan des
chaînes magiques. Mais quand je vois les exemples du grid mvc contrib
ou pire des posts qui proposent des scripts T4 pour en générer, je
ressens un certain malaise.
Pour le 12, j'aimerais bien, mais je donne un cours le lendemain et,
me connaissant, je pense que je l'aurai pas préparé d'ici là.
J'essaierai de venir.
@Gauthier
A l'époque j'avais besoin de faire un dashboard pour décideur. Plein
de graphes différents (pie-charts, etc.) et des jolies images. Flot
convenait à 90% de mes besoins, manquait les autres 10%, qui auraient
été couverts par le contrôle de graphes (qui n'existait pas à l'époque
de toute façon). Je n'avais pas particulièrement envie de passer du
temps à en écrire un proprement et parfois le côté fire and forget des
contrôles a du bon. Je pense aussi à l'aspect psychologique des choses
quand tu essayes de vendre MVC à des webformeurs. L'architecture est
plutôt facile à vendre et pas monstrueuse à expliquer, mais c'est un
peu plus dur de remporter l'adhésion sur les vues. Dire qu'on peut
réutiliser certains contrôles console un peu. Et le code devient
nettement plus baroque avec du VB.Net (qui du coup se prêterait
pourtant plus à du templating), quand il n'est tout simplement pas
supporté (les lambda VB sont des vrais lambda, c'est à dire de pures
expressions. Les bibliothèques open source étaient carrément tragiques
quand on était en .Net 2.0 sans délégués anonymes en VB). A propos de
VB, j'ai vu passer un view engine assez marrant qui utilisait les XML
literals VB pour créer le markup des vues. Plutôt rigolo. Et pour une
fois, la discrimination se faisait dans l'autre sens.
On Mar 4, 8:34 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Oui et non
>
> Oui pour CoC.
>
> <mvc:grid ViewModel="Person">
> <mvc:autowire /> (1)
> <mvc:column type="edit" /> (2)
> </mvc:grid>
> ton exemple est intéressant, Ce qui me plait dans les helpers c'est la
> vérification syntaxique. Dans ton controle "Person" ne correspond a rien,
> c'est une string.
> D'ailleurs quitte à faire de CoC si le ViewModel est typé on pourrait ne
> rien préciser.
> Mais bon soyons réaliste, déjà les grids on ne les utilises pas tellement,
> et encore moins des grid avec toute les colonnes, donc au final tu auras
> plein de tag et il faudra définir les colonnes.
>
> concernant le point (2), effectivement préciser le contrôleur et l'action
> devrait suffire, l'exemple de MVCContrib me surprend la dessus, ils écrivent
> même les <td> ... étrange.
>
> Tu viens a la petite discussion le 12 ?
>
> 2009/3/4 Yann Schwartz <abolibibe...@gmail.com>
Oui en fait je fais à moitié semblant de pas être d'accord. A moitié.
Généralement on a besoin d'une grid dans un coin, pour du scaffolding
ou un peu mieux et devoir table-tr-td à chaque fois est pénible.
Encore plus pénibles les controles qui mettent en dur les attributs de
style ou oublient qu'on peut vouloir un thead. Mais dans une logique
DRY, je préfère que le markup indique la boucle ou le test (de toute
façon elle apparaîtra la balise, que ce soit une balise html ou une
balise spécifique). C'est pour ça que j'aime spark (ou que je concède
en maugréant de l'intérêt à HAML). En asp.net je me retrouvais à la
fin avec un repeater. Mon mockup de code c'était pour imaginer ce que
j'aimerais avoir, dans l'idéal, et je ne suis pas spécialement fan des
chaînes magiques. Mais quand je vois les exemples du grid mvc contrib
ou pire des posts qui proposent des scripts T4 pour en générer, je
ressens un certain malaise.
Pour le 12, j'aimerais bien, mais je donne un cours le lendemain et,
me connaissant, je pense que je l'aurai pas préparé d'ici là.
J'essaierai de venir.
@Gauthier
A l'époque j'avais besoin de faire un dashboard pour décideur. Plein
de graphes différents (pie-charts, etc.) et des jolies images. Flot
convenait à 90% de mes besoins, manquait les autres 10%, qui auraient
été couverts par le contrôle de graphes (qui n'existait pas à l'époque
de toute façon). Je n'avais pas particulièrement envie de passer du
temps à en écrire un proprement et parfois le côté fire and forget des
contrôles a du bon. Je pense aussi à l'aspect psychologique des choses
quand tu essayes de vendre MVC à des webformeurs. L'architecture est
plutôt facile à vendre et pas monstrueuse à expliquer, mais c'est un
peu plus dur de remporter l'adhésion sur les vues. Dire qu'on peut
réutiliser certains contrôles console un peu. Et le code devient
nettement plus baroque avec du VB.Net (qui du coup se prêterait
pourtant plus à du templating), quand il n'est tout simplement pas
supporté (les lambda VB sont des vrais lambda, c'est à dire de pures
expressions. Les bibliothèques open source étaient carrément tragiques
quand on était en .Net 2.0 sans délégués anonymes en VB). A propos de
VB, j'ai vu passer un view engine assez marrant qui utilisait les XML
literals VB pour créer le markup des vues. Plutôt rigolo. Et pour une
fois, la discrimination se faisait dans l'autre sens.
On Mar 4, 8:34 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Oui et non
>
> Oui pour CoC.
>
> <mvc:grid ViewModel="Person">
> <mvc:autowire /> (1)
> <mvc:column type="edit" /> (2)
> </mvc:grid>
> ton exemple est intéressant, Ce qui me plait dans les helpers c'est la
> vérification syntaxique. Dans ton controle "Person" ne correspond a rien,
> c'est une string.
> D'ailleurs quitte à faire de CoC si le ViewModel est typé on pourrait ne
> rien préciser.
> Mais bon soyons réaliste, déjà les grids on ne les utilises pas tellement,
> et encore moins des grid avec toute les colonnes, donc au final tu auras
> plein de tag et il faudra définir les colonnes.
>
> concernant le point (2), effectivement préciser le contrôleur et l'action
> devrait suffire, l'exemple de MVCContrib me surprend la dessus, ils écrivent
> même les <td> ... étrange.
>
> Tu viens a la petite discussion le 12 ?
>
Rui
Mar 5, 2009, 4:10:40 AM3/5/09
to paris.alt.net
@Yann,
je suis tout à fait d'accord avec les points que tu soulèves sur les
avantages/inconvénients des WebControls. D'une manière plus générale,
je dirais que les webcontrols sont trop mappés dans leur manière de
faire et leur processus sur les controls winforms et finalement peu
adaptés au web. L'utilisation que l'on fait en général du modèle mvc
me semble de loin beaucoup plus adaptée au web et à une intégration
avec le design.
Je te rejoint aussi un peu sur les Helpers html.Néanmoins, je trouve
que d'une manière générale l'intellisense de visual est suffisante
pour comprendre l'utilisation du helper et puis la plus part du temps
il y a les sources. De plus je trouve très pratique des types anonymes
en entrée de helper car cela laisse une grande souplesse de syntaxe et
c'est très pratique au final. Même si on critiquait beaucoup il y a
quelques années javascript parce que l'on pouvait faire un peu tout et
n'importe quoi on se rend compte aujourd'hui que si ont fait les
choses proprement cela apporte une agilité que l'on ne retrouve pas
ailleurs. C'est un peu cette impression que j'ai quand j'utilise des
helpers avec des anonymes en entrée.
Quoi qu'il en soit, il est vrai que j'utilise les helpers html de
manière assez simple finalement pour réaliser un rendu html et déporte
une bonne partie de la logique d'affichage dans jQuery qui est
extremement sexy pour cela et du coup la notion même de webcontrol ne
me manque absolument pas. De même pour ta question initiale sur les
viewengines. La syntaxe aspview n'est pas la plus sexy, mais elle est
suffisament pratique et claire pour un rendu simple.
Je pense qu'il manque des choses dans le view engine par défaut et
d'autres qu'il faudrait réorganiser mais il faut quand même
reconnaître qu'il s'agit là d'une première version déja à mon gout
beaucoup plus sympa que les webforms et qu'elle se bonifiera avec le
temps
je suis tout à fait d'accord avec les points que tu soulèves sur les
avantages/inconvénients des WebControls. D'une manière plus générale,
je dirais que les webcontrols sont trop mappés dans leur manière de
faire et leur processus sur les controls winforms et finalement peu
adaptés au web. L'utilisation que l'on fait en général du modèle mvc
me semble de loin beaucoup plus adaptée au web et à une intégration
avec le design.
Je te rejoint aussi un peu sur les Helpers html.Néanmoins, je trouve
que d'une manière générale l'intellisense de visual est suffisante
pour comprendre l'utilisation du helper et puis la plus part du temps
il y a les sources. De plus je trouve très pratique des types anonymes
en entrée de helper car cela laisse une grande souplesse de syntaxe et
c'est très pratique au final. Même si on critiquait beaucoup il y a
quelques années javascript parce que l'on pouvait faire un peu tout et
n'importe quoi on se rend compte aujourd'hui que si ont fait les
choses proprement cela apporte une agilité que l'on ne retrouve pas
ailleurs. C'est un peu cette impression que j'ai quand j'utilise des
helpers avec des anonymes en entrée.
Quoi qu'il en soit, il est vrai que j'utilise les helpers html de
manière assez simple finalement pour réaliser un rendu html et déporte
une bonne partie de la logique d'affichage dans jQuery qui est
extremement sexy pour cela et du coup la notion même de webcontrol ne
me manque absolument pas. De même pour ta question initiale sur les
viewengines. La syntaxe aspview n'est pas la plus sexy, mais elle est
suffisament pratique et claire pour un rendu simple.
Je pense qu'il manque des choses dans le view engine par défaut et
d'autres qu'il faudrait réorganiser mais il faut quand même
reconnaître qu'il s'agit là d'une première version déja à mon gout
beaucoup plus sympa que les webforms et qu'elle se bonifiera avec le
temps
Mathias
Mar 6, 2009, 4:43:08 PM3/6/09
to paris.alt.net
hehe, je vois que le débat est le même partout...
Pas plus tard qu'aujourd'hui, mon collègue sur mon projet .Net était
effrayé à l'idée de faire du Javascript, et préfère utiliser des
balises <asp> plutôt que du pure HTML+Javascript.
Sérieusement, je n'ai JAMAIS utilisé la gridview d'ASP, car absolument
pas adapté à mes besoins. Je me tourne toujours faire une solution
HTML avec des foreach (ou repeater).
Je suis contre le fait de mélanger des langages dans un même source
(vive le PHP+HTML+JAVASCRIPT+SQL) mais je préfère maitriser mon HTML.
Pour la petite infos : j'ai passé encore 3 jours à me faire chier avec
le Calendar Ajax de .Net (qui bug à mort). Et j'ai déjà passé beaucoup
de temps pour remplacer mes UpdatePanel merdique (surtout en terme de
perfs) par du pure Javascript+WS Rest.
J'ai l'impression qu'il n'y a pas de solution miracle, car de toute
manière même en MVC, on mélange les langages. Mais je trouve le
mécanisme en MVC plus facile, moins verbeux et plus agréable à lire.
Bref, moi je kiff Html.MethodeDExtension() :)
Pas plus tard qu'aujourd'hui, mon collègue sur mon projet .Net était
effrayé à l'idée de faire du Javascript, et préfère utiliser des
balises <asp> plutôt que du pure HTML+Javascript.
Sérieusement, je n'ai JAMAIS utilisé la gridview d'ASP, car absolument
pas adapté à mes besoins. Je me tourne toujours faire une solution
HTML avec des foreach (ou repeater).
Je suis contre le fait de mélanger des langages dans un même source
(vive le PHP+HTML+JAVASCRIPT+SQL) mais je préfère maitriser mon HTML.
Pour la petite infos : j'ai passé encore 3 jours à me faire chier avec
le Calendar Ajax de .Net (qui bug à mort). Et j'ai déjà passé beaucoup
de temps pour remplacer mes UpdatePanel merdique (surtout en terme de
perfs) par du pure Javascript+WS Rest.
J'ai l'impression qu'il n'y a pas de solution miracle, car de toute
manière même en MVC, on mélange les langages. Mais je trouve le
mécanisme en MVC plus facile, moins verbeux et plus agréable à lire.
Bref, moi je kiff Html.MethodeDExtension() :)
Gauthier Segay
Mar 6, 2009, 6:20:24 PM3/6/09
to paris...@googlegroups.com
je rebondi juste sur une expérience assez désastreuse sur un projet
monté qui fut monté d'update panel et des refresh auto (toute 5sec
env) sur des grosses listes de données, faire du javascript avec des
balises ruinat server c'est vraiment pas pratique à ce que j'y ai vu :
monté qui fut monté d'update panel et des refresh auto (toute 5sec
env) sur des grosses listes de données, faire du javascript avec des
balises ruinat server c'est vraiment pas pratique à ce que j'y ai vu :
- viewstate de + 10aines de ko envoyé au serveur
- réponse immense par rapport au flux de donnée nécéssaire (plusieurs
bonnes 10aines de ko aussi au lieu d'un objet js)
faire un site public avec les webforms + form runatserver de cette
manière c'est effectivement loin d'être facile
à mon sens dans le code des vues (j'entends même avec MVC) il est
difficile de répondre aux besoins dans un délai court sans:
- sacrifier la lisibilité (conditions/parametres + html beverage)
- ne pas passer par trop de composants et qu'ils ne soient pas trop compliqués
- être débrouillard en js, css, html
- implémenter le statefull d'une page avec ajax (si c'est
"nécéssaire") plutôt que viewstate/session et autres horreurs, (ici
aussi on peut même faire du MVC "riche")
-> composition/kiss
ou bien
- connaitre par coeur la documentation infragistics + radcontrol +
telerik (plusieurs étagères je pense)
- overrider comme un fou ces controles aux sombres api
- lier le binding dto <-> présentation à coup de table.AddRow(new
HtmlRow()) ou Decimal.Parse(cell.FindControl("ballba") as TextBox)
dans du codebehind couplé à mort
- je vous laisse improviser la suite
-> héritage/complexité
dans ce contexte, ça fait longtemps que j'ai choisi mon camp, je ne
pense pas qu'il faille "vendre" MVC aux webformeurs réticents:
expliquer, démontrer oui mais pas "convertir" les webforms asp.net (et
jsf web java) restent des frameworks "over enginerés" pour lire et
écrire sur un flux http
bien entendu quand on a le temps de se faire des jolies librairies ça
peut rendre la vie meilleure de part et d'autre mais il est difficile
de capitaliser plus qu'une petite partie d'une
expérience/fonctionnalités sur des projets toujours shorts...
si il y'a un consensus sur les HtmlHelper et choses du genre,
j'aimerais que ces outils soient le plus framework agnostic possible,
voir issus d'une API existante, portables (java, php, js, ruby...).
force est de constater qu'il y'a de l'inventivité qui naît face aux
frustrations ;)
2009/3/6 Mathias <mathia...@gmail.com>:
Vincent Bourdon
Mar 9, 2009, 7:37:05 AM3/9/09
to paris...@googlegroups.com
C'est marrant c'est un sujet qui à fait l'objet d'une réunion chez Alt.net Seattle ;)
Perso, je n'ai pas eu le courage de regarder les vidéos, c'est des screeners :(
Vincent Bourdon
Mar 9, 2009, 12:35:59 PM3/9/09
to paris...@googlegroups.com
Une petite citation histoire de ranimer cette discussion jusqu'à Jeudi :
Stephen Walther :
In the ASP.NET MVC world, HTML helpers are the equivalent of ASP.NET Web Form controls. Like a web form control, an HTML helper enables you to encapsulate the rendering of HTML. However, unlike a Web Form control, HTML helpers are extremely lightweight. For example, an HTML helper does not have an event model and does not use view state.
@+ Vincent
2009/3/9 Vincent Bourdon <evil...@gmail.com>
Yann Schwartz
Mar 9, 2009, 2:00:46 PM3/9/09
to paris.alt.net
Oui on est d'accord, mais un html helper a une sémantique d'appel de
méthode, avec des paramètres non nommés. La mêle encapsulation
déclarative avec des paires nom/valeur (dans du markup, au hasard) est
plus lisible et marque mieux l'intention (je pense particulièrement
aux helpers qui encapsulent un lien ou une form).
Comparons
<% HtmlHelper.Foo("grobeulz", DateTime.Now) %>
ou, pour que ce soit un peu plus lisible (sans intellisense hein)
<% HtmlHelper.Foo(new FooParam{ Action = "grobeulz",
Gizmo=DateTime.Now}) %>
on peut aussi utiliser des lambdas, tout ça, mais dans ce cas,
comparons avec
<mvc:foo
action="grobeulz"
gizmo="${DateTime.Now}" />
mais c'est du bruit
On Mar 9, 5:35 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Une petite citation histoire de ranimer cette discussion jusqu'à Jeudi :
> Stephen Walther :
>
> I*n the ASP.NET MVC world, HTML helpers are the equivalent of ASP.NET Web
>
> @+ Vincent
>
> 2009/3/9 Vincent Bourdon <evilz...@gmail.com>
> >> 2009/3/6 Mathias <mathias.kl...@gmail.com>:
> ...
>
> read more »
méthode, avec des paramètres non nommés. La mêle encapsulation
déclarative avec des paires nom/valeur (dans du markup, au hasard) est
plus lisible et marque mieux l'intention (je pense particulièrement
aux helpers qui encapsulent un lien ou une form).
Comparons
<% HtmlHelper.Foo("grobeulz", DateTime.Now) %>
ou, pour que ce soit un peu plus lisible (sans intellisense hein)
<% HtmlHelper.Foo(new FooParam{ Action = "grobeulz",
Gizmo=DateTime.Now}) %>
on peut aussi utiliser des lambdas, tout ça, mais dans ce cas,
comparons avec
<mvc:foo
action="grobeulz"
gizmo="${DateTime.Now}" />
mais c'est du bruit
On Mar 9, 5:35 pm, Vincent Bourdon <evilz...@gmail.com> wrote:
> Une petite citation histoire de ranimer cette discussion jusqu'à Jeudi :
> Stephen Walther :
>
> Form controls. Like a web form control, an HTML helper enables you to
> encapsulate the rendering of HTML. However, unlike a Web Form control, HTML
> helpers are extremely lightweight. For example, an HTML helper does not have
> an event model and does not use view state.
>
> *
> encapsulate the rendering of HTML. However, unlike a Web Form control, HTML
> helpers are extremely lightweight. For example, an HTML helper does not have
> an event model and does not use view state.
>
>
> @+ Vincent
>
> 2009/3/9 Vincent Bourdon <evilz...@gmail.com>
>
> > C'est marrant c'est un sujet qui à fait l'objet d'une réunion chez Alt.net
> > Seattle ;)
> >http://whereslou.com/2009/03/08/spark-in-the-field-altnet-seattle
>
> > Perso, je n'ai pas eu le courage de regarder les vidéos, c'est des
> > screeners :(
>
> > 2009/3/7 Gauthier Segay <gauthier.se...@gmail.com>
> > C'est marrant c'est un sujet qui à fait l'objet d'une réunion chez Alt.net
> > Seattle ;)
> >http://whereslou.com/2009/03/08/spark-in-the-field-altnet-seattle
>
> > Perso, je n'ai pas eu le courage de regarder les vidéos, c'est des
> > screeners :(
>
>
> read more »
Yann Schwartz
Mar 9, 2009, 2:05:39 PM3/9/09
to paris.alt.net
Oups, mon message précédent parti tout seul. Il ne faut pas faire du
fétichisme, en sautant sur le syllogisme balise = webcontrol = berk.
Je le répète, je ne veux pas d'événements dans le web control, ni de
view state, je parle juste de l'encapsulation et de tenter d'éviter la
soupe alphanuméricosymbolique du view engine par défaut. Les templates
de django (ou spark, j'insiste hein) sont plus agréables à l'oeil et
moins intrusifs. Avec le view engine à la asp on change sans arrêt de
contexte au détriment de la lisibilité et de la robustesse (je le mets
où mon <% } %> ?). Dire qu'il suffit de compiler la vue pour trouver
ses erreurs est un peu léger quand on n'arrive pas à discerner en un
coup d'oeil la structure sur une vue un peu complexe.
> ...
>
> read more »
fétichisme, en sautant sur le syllogisme balise = webcontrol = berk.
Je le répète, je ne veux pas d'événements dans le web control, ni de
view state, je parle juste de l'encapsulation et de tenter d'éviter la
soupe alphanuméricosymbolique du view engine par défaut. Les templates
de django (ou spark, j'insiste hein) sont plus agréables à l'oeil et
moins intrusifs. Avec le view engine à la asp on change sans arrêt de
contexte au détriment de la lisibilité et de la robustesse (je le mets
où mon <% } %> ?). Dire qu'il suffit de compiler la vue pour trouver
ses erreurs est un peu léger quand on n'arrive pas à discerner en un
coup d'oeil la structure sur une vue un peu complexe.
>
> read more »
Gauthier Segay
Mar 9, 2009, 2:31:00 PM3/9/09
to paris...@googlegroups.com
Le débat ne revient-il pas à dire que le framework MSMVC manque d'une
fonctionnalité:
fonctionnalité:
- le support déclaratif des contrôles serveurs dans les autres
viewengine que webform
ou
- le support déclaratif de viewcomponents ala monorail (qui est le
palliatif à ce problème chez MR: les viewcomponents sont viewengine
agnostics et ne sont pas lié à System.Web.UI.Control)
?
2009/3/9 Yann Schwartz <abolib...@gmail.com>:
Yann Schwartz
Mar 9, 2009, 3:04:28 PM3/9/09
to paris.alt.net
On Mar 9, 7:31 pm, Gauthier Segay <gauthier.se...@gmail.com> wrote:
> Le débat ne revient-il pas à dire que le framework MSMVC manque d'une
> fonctionnalité:
>
> - le support déclaratif des contrôles serveurs dans les autres
> viewengine que webform
asp.net ne sont pas utilisables sans viewstate ou évenements.
> ou
> - le support déclaratif de viewcomponents ala monorail (qui est le
> palliatif à ce problème chez MR: les viewcomponents sont viewengine
> agnostics et ne sont pas lié à System.Web.UI.Control)
>
viewcomponents sans trop pousser le sujet (et plus généralement la
documentation de Castle et son statut Trunk only depuis plus d'un an
avaient fini par me décourager).
Reply all
Reply to author
Forward
0 new messages