Citation:
Envoyé par
fcharton
Je ne suis pas très futé, mais je l'avais quand même lu...
Je ne voulais absolument pas sous entendre que tu n'étais pas futé...
Si telle est l'impression que j'ai donnée, je t'en fais toutes mes excuses les plus sincères ;)
Citation:
Tous les frameworks actuels, quels qu'ils soient, permettent des skins (sous différentes formes), qui font que, si on a un graphiste, on peut facilement améliorer l'interface (enfin, si le développeur est au courant de cette possibilité et l'a déjà prise en compte).
Peut-être ne vais-je raler que sur la manière dont c'est abordé par l'existant, mais, quand on voit les RAD existant, on se rend compte que tout est systématiquement accessibles à tous:
Les propriétés propres à la seule apparence d'un élément visuelles côtoient allègrement les attributs purement fonctionnels (comme la possibilité de changer ou non la valeur d'un champs), quand il n'est pas possible (eg comme sous borland) d'aller "titiller" directement les événement auxquels l'élément doit réagir.
Et, bien souvent, la création d'un widget personnalisé passe par... la programmation pure et simple: si on veut créer une data grille perso, il faut... se taper du code C++ pour tout (ou peu s'en faut).
Citation:
Un nouveau framework doit permettre cela, mais ce n'est pas innovant. Ce qui le serait davantage, ce serait de permettre au développeur de faire joli (à partir de modeles prédéfinis et facilement modifiables et réutilisables) à partir d'une bête charte graphique, et sans graphiste.
d'accord, mais qu'est-ce qui empêcherait, justement, que ce soit un graphiste (ou n'importe qui "pas trop maladroit en dessin") qui propose ces modèles prédéfinis :question:
Si "n'importe qui" peut sauvegarder l'apparence d'un objet visuel, dans un format donné éventuellement généré par ailleurs), son utilisation peut être aussi simple que d'utiliser un menu "nouveau->selon modèle"...
Citation:
Plus généralement, le problème que je vois à cette approche, c'est l'idée qu'on peut joliment séparer données et traitements (cf la discussion sur les callbacks), que du moment qu'on a une approche déclarative, alors tout devient paramétrable (ben voyons), et que la "vue d'artiste" peut s'intégrer sans douleur dans un framework, sans qu'il y ait de trade offs avec la "développabilité" de celui ci, ou ses performances.
Le fait de croire que la séparation des différents aspects permet de tout résoudre et de lever toutes les limites s'apparente très certainement à une utopie, je te l'accorde.
Par contre, si l'on arrive à appliquer une séparation claire et maximale entre les différents éléments, nous pouvons arriver à lever un nombre important de restrictions.
La plupart du temps, les restrictions qui ne sont pas dues au matériel utilisées sont beaucoup plus dues aux dépendances dont souffre un aspect donné qu'à l'aspect lui-même.
Limitons les dépendances entre les trois aspects, nous lèverons de facto une bonne partie des restrictions dans chacun d'eux ;)
Citation:
L'idée que tout est séparable ne survit jamais longtemps à la réalité,
C'est pourtant l'un des principes récurrent de la programmation, quel que soit le côté d'où l'on regarde, c'est toujours du "diviser pour mieux régner" :D
Citation:
- soit parce certaines choses, veut veut pas, sont malgré tout liées (eg le moteur de rendu agnostique... tôt ou tard on bute sur les primitives de l'OS, ou le système d'entrée qui a "tout prévu"),
Il y a, effectivement, certaines limites insurmontables: vouloir créer un élément affichable en 3D alors que le moteur de rendu ne fonctionne qu'en 2D parrait... irréalisable :P
C'est la raison pour laquelle il me semble important de prévoir, à terme, la possibilité de la mise au point d'autres moteurs de rendus ou d'autres système d'entrées...
Tu auras, fatalement, des modèles qui ne pourront pas fonctionner avec un moteur donné, mais il "suffira" de brancher l'autre.
Cela pourrait simplement passer par l'utilisation d'une bibliothèque partagée différente ;)
Citation:
- soit parce que le cout de cette séparation, en terme d'accroissement de la complexité du framework, est prohibitif,
Ce sera peut être le cas... ou pas...
Tant que nous ne serons pas en période de conception, il sera difficile de répondre à cette question ;)
Citation:
- soit parce que même si "ce serait bien" de pouvoir tout séparer, on veut surtout que les choses restent liées par défaut (c'est ma principale objection à pas mal d'UI déclaratives : la quantité de code qu'il faut taper pour produire un truc moche reste assez impressionnante, et comme le code n'est pas destiné aux programmeurs eux mêmes, ceux ci ont un peu tendance à ne pas le rendre très amical)
C'est à nous, développeurs, de veiller à ce que ce qui ne nous est pas "directement destiné" reste malgré tout amical...
Je me sens totalement capable de faire respecter ce point :D
(dois-je avouer que je risque d'être chiant en supprimant à vue toute version qui ne respecte pas les règles qui seront imposées par les specs, une fois qu'elles seront écrites :question:)