Bonjour Jean Louis,
Lu dans marketing, une nouvelle (desole en Anglais) :
http://www.heise.de/english/newsticker/news/85162
Mais bof, au risque d insister, si deja, pour l utilisateur final, l
enregistreur de macro fonctionnait convenablement... :-(
J'ai dejà exprimé des reserves lors de la creation du projet VBA par
Novell et la mise en oeuvre de la solution proprietaire et non
interoperable (et oui) de Sun à leurs epoques. Je vous livre ici
quelques reflexions que je reprendrai surement par ailleurs, moins brut
de decoffrage.
L'enregistreur de macro fait son boulot, il enregistre des macros
Ce que les gens attendent c'est un outil d'apprentissage qu'il n'est pas
contrairement à son homologue sous Ms Office (si il est incomplet, alors
oui, le completer) (a noter egalement un debut de travail de Paolo
Mantovani sur un enregistreur de macro ecrivant du code sans dispatcher
en python - le projet est en sommeil, on pourrait le reactiver, mais il
faut des volontaires ... )
Donc, oui, les macros vba sont un probleme mais il devient insurmontable
car nous ne mettons pas les bons outils à disposition, ce qui donc
conduit à ce type de projet de support inconditionnel d'une technologoe
non maitrisée. Les migrations seraient vues comme beaucoup moins
critiques si un convertisseur était ecrit (et non un interpreteur comme
c'est actuellement ce qui est prevu) et surtout si les outils d'EDI
etaient enfin ameliorés : Autocompletion, integration au sdk etc (oui,
il y a XRay mais ce n'est pas une demarche naturelle pour un nouveau
venu, l'autocompletion, ca fait deux ans que l'on en parle dans le
projet framework et si ce n'est pas simple, on pourrait avoir quand meme
quelques avancées significatives ...)
Nous avons gagné la bataille de l'OpenDocument car nous avions un
avantage technologique, le fichier xml zippé, que la concurence n'avait
pas. Du coup, les filtres Ms Office n'ont pu s'imposer comme format par
defaut dans OOo. Ne me faites pas dire ce que je n'ai aps dit, il etait
indispensable de les avoir mais OpenDocument et OOo auraient ils eu la
meme independance si il n'y avait pas eu cet avantage technique ?
Il semble alors que certains enthousiastes veuillent reproduire la meme
chose avec VBA. Mais là, quel avantage direct avons nous (je ne parle
pas de la superioriyé de l'api, de UNO et tout l'ecosysteme
multi-langage pouvant etre créee) ? Aucun. Je dirais que faute d'outils,
nous serions plutot en retard pour la grande majorité des utilisateurs
qui se contenterons de reproduire ce qu'ils faisaient, ecrire des
macros. Nous sacrifions l'api de OOo sur l'autel de l'interoperabilité.
Mais c'est comme si OOo aurait basé l'interoperabilité de ses fichiers
sur les formats word ou excel.
Une possibilité d'evolution de la situation serait une place
grandissante de l'api vba au detriement de celle native de OOo et donc
un echec de l'api de OOo car nous n'aurions pas atteint la masse
critique. Il est en effet beaucoup plus facile de trouver de la
documentation et de l'aide sur l'api de vba que celle de OOo. Donc, tout
le monde va finir par parler vba, oublier l'api native qui sera releguée
au rang des specialistes, utilisée au travers d'autres langages etc ...
Et comme l'implémentation de cette api vba sera toujours en retard par
rapport à l'originale, au mieux le support des macros sous OOo finira
par etre vu comme moyen et peu fiable, au pire les possibilités natives
seront completement oubliées (ou negligées par manque de masse critique)
et freineront l'adoption de OOo.
Je laisse enfin de coté les interressants problemes techniques que celà
souleve et auquel je n'ai pas eu encore de reponse de la part ds
porteurs du projet : comment les deux API vont elles communiquer ? un
objet cellule de Excel n'est pas du tout un objet cellule de OOo. Et
pourtant c'est un objet cellule. Donc quelle sera la portée de l'objet
vba ? Aura t on le droit de mixer les api dans une meme macro ? un meme
module ? une meme bibliotheque ? Vis a vis de l'utilisateur ca ve
devenir incompréhensible (pourquoi y a t il la definition de deux objets
cellule ?) et alors il restera sur ce qu'il manipule depuis longtemps,
l'implementation vba
La problematique de migration de macros n'est certes pas simple mais a
vouloir des solutions à moindre coup et à court terme, ne risque t on
pas de perdre plus que l'on ne gagne sur le long terme ? Au moins la
solution de migration de macro definie par SUN etait un premier pas (si
libre) qu'il aurait fallu completer par des outils de developpement un
peu plus user-friendly du coté des macros. Mais y en a t il encore la
volonté ?
Voila, je rappel que ces quelques lignes sont brut de decoffrage et
qu'elles meriteront un peu plus de travail pour echafauder un veritable
argumentaire (qui a dit plaidoyer ?).
Laurent
--
Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org -
http://www.indesko.com
Nuxeo Enterprise Content Management >> http://www.nuxeo.com -
http://www.nuxeo.org
Livre "Programmation OpenOffice.org", Eyrolles 2004-2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
