Sauf que, ce n'est plus vraiment le cas. Les toolkits graphiques sont passé à des interfaces déclaratives et ça rend les designes bien plus simple que tu semble croire.
Mon expérience de ces technos est très peu approfondie, un peu de .net, un peu de QT (c'était à l'arrivé de QML mais je n'en ai pas fais à ce moment là), un peu de glade, et après des trucs genre pango (pour les fonts si j'ai bon souvenir).
Bref, oui il y à les tk, qui t'aides beaucoup, mais tu dois encore connecter les events.
Par exemple en QT les signals, ont à priori, extrêmement simplifié le problème, sauf que je me suis battu avec à cause des spécificités de C / C++ eect. (les pointeurs tousssa, Oui j'ai un niveau de m*** en C).
Et puis après il faut effectivement programmer les fonctionnalités. Rebolotte il faut se frotter à tout un tas de concepts qui pour moi sont un vrai problème.
Il reste la partie programmatique mais pour ça tu utilise le binding que tu veux (paf QML + Js et c'est partie).
Faudrait que je le testes pour de vrai. Mais je ne peux m’empêcher que cette solution est sous optimale par rapport à une refondation plus profonde comme a pu le faire des projets comme GO ou nodejs (langage que je manipules, mieux que le D, C, c# ect).
L'avantage c'est que tu n'a pas les contraintes liée à HTTP (asynchronisme, le découpage client/serveur de l'application, etc).
Moi je suis très content de ce découplage. Enfin, les technos actuelles purement à base de MVC sont à mon opinion pas bonne du tout.
Mais avec le MVVM pour le client, le MVC pour le serveur tu peux arriver à rendre chacun de ces aspects indépendant, mais pas découplé. J'insiste la dessus, indépendant et non découplé.
Après j'ai l'expérience d'une appli bureau réseau, grosse artillerie, .net Remoting.
Bah je me suis bien amusé au début, après qu'est ce que j'ai ramé……. Je n'ai pas sentit le power to build, mais plutôt le power to debug.
La différence à mon humble avis c'est que l'un est une question de présentation et d’expérience utilisateur (limiter la longueur des lignes etc) et l'autre est de la cosmétique.
Oui probablement. Mais l'un dans l'autre, les toolkits avec tous les efforts qu'ils ont fait ne sont jamais parvenus à fournir un environnement de développement qui permette à l'industrie non informatique de personnaliser leurs applications bureaux.
Là où le web ne travail qu'à cela depuis 20 ans.
Je ne dis pas qu'ils ne sont pas capable sur le desktop, cela ne s'est pas produit.
Et encore que s'attacher au problème de la beauté de l'ui n'est que le pendant du problème de la gestion multi plateforme.
Dans les deux technos web et desktop le multi plateforme est possible.
Dans les deux technos il y à des plus et des moins.
Je considère que les moins du web sont plus attrayants, plus facile à affronter, que les moins du desktop.
Même des technos comme GO ou nodejs qui sont pourtant toute fraîche et pensée pour aller à l'encontre de ces difficultés ne sont pas encore parvenus à une compatibilité sans défaut sur des concepts identiques.
Pour diverses raisons, ce n'est pas tant la question ici.
Tu entends quoi par « DP » ? Tu as des pointeurs sur le mvvm ? J'ai du mal à le différencier du mvc.
Design pattern, pensais tu à autre chose ?
Pour ce qui est de la différence entre mvvm et mvc, j'ai longtemps était dans le flou personnellement. Notamment parce qu'on présente mvvm comme une évolution de mvc cf http://en.wikipedia.org/wiki/MVVM
Alors qu'à mon humble avis ils sont surtout complémentaires et c'est ainsi qu'il faudrait en parler.
Je l'ai compris après avoir builder une application en utilisant knockout.
Éventuellement une bonne vidéo de démo de MVVM à regarder est celle de meteor (recherhe google : meteor js screencast)
bref, le model-view view-model n'intervient que pour synchroniser la vue par rapport au statut d'un modèle de vue (le modele et sa vue dans MVVM).
Car c'est bien d'un modele de Vue dont on parle. Pas d'un modèle de donnée que l'on mets dans un sgbd.
AMHA ce n'est pas un subset, ni une copie identique (penser REST), mais une ré interprétation (on formate, on tri, on prend deux services, on combine et paf un nouveau modèle de vue ect), et une spécialisation (le client de MVVM injecte son état dans son modèle).
Ce client MVVM, discute avec un Controleur de MVC, qui encapsule en entrée / sortie son Modèle de sgbd.
Sa Vue de MVC ne doit "que" formater la réponse en JS / XML / BIN / ce-qu'il-te-plait
Le Contrôleur de MVC, aussi complexe que soit ces règles de gestion, est relativement binaire il répondra toujours succès ou échec. (Les autres trucs 302 404 de HTTP ect c'est pas vraiment son problème à MVC amha, enfin sauf si il décide de ré implémenter une partie de son serveur web lui même… c'est une histoire connue dont je ne parlerais pas)
Le client MVVM peut dès lors consommer ces deux états afin de décider de l'affichage sur sa Vue.
Là où sa devient vraiment beau, c'est à voir l'implémentation de meteor
qui enregistre et applique immédiatement la modification sur son modèle de vue,
envoie sa demande à son contrôleur de MVC côté serveur,
plus tard lorsque le serveur répond, le client MVVM procède alors,
soit à un commit local,
soit un rollback, qui provoque alors une mise à jour de la vue.
Le problème c'est que pour que cela fonctionne bien il faut un pont entre l'implémentation de MVC et MVVM afin de ne pas dupliquer certaines choses comme le routing par exemple.
Il faut qu'il puisse partager des informations. Hors avec des bases en php, asp, java c'est compliqué à moins de passer par des sérialisations, mais alors sa réduit la liberté du développeur.
des réflexions comme sa, à basher, corriger, discuter avec plaisir.
[^] # Re: javascript, ok.
Posté par maboiteaspam . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 1.
hello,
je reprends par la fin :°)
et je le coupe en 3
Mon expérience de ces technos est très peu approfondie, un peu de .net, un peu de QT (c'était à l'arrivé de QML mais je n'en ai pas fais à ce moment là), un peu de glade, et après des trucs genre pango (pour les fonts si j'ai bon souvenir).
Bref, oui il y à les tk, qui t'aides beaucoup, mais tu dois encore connecter les events.
Par exemple en QT les signals, ont à priori, extrêmement simplifié le problème, sauf que je me suis battu avec à cause des spécificités de C / C++ eect. (les pointeurs tousssa, Oui j'ai un niveau de m*** en C).
Et puis après il faut effectivement programmer les fonctionnalités. Rebolotte il faut se frotter à tout un tas de concepts qui pour moi sont un vrai problème.
Faudrait que je le testes pour de vrai. Mais je ne peux m’empêcher que cette solution est sous optimale par rapport à une refondation plus profonde comme a pu le faire des projets comme GO ou nodejs (langage que je manipules, mieux que le D, C, c# ect).
Moi je suis très content de ce découplage. Enfin, les technos actuelles purement à base de MVC sont à mon opinion pas bonne du tout.
Mais avec le MVVM pour le client, le MVC pour le serveur tu peux arriver à rendre chacun de ces aspects indépendant, mais pas découplé. J'insiste la dessus, indépendant et non découplé.
Après j'ai l'expérience d'une appli bureau réseau, grosse artillerie, .net Remoting.
Bah je me suis bien amusé au début, après qu'est ce que j'ai ramé……. Je n'ai pas sentit le power to build, mais plutôt le power to debug.
Oui probablement. Mais l'un dans l'autre, les toolkits avec tous les efforts qu'ils ont fait ne sont jamais parvenus à fournir un environnement de développement qui permette à l'industrie non informatique de personnaliser leurs applications bureaux.
Là où le web ne travail qu'à cela depuis 20 ans.
Je ne dis pas qu'ils ne sont pas capable sur le desktop, cela ne s'est pas produit.
Et encore que s'attacher au problème de la beauté de l'ui n'est que le pendant du problème de la gestion multi plateforme.
Dans les deux technos web et desktop le multi plateforme est possible.
Dans les deux technos il y à des plus et des moins.
Je considère que les moins du web sont plus attrayants, plus facile à affronter, que les moins du desktop.
Même des technos comme GO ou nodejs qui sont pourtant toute fraîche et pensée pour aller à l'encontre de ces difficultés ne sont pas encore parvenus à une compatibilité sans défaut sur des concepts identiques.
Pour diverses raisons, ce n'est pas tant la question ici.
Design pattern, pensais tu à autre chose ?
Pour ce qui est de la différence entre mvvm et mvc, j'ai longtemps était dans le flou personnellement. Notamment parce qu'on présente mvvm comme une évolution de mvc cf http://en.wikipedia.org/wiki/MVVM
Alors qu'à mon humble avis ils sont surtout complémentaires et c'est ainsi qu'il faudrait en parler.
Je l'ai compris après avoir builder une application en utilisant knockout.
Éventuellement une bonne vidéo de démo de MVVM à regarder est celle de meteor (recherhe google : meteor js screencast)
bref, le model-view view-model n'intervient que pour synchroniser la vue par rapport au statut d'un modèle de vue (le modele et sa vue dans MVVM).
Car c'est bien d'un modele de Vue dont on parle. Pas d'un modèle de donnée que l'on mets dans un sgbd.
AMHA ce n'est pas un subset, ni une copie identique (penser REST), mais une ré interprétation (on formate, on tri, on prend deux services, on combine et paf un nouveau modèle de vue ect), et une spécialisation (le client de MVVM injecte son état dans son modèle).
Ce client MVVM, discute avec un Controleur de MVC, qui encapsule en entrée / sortie son Modèle de sgbd.
Sa Vue de MVC ne doit "que" formater la réponse en JS / XML / BIN / ce-qu'il-te-plait
Le Contrôleur de MVC, aussi complexe que soit ces règles de gestion, est relativement binaire il répondra toujours succès ou échec. (Les autres trucs 302 404 de HTTP ect c'est pas vraiment son problème à MVC amha, enfin sauf si il décide de ré implémenter une partie de son serveur web lui même… c'est une histoire connue dont je ne parlerais pas)
Le client MVVM peut dès lors consommer ces deux états afin de décider de l'affichage sur sa Vue.
Là où sa devient vraiment beau, c'est à voir l'implémentation de meteor
qui enregistre et applique immédiatement la modification sur son modèle de vue,
envoie sa demande à son contrôleur de MVC côté serveur,
plus tard lorsque le serveur répond, le client MVVM procède alors,
soit à un commit local,
soit un rollback, qui provoque alors une mise à jour de la vue.
Le problème c'est que pour que cela fonctionne bien il faut un pont entre l'implémentation de MVC et MVVM afin de ne pas dupliquer certaines choses comme le routing par exemple.
Il faut qu'il puisse partager des informations. Hors avec des bases en php, asp, java c'est compliqué à moins de passer par des sérialisations, mais alors sa réduit la liberté du développeur.
des réflexions comme sa, à basher, corriger, discuter avec plaisir.
a+