
Envoyé par
alex_vino
Les applications Windows Store écrites en Javascript peuvent accéder a tout (un peu pres) grace a l'API WinJS, c'est peut-etre la meme chose dans Office 2013. Je n'ai pas tester mais logiquement Office 2013 devrait supporter WinJS (j'ai bien dit logiquement

).
Ok, il devrait donc y avoir un ide javascript avec debugger dans cette version, mais quelle confusion entre le javascript "personnel" (PJ) qui peut tout faire et le Javascipt public limité au dom de son document... Pas si satisfaisant que ça ! surtout que VBA fonctionne encore très bien. En fait le seul vrai problème technique de VBA tient à sa gestion du multithread, accessoirement on peut aussi citer son approche objet approximative mais ce n'est pas forcément l'affaire d'un langage super-macro de faire du full objet.

Envoyé par
alex_vino
Oui mais le problème c'est que tu penses avec 18 ans de retard, donc une éternité

. Depuis le Web a grandement évolué au point d'etre utilisé pour des applications natives, et ce meme sous Windows.
J'ai presque envie de dire il faut vivre avec son temps, mais c'est vrai que dans le monde de l'entreprise ce n'est malheuresement pas toujours facile.
Je suis favorable a la nouvelle politique de Microsoft, par contre pour éviter les problemes dans le monde pro et surtout pour faciliter l'adoption il est nécessaire qu'Office supporte les macros VBA au moins dans cette version 2013.
Ben j'ai beau avoir écrit beaucoup de full cloud depuis 2002 et bien d'autres choses, je ne suis pas persuadé que tout le monde recherche la synchro entre machines à tous prix. Il y a quand même de gros bémols, la connexion réseau notamment. Je n'achèterai pas une machine qui ne marche pas sans réseau et je ne conseillerai à personne de le faire ! ensuite il y a ce problème de sécurité des données. Vous pouvez toujours dire à votre client que tout est sûr, si un autre lui dit le contraire, qui votre client croira-t-il ? Celui qui cloude ou celui qui stocke en local ?
Ici, l'approche payante de l'éditeur ne permet pas d'installer des serveurs locaux sur les machines.. L'open source a toujours eu cet avantage. Mais même... si le serveur est local, la fluidité de l'IHM web n'est pas à la hauteur, quant au développement... Imaginez : je veux zoomer et afficher une bulle d'info sur un svg en cliquant une entrée de liste. CSS html, javascript html , svg, CSS-svg, javascript-svg et hop , je zoome d'un cran de molette :
retour serveur, re-css-js-svg-css-js..... va falloir écrire des messages d'attente imaginatifs genre blague de carambar.
L'empilement des langages web n'est pas vraiment un facteur de productivité. Surtout si comme moi, vous court-circuitez le serveur en embarquant un maximum d'ihm dans le doc html, ça fait une couche de plus.

Envoyé par
alex_vino
D'apres tes recherches je penses que Microsoft permet aux entreprises (et le permettra dans sa prochiane version) de migrer en douceur, donc c'est plutot une bonne nouvelle

C'est le scénario le plus logique , mais je pense qu'il y a simplement trop de paramètres et que l'équation n'est pas favorable pour Redmond. le bénéfice d'une architecture toute fraîche ne couvre pas le risque de perdre des centaines de millions de clients potentiels alors qu'access est le seul produit de la gamme qui n'ait pas de concurrence sérieuse dans ce segment.

Envoyé par
alex_vino
De plus la
documentation 9[EN]existe déja pour VBA ce qui prouve qu'ils ne le délaisse pas tant que ca

Merci pour le lien, je pense que cette page montre qu'il faudrait peut être re-marketter VBA au lieu d'en faire un "pis-aller" juste là pour assurer une compatibilité ascendante.
0 |
0 |