Journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets

Posté par (page perso) . Licence CC by-sa
3
5
août
2016

Sommaire

Introduction

Cette application a pour buts, d'une part, de tester la mise en œuvre de certains concepts de développement (proof of concepts), et, d'autre part, au fur et à mesure de son évolution, de mettre à disposition des fonctionnalités de prise de notes, d'agenda, de gestion d'adresses…

Ces deux buts vont être détaillés dans les deux sections suivantes.

Auparavant, voici quelques liens relatifs à cette application :
- Sources du logiciel (compilables sous GNU/Linux et autres systèmes POSIX, dont OS X) et binaires Windows (XP SP3 et supérieurs) : http://q37.info/download/computing/apps/orgnzq/,
- démonstration en ligne de la version web : http://q37.info/xdh/orgnzq.html.

Les sources peuvent aussi être consultés directement à l'adresse :
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/apps/orgnzq pour l'application proprement dite,
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/tools/xdhcefq pour l’utilitaire prenant en charge la technologie XDHTML en tant qu'application desktop,
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/tools/xdhbrwq pour l’utilitaire prenant en charge la technologie XDHTML en tant qu'application web,
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/stable pour le framework.

Quelques précédents journaux en relation avec celui-ci :
- sur les débuts de l'application,
- sur l'interface web,
- sur la technologie XDHTML mise en œuvre dans cette application.

But n° 1 : proof of concepts

Hors gestion de l'interface graphique

Pour l'ensemble des binaires sous forme d'utilitaire avec interface en ligne de commande (CLI), ou déployés en tant que daemon, les objectifs suivants sont visés :

  • développement uniquement en C++,
  • portabilité multi-plateformes et multi-architectures,
  • utilisation uniquement des bibliothèques C/C++ standards et systèmes.

Par rapport à ces objectifs, cette application tourne sur GNU/Linux (et potentiellement toute plateforme POSIX), OS X et Windows, sous architecture IA-32, AMD-64 et ARM 32 bits. Pour la compilation, seul un compilateur C++, ainsi que la commande make, sont nécessaires.

Gestion de l'interface graphique

Pour la gestion de l'interface graphique, en plus des objectifs ci-dessus, sont visés les objectifs suivants (technologie XDHTML) :

  • utilisation des technologies web (HTML5, CSS…),
  • un seul et unique code C++ pour les versions web, desktop et mobile,
  • modification de l'apparence de l'application sans avoir à modifier son code source, juste en modifiant des fichiers XSL.

Par rapport à ces objectifs, seule les versions web et desktop ont été développées. Hors version desktop, et notamment pour la version web, les mêmes observations que ci-dessus concernant les plateformes, les architectures et la compilation sont valables. L'adaptation de l'interface aux particularités des plateformes sur lesquelles elle tourne (desktop, web ou mobile), par rapport aux dimensions de l'affichage notamment, se fera au niveau des fichiers XSL.

Le cœur de l'application prend la forme d'une bibliothèque dynamique, qui répond intégralement aux objectifs ci-dessus (notamment pas de dépendances hors bibliothèques C/C++ standards et systèmes). Sa mise en œuvre en tant que version desktop est prise en charge par un utilitaire nommé xdhcefq, et sa mise en œuvre en tant que version web, par un utilitaire nommé xdhbrwq (qui, de ce fait, est assimilable à une CGI).

xdhcefq s'appuie sur Chromium Embedded Framework (CEF), et est donc soumis aux mêmes contraintes en termes de plateformes, architectures et compilation. Néanmoins, on peut envisager de développer l'équivalent de xdhcefq en s'appuyant sur XULRunner ou QtWebKit, par exemple, ou tout autre composant, présent ou à venir, proposant un moteur de rendu web. Le cœur de l'application n'aura pas à être modifié.

Réutilisabilité

Un maximum de code développé dans le cadre de cette application est intégré dans un framework (publié sous licence AGPL), pour qu'il puisse être réutilisé pour d'autres applications. Les utilitaires xdhcefq et xdhbrwq notamment, qui permettent de déployer une application respectivement dans sa version desktop et sa version web, ne sont pas propres à cette application, mais seront utilisables par n’importe quelle application s'appuyant sur la technologie XDHTML.

But n° 2 : les fonctionnalités

A terme, cette application proposera des fonctionnalités de prise de notes, d'agenda, de carnets d'adresse…, avec de notables différences avec l'existant.

Une de ces différences, suite à la mise en œuvre de la technologie XDHTML, porte sur la facilité avec laquelle l'aspect de son interface pourra être modifié par toute personne familière avec les technologies web et XSLT. Une autre de ces différences portera sur l'adaptabilité de l'application. Ainsi, la gestion de l'authentification, des types de champs, et du stockage des données se fait par un système de plugins, ce qui facilitera la mise en œuvre d'alternatives.

L'apparence de l'application est très rustique, d'une part parce que mes connaissances en HTML et CSS sont très limitées, et, d'autre part, parce qu'il est facile pour toute personne ayant des connaissances en HTML, CSS et XSLT de modifier cette apparence à sa guise, conformément à ce qui est annoncé dans la précédente section.

Du fait que l'on se concentre actuellement sur le but n°1 (les proof of concepts) de l'application, ses fonctionnalités sont encore très limitées. Voici celles qui sont actuellement disponibles (les entrées en gras sont des nouveautés par rapport à la précédente version) :

  • prise en charge de plusieurs utilisateurs,
  • gestion d'onglets,
  • réorganisation des onglets par *drag & drop*,
  • création d'une fiche,
  • modification d'une fiche en cliquant sur son entrée dans la liste,
  • création, dans une fiche, de champs mono ou multi de type :
    • texte simple,
    • texte enrichi (avec mise en forme),
    • date,
    • heure,
  • réorganisation de l'ordre des champs d'une fiche par drag & drop,
  • modification d'un champ d'une fiche en cliquant sur son libellé,
  • modification d'une entrée d'un champ multi en cliquant sur son contenu,
  • réorganisation des entrées d'un champ multi par drag & drop,
  • et, accessoirement, affichage d'un A propos… avec la séquence de touches Ctrl-Shift-A (cela provoque l'ouverture d'une nouvelle page avec certains navigateurs ; il faudra revenir sur la page de l'application).

Une démonstration en ligne de l'application est accessible à : http://q37.info/xdh/orgnzq.html.

Cette démonstration tourne sur un petit serveur placé derrière une box ADSL. De ce fait, l'application peut manquer de réactivité. Cette démonstration devrait tourner sur la plupart des navigateurs web graphique moderne, à la notable exception de Microsoft Edge (sauf s'il s'agit de la dernière version, celle fournie avec Windows 10 version 1607). En outre, à cause de ceci, certaines données ne s'afficheront pas correctement dans Firefox.

Avec la version desktop de l'application, vous pouvez vous connecter directement au backend de la version web de démonstration en sélectionnant Moteur de traitement sur q37.info sur la première page de l'application. Si vous vous connectez avec le même compte sur la version de démonstration en ligne et sur la version desktop, les modifications opérées dans l'une seront naturellement visibles dans l'autre, et vice-versa.

Déploiement

GNU/Linux

Compilation

En supposant que g++ et make soient installés :

  • Télécharger et décompresser les sources de l'application situés à : http://q37.info/download/computing/apps/orgnzq/,
  • télécharger et décompresser la version de CEF de la branche 2704 correspondant à votre architecture (Linux 32bit ou Linux 64bit) située à http://cefbuilds.com/,
  • créer une variable d'environnement nommée CEF pointant sur la racine du package de CEF (export CEF=<path to>/cef_binary_3.2704...),
  • se placer à la racine du package de l’application et lancer la commande make.

Lancement de l'interface desktop

Pour lancer l'interface desktop, se placer dans le répertoire frontend et lancer xdhcefq/xdhcefq -m=XDHTML/orgnzqxdh. A cause d'une particularité de la version Linux de CEF, il faut faire CTRL-C dans la console pour fermer l'application.

Lancement du backend comme daemon

Pour lancer le backend en mode daemon, se placer dans processing, et lancer dmnzq/tool/dmnzq backend/dmnzq.xprj. Vous pouvez alors, dans l'interface desktop, sélectionner Moteur de traitement local pour se connecter à ce backend.

Lancement de l'interface web

Dans le répertoire frontend/xdhbrwq, il y a un répertoire htdocs dont il faut placer le contenu à un endroit qui soit accessible à votre serveur httpd.

Pour lancer la CGI, se placer dans le répertoire frontend et lancer xdhbrwq/xdhbrwq XDHTML/orgnzqxdh. Puis ouvrir un navigateur web et saisir l'adresse correspondant au fichier orgnzq.html du répertoire htdocs mentionné ci-dessus. Remplir les champs, et sélectionner localhost à la place de q37.info.

Windows

Les binaires fournis sont destinés à Windows XP SP3 et supérieurs.

Prendre à l'adresse http://q37.info/download/computing/apps/orgnzq/ et désarchiver le package correspondant aux binaires Windows. Une fois chargé et désarchivé, suivre les instructions données dans le chapitre GNU/Linux (sauf ceux relatifs à la compilation). Selon la version de Windows, les / (slash) devront peut-être être remplacés par des \ (backslash).

Autres systèmes d'exploitation

Pour les systèmes d'exploitation POSIX pour lesquels il n'y a pas de version de CEF, il n'est possible que de lancer le backend et la CGI. Suivre les instructions concernant GNU/Linux, en ignorant tout ce qui concerne CEF. La compilation de l'utilitaire xdhcefq, qui intervient en dernier, échouera naturellement, mais tout le reste devrait être compilé et pouvoir être lancé en suivant les instructions dans la section consacrée à GNU/Linux.

Pour la version OS X, la procédure est détaillée ici.

Les nouveautés

Dans cette version, il y a deux principales nouveautés, détaillées dans les sections suivantes.

Nouveaux types de champs basés sur jQuery

La première nouveauté concerne la mise en œuvre de widgets basés sur jQuery, qui semblent jouir d'une certaine popularité. Ainsi, en plus du type texte de base, il y a trois nouveaux types, texte enrichi, date et heure, qui font appel à des widgets basés sur jQuery. Des plugins ont été développés pour gérer ces nouveaux types de champs. Un plugin n'est pas associé à un widget précis, mais à l’ensemble des widget manipulant des données de même nature. Ainsi, pour le texte enrichi, c'est le widget CKEditor qui est utilisé, mais on pourrait utiliser jQuery TE à la place, tout en utilisant le même plugin, les deux widgets manipulant des données au format HTML. Par contre, si l'on voulait utiliser un widget qui manipulerait des données au format markdown, il faudrait développer un nouveau plugin.

Concernant le type texte enrichi basé sur du HTML, les données correspondantes sont malheureusement mal affichées dans Firefox à cause de ceci. Vu la popularité de ce navigateur, ainsi que le fait que la fonctionnalité incriminée soit considérée comme obsolète dans XSLT 2.0, j'ai cherché une alternative, mais n'est malheureusement encore rien trouvé. Depuis que la dernière version de Microsoft Edge, celle fournie avec la dernière mise à jour de Windows 10 (version 1607), est capable d'afficher correctement la version Web de cette application, cela fait de Firefox le seul navigateur Web graphique moderne à poser problème…

Les onglets

La seconde nouveauté concerne les onglets. Cette application devant ultérieurement offrir la possibilité de créer des champs de type fiche, c'est-à-dire d'insérer dans une fiche une référence à une ou plusieurs autres fiches (faire du relationnel en quelque sorte), l'idée est d'avoir, d'une part, la fiche en cours de saisie, celle dans laquelle on voudrait référencer une ou plusieurs fiches, dans un onglet et, d'autre part, une liste de fiches, parmi lesquelles on sélectionnerait les fiches à référencer, dans un autre onglet. Bien sûr, ce n'est qu'un des usages envisageables des onglets.

Accessoirement, on peut réorganiser les onglets par drag & drop.

Le framework

Bien que ce n'en fût pas l'objet, les précédents journaux ont de nombreux commentaires portant sur le framework sur lequel s'appuie cette application, notamment pour affirmer, généralement de manière péremptoire, qu'il existe de meilleures manières et/ou des frameworks plus adaptés pour réaliser ce que je réalise à l'aide de ce framework. Comme je suis toujours à l'affût du meilleur outil pour réaliser une tâche, et comme suggéré dans l'un des commentaires, j'ai l'intention de documenter petit à petit, au fur et à mesure des journaux, les différents concepts mis en œuvre dans ce framework, histoire d'avoir des éléments concrets sur lesquels s'appuyer pour alimenter un éventuel débat. Bien que j'ai commencé une telle documentation, sa rédaction n’en est pas suffisamment avancée pour l'inclure dans ce journal ; j'espère pouvoir l'inclure dans le prochain.

En attendant, je remets ici les liens sur de précédents journaux dans lesquels j'avais déjà abordé certains points concernant le framework, notamment la technologie XDHTML, et la gestion des arguments de la ligne de commande ; leur mise en œuvre dans cette application les éclairera peut-être d'une lumière nouvelle…

  • # Erreur lien 'technologie XDHTML'.

    Posté par (page perso) . Évalué à 4.

    Malgré mes multiples relectures, j'ai laissé passé une erreur sur le pénultième lien, celui sur la technologie XDHTML. Voici le lien correct.

    Développeur freelance.

  • # chromium only

    Posté par . Évalué à 6.

    Avant je ne comprenais pas tes technologies, mais au moins tu affichais un objectif clair : avant tout répondre aux besoins de tes clients, même si c'est au prix d'une solution imbitable.

    Aujourd'hui on apprend que ça ne permet de générer que des interfaces web incompatibles avec la plupart des navigateurs, ce qui serait rédhibitoire pour n'importe quel client. Maintenant je ne comprends ni tes technologies, ni tes objectifs…

    Membre de l'april, et vous ? http://www.april.org/adherer

    • [^] # chromium, but not only

      Posté par (page perso) . Évalué à 3. Dernière modification le 06/08/16 à 09:08.

      Avant je ne comprenais pas tes technologies, mais au moins tu affichais un objectif clair : avant tout répondre aux besoins de tes clients, même si c'est au prix d'une solution imbitable.

      Ce n'est pas parce que c'est atypique que c'est imbitable. Et si tu m'indiquais précisément ce qui te semble imbitable, je me ferais un plaisir de te fournir les explications pour te le rendre bitable. Et ça me donnerais de précieuses indications sur ce que je dois mettre dans la documentation que je suis en train de rédiger.

      Aujourd'hui on apprend que ça ne permet de générer que des interfaces web incompatibles avec la plupart des navigateurs, ce qui serait rédhibitoire pour n'importe quel client. Maintenant je ne comprends ni tes technologies, ni tes objectifs…

      Je me suis peut-être mal exprimé, mais, au contraire, depuis la mise à jour de Microsoft Edge, l'interface web fonctionne avec tous les navigateurs web graphiques modernes que j'ai pu essayer. Avec la démonstration en ligne, il y a moyen de s'en rendre compte par soi-même. Il y a juste Firefox qui pose problème dans certains cas, comme je l'ai expliqué…

      Développeur freelance.

      • [^] # Re: chromium, but not only

        Posté par . Évalué à 5.

        Ce n'est pas parce que c'est atypique que c'est imbitable

        Imbitable n'était pas le bon mot, disons qu'elle n'est pas pour l'instant réutilisable par quelqu'un d'autre que toi : quel que soit le besoin, il sera moins coûteux de créer une nouvelle appli basée sur des technologies connues que d'investir dans la tienne.

        interface web fonctionne avec tous les navigateurs web graphiques modernes

        Je ne sais pas quels sont tes clients, mais pour les miens « moderne » signifie plutôt « moins de 3 ans » que « moins de 3 semaines ». Et une incompatibilité avec firefox et internet explorer pour windows < 10 est invendable.

        Tu as visiblement la chance d'avoir des clients qui ne s'intéressent pas à la technique et qui deviennent captifs puisque tu es le seul à pouvoir maintenir ton code, mais c'est de moins en moins la réalité du marché. Du coup je ne comprends pas l'objectif de ton POC, parce que je n'ai aucun doute que ça va fonctionner et que tu vas pouvoir l'utiliser pour tes clients, mais pourquoi le rends-tu public ?
        - tu as déjà expliqué dans les commentaires des journaux précédents que tu ne visais pas un usage pour les projets communautaires
        - maintenant tu sembles indiquer que même pour des projets de commande tu t'adresses à un marché très restreint

        Je pense que tu as raison de continuer, visiblement ça peut te permettre d'avoir un avantage concurrentiel dans ton marché, mais je ne comprends pas quel est ton but en communiquant à ce sujet dans des journaux sur linuxfr.org.

        Membre de l'april, et vous ? http://www.april.org/adherer

        • [^] # Re: chromium, but not only

          Posté par (page perso) . Évalué à 3.

          Ce n'est pas parce que c'est atypique que c'est imbitable

          Imbitable n'était pas le bon mot, disons qu'elle n'est pas pour l'instant réutilisable par quelqu'un d'autre que toi : quel que soit le besoin, il sera moins coûteux de créer une nouvelle appli basée sur des technologies connues que d'investir dans la tienne.

          interface web fonctionne avec tous les navigateurs web graphiques modernes

          Je ne sais pas quels sont tes clients, mais pour les miens « moderne » signifie plutôt « moins de 3 ans » que « moins de 3 semaines ». Et une incompatibilité avec firefox et internet explorer pour windows < 10 est invendable.

          Je n'ai jamais développé d'application web pour mes clients, et je n'ai pas l'intention d'en développer. L'interface de l’application présentée ici montre clairement que je n'ai pas les compétences en HTML, CSS et consorts pour cela (c'est pour cela que la facilité de modification de l'interface est un point clef de la technologie que j'emploie). D'ailleurs, si un prospect me contacte pour me demander de développer une application web, je lui dit sans équivoque qu'il lui sera facile de trouver développeur bien plus compétent et concurrentiel que moi pour cela.

          Le fait est que les interfaces desktop que je développe s'appuient sur des technos web, pour les raisons expliquées dans ce journal. Du fait de l'utilisation de ces technos web, il me semblait juste logique que le même code puisse servir pour développer une version web de l'interface. Et c'est cette hypothèse qui fait l'objet d'une des POC présentés ici. L'interface web, c'est juste un bonus ; cela ne fait pas officiellement partie de mes prestations…

          Tu as visiblement la chance d'avoir des clients qui ne s'intéressent pas à la technique et qui deviennent captifs puisque tu es le seul à pouvoir maintenir ton code, mais c'est de moins en moins la réalité du marché.

          Au contraire, c'est parce que mes clients s'intéressent à la technique qu'ils me contactent. Ils sont bien conscients que c'est parce que les développeurs classiques n'ont pas la maîtrise des technologies qu'ils utilisent qu'ils ne sont pas capables de leur fournir une application qui réponde à leurs besoins. Avec mon framework, parce que j'en ai la totale maîtrise, je ne suis pas soumis au bon vouloir d'un éditeur pour en dépasser les limites.

          Il vaut mieux une application développée dans une technologie soi-disant captive (mon framework, c'est quand même que du C++), mais qui réponde parfaitement aux besoins du client, qu'une application certes basée sur des technologies répandues, mais inutilisable à cause des limitations de ces technologies. Des clients dont les exigences sont telles que les technologies classiques ne peuvent y répondre sont peu nombreux, mais, d'un autre coté, comme on est peu de développeurs sur ce marché…

          Du coup je ne comprends pas l'objectif de ton POC, parce que je n'ai aucun doute que ça va fonctionner et que tu vas pouvoir l'utiliser pour tes clients, mais pourquoi le rends-tu public ?
          - tu as déjà expliqué dans les commentaires des journaux précédents que tu ne visais pas un usage pour les projets communautaires
          - maintenant tu sembles indiquer que même pour des projets de commande tu t'adresses à un marché très restreint

          Je n'ai pas trop compris ce que tu entends par viser un usage pour les projets communautaires.

          Concernant mon framework, du fait qu'il soit atypique et que la documentation est inexistante, il y a peu de chances que quelqu'un s'y intéresse ; je ne communique donc pas directement dessus. Par contre, une application telle que celle présentée ici, naturellement pas en l'état, est plus à même de susciter l'intérêt, voire de fédérer une communauté. Certes, il reste bien du travail pour que cette application soit utilisable, et c'est pour cela que j'insiste plus sur l'aspect POC que sur ses fonctionnalités. Mais, à terme, peut-être deviendra-t-elle un projet communautaire ? En tout cas, je n'y aurais rien à y redire…

          Je pense que tu as raison de continuer, visiblement ça peut te permettre d'avoir un avantage concurrentiel dans ton marché, mais je ne comprends pas quel est ton but en communiquant à ce sujet dans des journaux sur linuxfr.org.

          Suite à ces journaux, j'observe quand même quelques téléchargements de mes logiciels. Sans préjuger de l'intention des téléchargeurs, on peut quand même supposer que mes logiciels, et donc leur évolution, les intéressent, d'où ces journaux pour communiquer à leur sujet…

          Développeur freelance.

    • [^] # Re: chromium only

      Posté par (page perso) . Évalué à 2.

      C'est l'éternel « dialogue » entre le pragmatique et le dogmatique.

      PRAGMATIQUE — Je suis heureux : mon application fonctionne sur toutes les plateformes et n’a aucun bug connu.
      DOGMATIQUE — Mais la technologie employée est spécifiée sur du sable mouvant et le code est bourré de rustines immondes.
      PRAGMATIQUE — Aucune importance : ça marche.

      DOGMATIQUE — Je suis heureux : mon application colle pile poil aux ISO / RFC / etc.
      PRAGMATIQUE — Mais elle est très moche et il y a des bugs sur certaines plateformes.
      DOGMATIQUE — Aucune importance : elle respecte les standards.

      • [^] # Re: chromium only

        Posté par . Évalué à 2.

        le pragmatisme est aussi un dogme en soit donc je trouve l'utilisation du terme pragmatique en opposition de dogmatique ne fait pas de sens. Tu aurais du utiliser "PURISTE" à la place de dogmatique.

        • [^] # Re: chromium only

          Posté par . Évalué à 7.

          Bah, le problème est quand même surtout que la connotation des deux termes est différente. Dogmatique ou puriste, c'est plutôt négatif (sauf dans certaines communautés religieuses ou équivalent—je viens de me rendre compte que le librisme avait des propriétés communes avec les religions), alors que pragmatique, c'est plutôt positif. Dans un entretien d'embauche, si on vous demande votre qualité principale, vous êtes mal barré si vous répondez "dogmatique". Par contre, "pragmatique", c'est une qualité.

          Le paradoxe, c'est peut-être que la réalilté est exactement le contraire. Un informaticien qui se prétend pragmatique risque de multilier les mauvaises pratiques ; on accepte les erreurs de syntaxe ou les comportements indéterminés tant que ça compile et ça exécute correctement, on utilise des goto ou des variables globales parce que tant que ça marche c'est pas un problème, etc. D'un point de vue "scientifique", le pragmatisme peut réellement être un défaut.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.