Bonjour à tous,
Je ne suis absolument PAS programmeur professionnel (
et il est d’ailleurs absolument hors de question que je le devienne)... Sans doute peut-on dire de mon niveau qu’il est celui d’un «
honnête homme », au sens où on l’entendait au XVIII
e siècle, c’est-à-dire d’un
amateur (celui qui
aime), un tant soit peu éclairé.
L’API d’Open/LibreOffice est bien trop grande pour imaginer la moindre exhaustivité dans le cadre d’un tutoriel. L’amateur comme le professionnel se rendent très vite à cette évidence une fois mis un peu le nez dans cette immensité. Toutefois, nous ne pouvons
PAS, dans le domaine francophone, ne pas évoquer
le livre de Bernard Marcelly qui pallie LE problème numéro un : à savoir tirer un bout de fil par
OÙ commencer. Et là, dire qu’un travail de synthèse
n’a pas été fait, c’est, de mon (strict) point de vue, un peu fort de café. Seulement voilà : pour un champ d’application de cette envergure, le
travail de synthèse en question fait neuf cents pages ; doit-on systématiquement projeter sa publication sur le Web ? Je ne suis pas certain qu’abandonner la forme livresque, sachant l’abondance actuelle déjà présente en ligne, serait un plus pour ce qui regarde ce cas d’espèce.
Il en va sans doute différemment des langages
Python ou
JavaScript, dont la suite prétend bien donner accès sans que la chose soit suffisamment pratiquée et démontrée à la masse et que nous croulions en conséquence sous la documentation. De même, celle relative à
Base est aussi proportionnelle au développement-même de ce module de la suite, c’est-à-dire finalement assez pauvre, ceci principalement parce que les développeurs ont souvent préféré travailler sur
Writer et
Calc, laissant non seulement un peu de côté
Base, mais aussi (à mon grand regret tant je fais déjà de belles choses avec)
Draw.
Les forums spécialisés, je veux dire pas seulement ceux de
Develloppez.com, apportent énormément pour peu qu’on se donne quand même la peine de chercher. On peut regretter que le plus connu soit administré par des obsessionnels de la «
forme » (
parce-que-si-t’as-pas-mis-la-balise-machin-sous-la-forme-truc,-tu-te-feras-jeter-comme-du-poisson-pourri), ce qui laisse souvent aux «
éclairés » le soin de dispenser leurs lumières dans des recoins moins accessibles du Web, donc toujours plus compliqué à dénicher pour le débutant.
Outre le
premier abord, souvent difficile c’est acquis, il reste l’
extrêmement spécifique, le truc que peu de gens usent et qui est donc aussi peu documenté, à proportion. Par exemple, quelqu’un a un jour parlé de
la programmation objet avec oBasic, chose qui n’est à priori pas forcément hyper utilisé (et que fort mal implémenté, la chose est acquise) mais qui a tout de même le mérite d’exister !
J’ai, pour ma part, éprouvé le besoin de travailler avec XML une première fois, puis une seconde (pour l’instant). Les lectures, écritures et traitements des fichiers en
oBasic sont tout ce qu’il y a de plus disponible dans l’API ; au pesé du format ODF, il serait d’ailleurs surprenant que cela ne soit pas le cas. Et les domaines que cela ouvre sur le seul axe d’
échanges sont gigantesques. Mais la documentation est rarissime, souvent en anglais, souvent dispensée par bribes de pages de forums, dans une langue souvent propre aux professionnels (
et je suis désolé, mais il peut y avoir une vie informatique en dehors de leur strict milieu un tantinet irrespirable...). J’ai résumé ma propre problématique (et mes principales sources)
dans une page Web. Je n’ai que très peu parlé du DOM parce qu’il est aussi omniprésent que forcément connu des gens qui s’avancent dans ces contrées spécifiques (même amateurs).
Il y a bien longtemps maintenant, j’ai programmé un petit utilitaire, en PHP, qui, d’
un formulaire Web dûment rempli peut,
entre autre, accoucher d’
un « graphique » en art ASCII. Mais cet «
entre autre » est important ; dans la réalité des faits, mes petites données sont stockées
en XML. Si l’art ASCII est ici parfaitement adapté à la fonction de comptage (ligne par ligne), il l’est peu pour présenter ce type de graphiques, extrêmement «
métier », dans le cadre de publications imprimées. On lui préfère donc une forme vectorielle que les tableurs, même
propriétaires,
même avec toutes les contorsions du monde, ne sont pas capables de produire dignement. J’ai donc, il y a peu, programmé une macro capable de lire et de tracer mes données XML avec
Draw, ce qui présente certains avantages non négligeables propres aux
publications spécialisées. Surtout, permettre à l’utilisateur de faire des rajouts en surcouche à des graphiques produits automatiquement, c’est simplement extraordinaire.
Je n’ai, pour l’instant, pas encore publié mes notes de programmation de cette seconde «
expérience XML » via
oBasic. Toutes les notes sont prises et cela viendra en son temps ; forcément. Mais je reste toujours à croire que se lamenter de
l’absent sans produire
au présent reste dépenser une énergie qui pourrait être bien plus utile ailleurs... Il n’est pas faux de dire que la suite évolue. Il arrive même à l’API de diverger d’
OpenOffice à
LibreOffice (par exemple récemment sur la gestion des dates), ce qui ne simplifie pas les choix de programmation.
Je suis estomaqué de lire ici des choses comme «
je voyais plutôt une rubrique présentant le langage d'un point de vue général [...] », car c’est EXACTEMENT le boulot que fait
le chapitre 7 de la FAQ de ce site !!! Car tout de même : arrêtons de dire que le chemin est aussi peu balisé qu’il y a dix ans. Je sais bien qu’il est toujours possible de mieux faire : cela restera même toujours une nécessité. Mais à
figer un constat sur
un logiciel qui évolue, on devient soi-même un tantinet largué... Et cela, c’est précisément ce qui sert en premier le concurrent propriétaire qui n’en attend jamais moins...
Donnons-nous donc d’autres perspectives teintées de plus de
Libertés.
6 |
0 |
Bonjour à tous,
Envoyé par zoom61
Avec ou sans macros.
) me semblerait intéressant