Ça peut paraître rétrograde, mais pour moi un site ouaibe doit être consultable avec un brouteur graphique comme avec un brouteur texte (links power :), ne doit pas mettre 10 secondes pour charger chaque page, doit être rapide et léger.
Ce n'est pas du tout rétrograde, bien au contraire, cela correspond à une architecture moderne, saine et évolutive. Microsoft nous a fait croire (car c'était das son interêt) que l'interface utilisateur doit être très fortement "couplée" avec le programme, ce qui rend difficile toute migration vers d'autres systèmes, avec pour effet secondaire de rendre son développement singulièrement compliqué.
Dans une architecture moderne dite (MVC : http://en.wikipedia.org/wiki/Model-view-controller,(...) ou trois-tiers par exemple, pour utiliser des mots à la mode, mais ce n'est pas le propos), l'interface utilisteur doit être conçue comme un module comme les autres. Il doit être en particulier facile de tester l'ensemble des fonctionnalités "indépendemment" de cette interface, en mode ligne de commande en particulier, pour pouvoir la scripter, l'automatiser, refaire facilement les tests, utiliser des technique venant de l'extreme programming, (refactoring, test driven development, etc) (ou sa théorie préferée). Rien n'est plus difficile à automatiser qu'une interface graphique.
20 ans d'expérience en informatique, m'ont appris que l'interface utilisateur était la partie la plus difficile, la plus complexe à développer et à tester. Je pense qu'il est plus simple de la concevoir comme sorte "d'outil d'impresion" des fonctionnalités du programme, c'est le programme qui doit conduire l'interface utilisateur et non l'inverse comme le préconise Microsoft.
Une telle architecture rend les applications plus simples à développer et à migrer vers d'autres architecture. On veut imprimer sur quelque chose qui comprend XUL eh bien on réecrit l'interface pour parler XUL, on veut "imprimer" en PDF on la réecrit en PDF, on veut imprimer en "GTK" ou "QT" idem. Moins l'interface sera couplée au programme, plus elle sera facile à réecrire ou à adapter. On peut même envisager une sorte de code intérmédiaire pour les grosses applications.
Pour revenir à ton propos, on lira avec profit ce lien http://www.w3.org/2002/mmi/2002/MM-Arch-Maes-20010820.pdf(...) qui applique ce principe au browser, il parle d'un browser multi-modal, un site doit être conçu pour s'adapter au browser : PC, mais aussi mobile phone, PDA, ou même vocal. L'application doit être capable de présenter le bon HTML ou autre code (style VoiceXML) en fonction du browser qui consulte. Bie sûr c'est une vue théorique qui n'est peut être pas facile à appliquer toujours, mais c'est une architecture qu'on doit avoir à l'esprit et dont on doit se rapprocher le plus possible.
[^] # Architecture MVC et trois tiers
Posté par khalid . En réponse à la dépêche OpenLaszlo : un concurrent libre pour Macromedia Flex.. Évalué à 2.
Ce n'est pas du tout rétrograde, bien au contraire, cela correspond à une architecture moderne, saine et évolutive. Microsoft nous a fait croire (car c'était das son interêt) que l'interface utilisateur doit être très fortement "couplée" avec le programme, ce qui rend difficile toute migration vers d'autres systèmes, avec pour effet secondaire de rendre son développement singulièrement compliqué.
Dans une architecture moderne dite (MVC : http://en.wikipedia.org/wiki/Model-view-controller,(...) ou trois-tiers par exemple, pour utiliser des mots à la mode, mais ce n'est pas le propos), l'interface utilisteur doit être conçue comme un module comme les autres. Il doit être en particulier facile de tester l'ensemble des fonctionnalités "indépendemment" de cette interface, en mode ligne de commande en particulier, pour pouvoir la scripter, l'automatiser, refaire facilement les tests, utiliser des technique venant de l'extreme programming, (refactoring, test driven development, etc) (ou sa théorie préferée). Rien n'est plus difficile à automatiser qu'une interface graphique.
20 ans d'expérience en informatique, m'ont appris que l'interface utilisateur était la partie la plus difficile, la plus complexe à développer et à tester. Je pense qu'il est plus simple de la concevoir comme sorte "d'outil d'impresion" des fonctionnalités du programme, c'est le programme qui doit conduire l'interface utilisateur et non l'inverse comme le préconise Microsoft.
Une telle architecture rend les applications plus simples à développer et à migrer vers d'autres architecture. On veut imprimer sur quelque chose qui comprend XUL eh bien on réecrit l'interface pour parler XUL, on veut "imprimer" en PDF on la réecrit en PDF, on veut imprimer en "GTK" ou "QT" idem. Moins l'interface sera couplée au programme, plus elle sera facile à réecrire ou à adapter. On peut même envisager une sorte de code intérmédiaire pour les grosses applications.
Pour revenir à ton propos, on lira avec profit ce lien http://www.w3.org/2002/mmi/2002/MM-Arch-Maes-20010820.pdf(...) qui applique ce principe au browser, il parle d'un browser multi-modal, un site doit être conçu pour s'adapter au browser : PC, mais aussi mobile phone, PDA, ou même vocal. L'application doit être capable de présenter le bon HTML ou autre code (style VoiceXML) en fonction du browser qui consulte. Bie sûr c'est une vue théorique qui n'est peut être pas facile à appliquer toujours, mais c'est une architecture qu'on doit avoir à l'esprit et dont on doit se rapprocher le plus possible.