[Résolu][Basic]Est-ce le bon outil?

[jpmoularde]

Bonjour, ???

Je me suis lancé dans la lecture du livre "Programmation OpenOffice.org et LibreOffice", livre très bien fait mais qui me remplit de perplexité.

Mon intention était de réécrire une application initialement développée en VBA/Excel de plusieurs milliers de lignes de code.
J'avais réalisé du début des années 2000 plusieurs application VBA/Excel ou VBA/Word qui ont permis à la société de services pour laquelle je travaillais avant ma retraite de gérer les propositions de contrat et le suivi de l'avancement des projets au niveau international.
Ce sont ces mêmes technique que j'utilise actuellement pour gérer quelques sites web dont j'assure la maintenance, et pour diverses raisons j'avais l'intention de passer de MSOffice/VBA à OpenOffice/OOoBasic.

Malheureusement je ne trouve rien qui me permette de faire ce développement, en particulier:

• le plus important: je n'ai pas compris comment créer mes propres objets, et j'ai l'impression que ce n'est pas possible.
  J"avoue ma perplexité: faut-il abandonner la programmation objet et revenir à des "types", c'est à dire des structures de données sans méthodes attachées? Je pensais cette approche périmée depuis que la diminution du coût du CPU et de la mémoire a permis le bon en avant de la programmation Objet dans les années 1990. Cela doit faire plus de 15 ans que je n'ai pas analysé et programmé une application autrement qu'à base d'objets.
• je n'ai pas vu d'interface permettant de gérer un fichier xml en utf-8 en lecture ou en écriture, ce qui est d'autant plus surprenant que OpenOffice semble faire une utilisation intensive de xml. Si j'ai bien compris, OpenOffice traite les caractères en interne sur 16 bits, ce qui me semble effectivement l'état de l'art, mais OOoBasic n'a pas l'air de savoir traiter les caractères au delà de 255 (8 bits). J'ai dû très mal comprendre.
• je n'ai pas vu d'interface permettant de transférer des fichiers depuis ou vers un serveur FTP ou plus généralement d'appeler des fonctions externes

Merci de (re)lire les règles de ce forum : une seule question par fil avec un titre explicite.

Ce langage a l'air en fait limité à faire quelques automatisations de fonctions répétitives, c'est à dire au sens propre des "macros", ce qu'on faisait dans les très vieilles versions de VBA. Cela me semble surprenant, car comment vouloir concurrencer le leader du marché sans offrir des fonctions sinon compatibles du moins équivalentes?
Ce n'est pas avec les quelques exemples du livre ou ceux que j'ai pu trouver sur le site, forcément limités, que je peux comprendre comment résoudre mes problèmes.

Dois-je abandonner l'idée de réaliser ce développement avec OpenOffice et OOoBasic?
Ou plus vraisemblablement y a-t-il quelque chose qui m'échappe dans la logique et l'implémentation du produit?

[Bidouille]

Bonsoir,

La section Macro & API est juste faite pour des questions précises sur la programmation.

Ce langage a l'air en fait limité à faire quelques automatisations de fonctions répétitives, c'est à dire au sens propre des "macros", ce qu'on faisait dans les très vieilles versions de VBA. Cela me semble surprenant, car comment vouloir concurrencer le leader du marché

A priori, vous souhaitez plutôt entretenir une comparaison avec une suite bureautique payante et fermée.

Je transfère dans la section Tribune libre.

[jpmoularde]

Bonsoir,

La section Macro & API est juste faite pour des questions précises sur la programmation.

Ce langage a l'air en fait limité à faire quelques automatisations de fonctions répétitives, c'est à dire au sens propre des "macros", ce qu'on faisait dans les très vieilles versions de VBA. Cela me semble surprenant, car comment vouloir concurrencer le leader du marché

A priori, vous souhaitez plutôt entretenir une comparaison avec une suite bureautique payante et fermée.

Je transfère dans la section Tribune libre.

Si vous voulez.
Je ne cherche pas à faire des comparaisons, simplement savoir si j'ai bien compris qu'on ne pouvait faire que des choses limitées avec cet outil, ou si quelque chose m'échappe et que c'est possible.
Je crains malheureusement que votre réponse signifie que mes craintes sont fondées.

[jpmoularde]

À propos, ou est la "tribune libre"?

[jpmoularde]

Merci de (re)lire les règles de ce forum : une seule question par fil avec un titre explicite.

Il n'y a qu'une seule question, et elle est dans le titre. Le reste, ce sont des éléments d'explication de la question.

[alhazred]

Bonsoir,

En ce qui concerne la programmation orientée objet, tu peux consulter cet article de Churay.

Et évite de poster plusieurs messages à la suite : le bouton Editer est là pour ça

[jpmoularde]

Bonsoir,

En ce qui concerne la programmation orientée objet, tu peux consulter cet article de Churay

Merci mille fois, voilà un point qui me redonne confiance dans la possibilité d'utiliser le produit pour ce que j'ai l'intention de faire. Lors de ma retraite il y a 6 ans, j'avais déjà pensé à changer d'outil pour OpenOffice, et j'avais renoncé devant l'ampleur de la tâche et les doutes que j'avais sur la possibilité de le faire. Comme je voudrais pouvoir faire effectuer la saisie des données par d'autres personnes, je me suis à nouveau remis à étudier sérieusement cette hypothèse. J'espère que cet article va me permettre d'aboutir.

Et évite de poster plusieurs messages à la suite : le bouton Editer est là pour ça

Il est effectivement assez gros, mais hier soir je l'ai cherché sans le trouver. Résultat sans doute de ma frustration de voir ma question de fond traitée de façon administrative et superficielle!

.

[bm92]

Bonjour,

Mon intention était de réécrire une application initialement développée en VBA/Excel de plusieurs milliers de lignes de code.
(...)
J"avoue ma perplexité: faut-il abandonner la programmation objet et revenir à des "types", c'est à dire des structures de données sans méthodes attachées?

OpenOffice peut être automatisé avec différents langages, chacun a des avantages et des inconvénients.

OpenOffice Basic n'est pas orienté objet, et les notions de classes n'en font pas un véritable langage objet. C'est un langage de macros, suffisant pour des applications mêmes élaborées si on prend soin de structurer correctement le programme.
Python est un langage objet disposant de nombreuses bibliothèques; l'accès à l'API est très similaire à Basic, mais l'absence d'EDI intégré nécessite de mettre les doigts dans le cambouis.
Java offre encore plus de possibilités pour un développeur compétent. Il est plus lourd à programmer dans les accès à l'API OpenOffice.
C++ est encore plus complexe que Java pour utiliser l'API.

Enfin, face à un projet de plusieurs milliers de lignes de code, je me demande : quelle est la part spécifique à Excel/Calc ? Ce projet a-t-il vraiment besoin d'être intégré dans un tableur, ou le tableur est-il seulement utilisé pour afficher des résultats, ou le projet a-t-il été développé sur VBA/Excel simplement parce qu'il offrait d'un langage de programmation gratuit ? Il existe d'autres langages de programmation orientés objet, gratuits, puissants, et en source libre.

[Churay]

Bonjour,

cet article de Churay[/url]

Merci, merci : merci mille fois, mais heu....
Le mérite en revient à JPL : je me suis contenté de faire de la mise en page pour obtenir un document plus facilement retrouvable que le bon fil (enfin : quand, comme moi, on n'est pas toujours performant avec l'outil de recherche d'un forum)...

Ce langage a l'air en fait limité à faire quelques automatisations de fonctions répétitives

Au départ, les langages de macros (ou de scripts) existent pour automatiser, me semble-t-il.
Au-delà, ils permettent généralement d'aller plus loin et bien souvent beaucoup plus loin.
Comme tout langage Basic (OOo|AOO|LO)demande du temps : entre autre celui de se familiariser avec l'API.
Et les quelques deviennent plus nombreuses...

Après, comme le signale bm, si la notion objet est essentielle, autant attaquer avec un langage de POO et interfacer ensuite.

Basic n'est pas limité : simplement il n'est pas adapté (ou mal adapté) à tous les traitements, comme n'importe quel langage AMHA.

[jpmoularde]

Enfin, face à un projet de plusieurs milliers de lignes de code, je me demande : quelle est la part spécifique à Excel/Calc ? Ce projet a-t-il vraiment besoin d'être intégré dans un tableur, ou le tableur est-il seulement utilisé pour afficher des résultats, ou le projet a-t-il été développé sur VBA/Excel simplement parce qu'il offrait d'un langage de programmation gratuit ? Il existe d'autres langages de programmation orientés objet, gratuits, puissants, et en source libre.

Merci de votre réponse

Le problème que je veux traiter est la saisie de données nombreuses et complexes, pour lesquelles un formulaire n'est pas suffisant.

Utiliser une feuille de tableur comme formulaire est une technique que j'ai utilisée avec succès depuis de nombreuses années, en utilisant à la fois les possibilités du tableur et celles du langage de contrôle.
L'application que j'ai développée pour mon ancien employeur avant de partir en retraite se déroulait en 3 phases:

1. Réception en attachement à un courriel des informations provenant de la base de donnée de l'entreprise sur les temps déclarés par les différents intervenants, et intégration automatique des données à partir du courriel sauvegardé pour créer de nouvelles feuilles de calcul
2. saisie par le responsable de projet des informations complémentaires: validation des chiffres provenant de la base de données, estimation du "reste à faire" mensuel et trimestriel, état des relations avec le client et avec les membres de l'équipe, intégration des avenants au contrat, etc.
3. fabrication d'un fichier xml contenant les informations de gestion du projet, affichage des informations et courbes d'évolution, envoi du fichier xml en attachement à un courriel généré automatiquement.

Cette application permettait à quelques milliers de responsables de projet en Europe de fabriquer leur rapport d'activité mensuel en moins d'une heure, tout en assurant la centralisation des données, les comparaisons entre projets, etc.

Dans l'application que je veux réaliser en Basic (ou tout autre langage) il s'agit là encore de saisir de multiples données sur plusieurs feuilles, avec tous les controles possibles en amont avant d'envoyer un fichier xml sur un site.

OpenOffice étant la seule alternative à "nous savons qui", j'avais déjà regardé il y a 6 ans (au moment où je partais en retraite) si je pouvais l'utiliser pour ce genre d'application. A l'époque cela m'avait paru un peu compliqué alors que j'était le seul utilisateur de mes applications. Maintenant j'aimerais faire remplir les feuilles par d'autres personnes qui n'ont aucune compétence informatique: j'ai donc besoin d'applications qui fassent encore plus de contrôles sur les données, et cela passe bien par un tableur assisté par du code évolué en Basic (ou autre).

Si cela n'est pas faisable, je serai conduit à prendre une toute autre approche: des formulaires on-line gérés par php sur le site. Mais les premiers essais montrent que c'est une approche très lourde à programmer et n'offrant pas les nombreuses facilités offertes par un tableur, telles que le copier/coller d'une ligne ou d'une colonne ou la vérification automatique et immédiate de la valeur d'une donnée entrée.

[jpmoularde]

Merci de ne pas poster plusieurs messages à la suite !
Si vous devez ajouter un complément d'information, le bouton "Editer" à la droite du message permet d'y remédier.

En attendant une prochaine réponse, vous pouvez participer également en répondant à d'autres questions sur notre forum.

Au départ, les langages de macros (ou de scripts) existent pour automatiser, me semble-t-il.
Au-delà, ils permettent généralement d'aller plus loin et bien souvent beaucoup plus loin.
Comme tout langage Basic (OOo|AOO|LO)demande du temps : entre autre celui de se familiariser avec l'API.
Et les quelques deviennent plus nombreuses...

Merci de cette réponse.
J'ai du pratiquer dans ma vie d'informaticien (depuis 1967) une bonne trentaine de langages, donc utiliser un nouveau langage ne me pose pas de problème a priori, sauf que si on en utilise trop simultanément on risque de confondre les syntaxes.
Comme de plus je suis en retraite, je suis prêt à passer le temps nécessaire à acquérir un nouveau langage, pour autant que ce soit le bon, et c'est là le sens de ma question.

Une remarque: ce ne sont pas seulement les langages de scripts qui servent à automatiser: c'est le rôle de toute application informatique, et donc de tout langage, que d'automatiser des tâches fastidieuses ou infaisables manuellement dans des délais raisonnables. La particularité des langages de script c'est de manipuler les objets d'une application telle que Calc (cellules, feuilles, etc.)

D'où ma question: Basic est il le bon outil? Est-ce que les autres langages de scripts supportés par OpenOffice seraient plus appropriés? Lesquels?

Quant aux discussions subtiles sur le fait que Basic (ou tout autre langage) puisse être un 'langage objet", je ferais simplement remarquer qu'à l'origine (j'y étais!) Basic ne supportait que les variables dont le nom faisait un seul caractère, que les branchements se faisaient par "goto numéro de ligne", etc. Tout langage aujourd'hui doit à mon sens être au minimum capable de supporter les "objets simples" permettant l'encapsulation et le polymorphisme, sachant que l'héritage (même unique) n'est pas absolument indispensable, de même que depuis longtemps tous les langages ont évolué pour faciliter la programmation structurée.

[Churay]

des formulaires on-line gérés par php

Je trouve aussi rapidement de la lourdeur avec php...

ou la vérification automatique et immédiate de la valeur d'une donnée entrée.

immédiate non, mais entre le submit et le passage à la suite, tu peux toujours revenir sur le contrôle non conforme et lui donner le focus.
Lourdeur, pour lourdeur... tu peux récupérer un pack de fonctions prêtes à l'emploi en JavaScript chez biblioscript.com.

[jpmoularde]

des formulaires on-line gérés par php

Je trouve aussi rapidement de la lourdeur avec php...

Ah que oui!

ou la vérification automatique et immédiate de la valeur d'une donnée entrée.

immédiate non, mais entre le submit et le passage à la suite, tu peux toujours revenir sur le contrôle non conforme et lui donner le focus.
Lourdeur, pour lourdeur... tu peux récupérer un pack de fonctions prêtes à l'emploi en JavaScript chez biblioscript.com.

Merci
Bien entendu j'ai déjà ce genre de fonctions dans mon arsenal (à mon âge, ce serait bien le comble de ne pas les avoir!)
Mais ça ne fait que vérifier la nature du champ ou la cohérence avec les autres champs du même formulaire. SI je veux vérifier la cohérence avec d'autres morceaux de la base de donnée, il faut que j'envoie ma base de données en Javascript. Je l'ai déjà fait dans certains cas, mais j'aime mieux éviter ce genre de fonctionnement.

[bm92]

Bonjour,

[Basic]Est-ce le bon outil?

Tu as déjà une solution que tu connais bien, qui correspond à ta manière de voir les choses, qui marche depuis des années.
Seul inconvénient, elle est entièrement dépendante des fonctionnalités offertes par Microsoft Excel et son VBA.

Pour utiliser OpenOffice à la place il faudra récrire totalement le projet : OpenOffice n'est pas un clone d'Excel, et son API est très différent de VBA; il n'y a pas toujours d'équivalence, ce ne sera pas un transcodage.
Ces difficultés, tu les rencontreras quel que soit le langage de programmation, et tu risques d'obtenir une solution peu satisfaisante.
Quitte à changer il vaudrait mieux reprendre à zéro le principe même de la solution. Je ne suis pas convaincu qu'utiliser un tableur soit nécessaire pour ton projet. Les langages externes sont parfaitement capables de présenter des formulaires très élaborés, y compris avec des données sous forme tabulaire, avec plus de souplesse qu'un tableur.

[jpmoularde]

Bonjour,

[Basic]Est-ce le bon outil?

Tu as déjà une solution que tu connais bien, qui correspond à ta manière de voir les choses, qui marche depuis des années.
Seul inconvénient, elle est entièrement dépendante des fonctionnalités offertes par Microsoft Excel et son VBA.
Pour utiliser OpenOffice à la place il faudra récrire totalement le projet : OpenOffice n'est pas un clone d'Excel, et son API est très différent de VBA; il n'y a pas toujours d'équivalence, ce ne sera pas un transcodage.
Ces difficultés, tu les rencontreras quel que soit le langage de programmation, et tu risques d'obtenir une solution peu satisfaisante.
Quitte à changer il vaudrait mieux reprendre à zéro le principe même de la solution. Je ne suis pas convaincu qu'utiliser un tableur soit nécessaire pour ton projet. Les langages externes sont parfaitement capables de présenter des formulaires très élaborés, y compris avec des données sous forme tabulaire, avec plus de souplesse qu'un tableur.

Bonsoir et merci de ta réponse

Réponses aux différents points de ce message (si les "modérateurs" du forum me permettent de le faire dans un seul message) :

1. Pas de problème, j'ai bien compris qu'il faudrait tout réécrire de zéro, ça ne me fait pas peur. J'ai eu l'occasion de développer des choses nettement plus complexes dans le passé, et malgré mon grand âge je me sens encore capable de le faire.
2. Ma solution, si je décide de la développer sur OpenOffice, ne dépendra pas des "fonctionnalités offertes par Microsoft Excel et son VBA" mais des "fonctionnalités offertes par OpenOffice Calc et son Basic" et c'est justement pour avoir une idée plus précise de ces fonctionnalités que je me suis permis de m'inscrire sur ce forum et de poser cette question. Indépendamment de mes besoins propres, je serais heureux que OO et Basic soient suffisamment évolués pour offrir une alternative aux produits qui dominent le marché, mais c'est une position philosophique personnelle qui ne présente pas d'importance dans la discussion en cours.
3. J'ai bien compris que OpenOffice/Basic et Excel/VBA étaient différents, mais pas fondamentalement plus différents que les multiples plateformes et langages que j'ai utilisés depuis 1967. Je ne compte plus le nombre d'applications et d'algorithmes que j'ai développés et redéveloppés sous des environnements différents, sachant que lorsqu'on a en tête une approche correcte d'un problème, l'implémentation dans un autre langage et un autre environnement ne présentent d'autre difficulté que d'acquérir la connaissance de ce langage et de cet environnement.
4. Je n'ai pas décidé au hasard de développer mon application sur un tableur; c'est le résultat d'une longue recherche de solutions, d'essais et erreurs avec pas mal d'aller-retours, mais si vous me fournissez des exemples de "langages externes parfaitement capables de présenter des formulaires très élaboré, avec plus de souplesse qu'un tableur" je serai heureux de les étudier et de développer une nouvelle solution sur une nouvelle base si je trouve bon bonheur.

Je rappelle par ailleurs les trois problèmes principaux que j'ai décrits dans ma question initiale, et qui venaient de ce que je n'avais pas trouvé de réponse dans le document:

1. le plus important: je n'ai pas compris comment créer mes propres objets
   J'ai reçu à ce sujet une réponse de alhazred qui me donne l'impression qu'on peut doit pouvoir avoir des "objets simples" qui devraient satisfaire mes besoins. Je vais creuser ce sujet.
2. je n'ai pas vu d'interface permettant de gérer un fichier xml en utf-8 en lecture ou en écriture
   C'est effectivement fort étonnant, car toute la documentation externe disponible sur OpenOffice insiste sur le fait que ce produit utilise intensément le XML.
   Mais si les "objets simples" listés au point précédent sont conformes à ce que je pense, et si le support des caractères Unicode par Basic est bien ce que je crois (information trouvée en dehors de ce forum sur les fonctions AscW et ChrW), je devrais pouvoir développer moi même un module correspondant aux quelques fonctions XML dont j'ai besoin.
3. je n'ai pas vu d'interface permettant de transférer des fichiers depuis ou vers un serveur FTP
   Je devrais pouvoir trouver un contournement acceptable par mes utilisateurs

J'ai conscience d'avoir semé la perturbation dans ce forum, je vous prie tous de m'en excuser.
Je n'ai plus l'intention de me manifester davantage jusqu'à nouvel ordre, sauf pour répondre éventuellement à vos messages.

[Bidouille]

Je rappelle par ailleurs les trois problèmes principaux

Et moi, je vous rappelle les règles et qu'il ne faut mettre qu'une question par fil : http://forum.openoffice.org/fr/forum/ftopic1.html

Poser plusieurs questions complique la compréhension et n'encourage pas les réponses : il vaut donc mieux découper votre problème.
Le titre de votre question ne peut pas refléter l'ensemble des problèmes exposés.

A ce sujet, on vous a répondu : http://forum.openoffice.org/fr/forum/vi ... =8&t=38027

Je n'ai plus l'intention de me manifester davantage jusqu'à nouvel ordre, sauf pour répondre éventuellement à vos messages.

Je rappelle également que vous êtes sur un forum communautaire où l'entraide se fait avec la collaboration de tous.
Venir poser une question et attendre une réponse n'est pas une attitude positive.
Vous pouvez aussi répondre à d'autres sur ce forum surtout qu'il semble que vous soyez du métier depuis très longtemps.

Merci d'ajouter [Résolu] au début du titre du 1er message sans oublier de cocher la case de l'icône de sujet (le V vert).

[jpmoularde]

Merci d'ajouter [Résolu] au début du titre du 1er message sans oublier de cocher la case de l'icône de sujet (le V vert).

J'ai mis "résolu" car j'ai fini par trouver ailleurs que sur ce forum une réponse à ma question.

Je ne ferai pas de commentaires sur les autres points abordés par M. Bidouille.

[OOo - Ekel]

Bonsoir,

La vérité est ailleurs nous le savons....

Par contre, il faut apprendre à lire les règles... c'est le premier message qu'il faut éditer !

Cordialement.

[Alain de La Chaume]

Bonjour,

j'ai fini par trouver ailleurs que sur ce forum une réponse à ma question

Sur un forum d'entraide comme celui-ci, il eut été de bon ton de faire profiter la communauté de votre trouvaille.
Car sur un forum d'entraite, le principe est de partager la connaissance.
La plupart des participants a adopté ce principe élémentaire.
Mais compte tenu de ce que j'ai lu de vous, notamment "et malgré mon grand âge" j'ai compris que nous ne changerons rien à vos habitudes, et que partager n'en fait pas partie.

Alain