URL: https://linuxfr.org/users/epeios/journaux/de-l-utilisation-des-technologies-web-dans-une-application-native
Title: De l’utilisation des technologies web dans une application native.
Authors: Claude SIMON
Date: 2015年08月21日T07:47:34+02:00
License: CC By-SA
Tags: 
Score: 10
# Introduction #
Une des particularités du *framework* *Epeios*, c'est de faciliter le codage d'utilitaires en ligne de commande comme [tmcq](http://linuxfr.org/users/epeios/journaux/tmcq-un-convertisseur-de-timecodes) et [dpkq](http://linuxfr.org/users/epeios/journaux/dpkq-un-piocheur-de-donnees). Concrètement, cela se traduit, par exemple, par le fait que de tels utilitaires prennent en charge les arguments de la ligne de commande sans que cela n'ait nécessité d'écrire la moindre ligne de code dédiée lors du codage de ces utilitaires, comme expliqué dans ce [journal](http://linuxfr.org/users/epeios/journaux/xppq-ou-une-autre-approche-de-la-gestion-des-arguments-de-la-ligne-de-commande). Dans le même esprit, le *framework* *Epeios* s'enrichit de fonctionnalités pour la prise en charge d'applications avec interface graphique. L'idée est de déporter un maximum de fonctionnalités dédiées à la gestion d'interfaces graphiques dans le *framework* même, de manière à ne pas avoir à les recoder pour chaque nouvelle application.
En outre, il ne s'agit pas seulement de simplifier le développement d'interfaces graphiques, mais également d'offrir à l'utilisateur un moyen simple de personnaliser au maximum l'interface d'une application sans avoir à en modifier le code source. Mettre les sources d'une application à disposition de l'utilisateur pour qu'il puisse l'adapter à ses besoins, c'est bien, mais lui offrir la possibilité de la personnaliser sans avoir à modifier ces sources (surtout qu'en l’occurrence, il s'agit de sources *C++*), c'est mieux.
 En fait, ce *framework* était déjà capable de prendre en charge la gestion d'interfaces graphiques. Je m’appuyais pour cela sur *XULRunner*, comme décrit dans ce [journal](http://linuxfr.org/users/epeios/journaux/xulrunner-et-c) (n.b. : le lien donné dans ce journal n'existe plus). Cependant, un [bug](http://bugzilla.mozilla.org/show_bug.cgi?id=1006402) rédhibitoire (pour moi) de *XULRunner*, et des doutes concernant la pérennité de *XULRunner*, m'ont poussé à l'abandonner, et à explorer d'autres technologies en vue de le remplacer.
# *HTML5* #
Comme, dans ce même [journal](https://linuxfr.org/users/epeios/journaux/xulrunner-et-c), on m'avait [bassiné](http://linuxfr.org/users/epeios/journaux/xulrunner-et-c#comment-1321182) avec *Qt*, je résolus d'essayer ce dernier. Mais je n'ai pas persévéré dans cette voie, leur approche ne me convenant pas. Je rappelle que je cherchais uniquement une technologie pour gérer les interface graphiques, ce qui était l'unique usage que j'avais de *XULRunner*, bien qu'il soit capable de beaucoup plus ; pour toute la partie traitement, j'ai le *framework* *Epeios*.
Coïncidence, à peu près au même moment fût publiée la version finalisée de *HTML5*, et j’entrepris donc d'explorer cette piste. Au final, pour l'usage que je comptais en faire, *HTML5* s'est révélé être très proche de *XUL* (langage dont *XULRunner* est le moteur de rendu) ; je pouvais donc réutiliser pas mal d'outils que j'avais développés dans le cadre de mon utilisation de *XULRunner*.
# *Chromium Embedded Framework* #
Comme mon but était de trouver des technologies pour développer des applications natives (j'avais déjà ce qu'il me fallait pour développer des applications web), il me fallait trouver un moyen d'*exécuter* *HTML5* dans ce contexte. Comme j'avais déjà *Qt* d’installé, j'ai essayé *QtWebKit*, mais certaines limitations de ce composant, ainsi que le fait de recourir à tout l'environnement de développement *Qt* pour n'utiliser que ce composant m’apparaissait totalement disproportionné, je me suis mis à la recherche d'un équivalent.
Qui dit *HTML(5)*, dit *JavaScript*. La même chose vaut pour *XULRunner*, comme on me l'avait fait remarquer toujours dans ce fameux [journal](http://linuxfr.org/users/epeios/journaux/xulrunner-et-c). J'y ai cependant détaillé les raisons pour lesquelles je préférais utiliser *C++*, au détriment de *JavaScript*, et c'est pour ces mêmes raisons que je j'utiliserais *C++* avec *HTML5*. Restait, comme écrit, à trouver le moyen d’exécuter *HTML5* dans un contexte natif. Ce moyen, je l'ai trouvé avec *Chromium Embedded Framework* *([CEF](http://bitbucket.org/chromiumembedded/cef))*.
# *xdhcefq* #
Un problème que j'avais lorsque j'utilisais *XULRunner*, c'est que ses fichiers d’en-tête *polluaient* les sources de mes applications. Pour éviter ce désagrément, je résolus de développer un utilitaire qui prenait en charge toutes les interactions avec *[CEF](http://bitbucket.org/chromiumembedded/cef)*, le code proprement dit de traitement de l'interface graphique étant déporté dans une bibliothèque, bibliothèque dont le code source n'aura donc pas à inclure de fichier d'en-tête de *[CEF](http://bitbucket.org/chromiumembedded/cef)*. Cet utilitaire, c'est *[xdhcefq](http://q37.info/computing/epeios/tools/xdhcefq/)*.
A noter que les exemples d’utilisation qui sont donnés pour *[CEF](http://bitbucket.org/chromiumembedded/cef)* s'appuient sur son *API* *C++*. Comme l'utilisation de cet *API* nécessitait la compilation de bibliothèques supplémentaires, j'ai préféré utiliser l'*API* *C*, qui ne nécessitait pas ces bibliothèques supplémentaires. Mais la mise en œuvre de *[CEF](http://bitbucket.org/chromiumembedded/cef)* est nettement plus compliquée en passant par la version *C* de l'*API*. Cependant, comme je n'ai à me préoccuper de *[CEF](http://bitbucket.org/chromiumembedded/cef)* que lors du développement de *[xdhcefq](http://q37.info/computing/epeios/tools/xdhcefq/)*, et que, pour le développement des applications proprement dites, je n'aurais plus à me préoccuper de l'*API* (*C* ou *C++*) de *[CEF](http://bitbucket.org/chromiumembedded/cef)* (ce qui est, je le rappelle, justement l'objet de *[xdhcefq](http://q37.info/computing/epeios/tools/xdhcefq/)*), j'ai préféré recourir à l'*API* *C*, car elle moins contraignante.
# *xdhdq* #
L'ensemble des technologies concernant la gestion d'interfaces graphiques dans le *framework* *Epeios* est regroupé sous le vocable *[XDHTML](http://q37.info/computing/epeios/xdhtml/)*. Ci-après, vous allez trouver les principes de base de cette technologie. Pour rendre cela plus concret, une petite application triviale, s'appelant *[xdhdq](http://q37.info/computing/epeios/apps/xdhdq)*, a été développée. Cette application prend la forme d'une bibliothèque dynamique, qui est chargée par *[xdhcefq](http://q37.info/computing/epeios/tools/xdhcefq/)*. C'est de cette application que les exemples ci-dessous sont tirés.
Si vous désirez approfondir, *[xdhdq](http://q37.info/computing/epeios/apps/xdhdq)* est librement téléchargeable à partir de sa page dédiée. Elle vient avec *[xdhcefq](http://q37.info/computing/epeios/tools/xdhcefq/)*, qui est indispensable pour la faire tourner. Elle est disponible pour *GNU/Linux*, *OS X* et *Windows*, avec architecture *IA-32* et *AMD64*.
# Génération des composants *HTML* de l'interface graphique #
Le code *HTML* de l'interface n'est pas directement généré par l'application, mais est le résultat d'une transformation *XSL* sur des données *XML* fournies par l'application. Les fichiers *XSL* utilisé pour la transformation sont spécifiés dans le [fichier de configuration](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/xdhdqxdh.xcfg) de l’application. Des exemples de tels fichiers *XSL* sont visibles [ici](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/XSL/) (ce sont ceux suffixés par `Layout.xsl`).
# Gestion de l'accessibilité des éléments #
Pour gérer *l'accessibilité* d'un élément (c'est-à-dire le fait qu'un élément ait un attribut comme `hidden` ou `disabled` de défini ou non) se fait à l'aide d'un élément et d'un attribut maison (respectivement `xdh-cast` et `data-xdh-cast`). L'attribut `data-xdh-cast` est affecté aux éléments concernés lors de l'opération décrite juste au-dessus, et la définition des éléments `xdh-cast` se fait, comme précédemment, à partir d'une transformation *XSL* sur des données *XML* générées par l’application. Les fichiers *XSL* utilisés pour cette transformation sont également spécifiés dans le [fichier de configuration](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/xdhdqxdh.xcfg) de l’application, et des exemples de tels fichiers sont également visibles [ici](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/XSL/) (ce sont ceux suffixés par `Casting.xsl`).
Voici un exemple de déclaration (issu de [PrologLayout.xsl](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/XSL/PrologLayout.xsl)) :
``` xml
	<select data-xdh-cast="PredefinedProjectsCast">
		...
	</select>
```
Et la définition correspondante (issue de [PrologCasting.xsl](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/XSL/PrologCasting.xsl)):
``` xml
	<xsl:template match="ProjectType">
		<xsl:variable name="Type" select="."/>
		<xsl:choose>
			<xsl:when test="$Type='New'">
				<xdh-cast id="PredefinedProjectsCast" kind="Hide"/>
			</xsl:when>
			<xsl:when test="$Type='Predefined'">
				<xdh-cast id="PredefinedProjectsCast" kind="Plain"/>
			</xsl:when>
			<xsl:when test="$Type='Remote'">
				<xdh-cast id="PredefinedProjectsCast" kind="Hide"/>
			</xsl:when>
		</xsl:choose>
	</xsl:template>
```
# Gestion d’événements #
La gestion d’événement se fait grâce aux attributs `data-xdh-onevent`, pour définir un seul gestionnaire d’événement, ou `data-xdh-onevents` (avec un `s` à la fin), pour en définir plusieurs. Les événements déclenchent une action définie dans un *callback* écrit en *C++* et pourvu d'un identifiant unique. La définition d'un gestionnaire d’événement consiste donc à indiquer un événement (`mouseleave`, `click`...) ainsi que l'identifiant de l'action à lui associer. Par exemple (tiré de [MainLayout.xsl](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/XSL/MainLayout.xsl)) :
``` xml
<fieldset data-xdh-onevents="(mouseenter&#124;HideFacetiousButton)&#124;(mouseleave&#124;ShowFacetiousButton)">
````
On peut omettre la spécification de l’événement, auquel cas ce sera l’événement par défaut qui sera utilisé (généralement `click`).
Il existe certains événements prédéfinis, qui peuvent prendre plusieurs paramètres. Par exemple (issu de [PrologLayout.xsl](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/XSL/PrologLayout.xsl)) :
``` xml
<button data-xdh-onevent="(OpenFile&#124;DisplayProjectFilename&#124;(#plgSelectProjectFile#&#124;.xprj))">
````
Un clic (événement qui n'est pas spécifié, car c'est l’événement par défaut pour cet élément) sur ce bouton provoquera l'affichage d'une sélecteur de fichier (action prédéfinie `OpenFile`), avec, pour titre, le texte correspondant à l'identifiant `plgSelectProjectFile` (qui est défini dans la section `Locale` du [fichier de configuration](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/xdhdqxdh.xcfg)), et `.xprj`comme filtre d'extension. Une fois le sélecteur fermé, l’action `DisplayProjectFilename` (qui est une action classique, c'est-à-dire qui correspond à un *callback* *C++*) est lancée.
# Composants *HTML* et *JQuery* #
De nombreux composants *HTML* d'interface graphique s'appuient sur *JQuery*, et, de ce fait, ont toujours quasiment le même code *JavaScript* d’instanciation. Pour éviter d'avoir à taper ce code, on peut recourir à l'attribut `data-xdh-widget`, par exemple de la manière suivante (tiré de [FieldsLayout.xsl](http://hg.savannah.gnu.org/hgweb/epeios/file/951697d1519c/apps/xdhdq/frontend/XDHTML/XSL/FieldsLayout.xsl)) :
``` xml
<textarea data-xdh-widget="ckeditor&#124;enterMode : CKEDITOR.ENTER_BR, linkShowTargetTab: false, language: '#fieldsLanguage#', startupFocus : true,&#124;val\(\)&#124;ckeditor\(\).editor.focus\(\)">
```
Cela crée un composant [ckeditor](http://ckeditor.com/), avec certains paramètres propres à ce composant (situés entre le premier et le second `&#124;` ; voir le site du composant pour leurs significations). Comme la récupération du contenu de ce composant, ainsi que la manière de lui donner le *focus*, ne se fait pas de façon classique, le code *JavaScript* adéquat est précisé (respectivement `val()` et `ckeditor().editor.focus()` ; les `\`servent à échapper les caractères `(`et `)`).
# Et maintenant ? #
Il y a principalement deux projets en cours relatifs à la technologie *[XDHTML](http://q37.info/computing/epeios/xdhtml/)*. Le premier consiste en une véritable application, à titre de *POC* évoluée, mais pleinement fonctionnelle et d'une réelle utilité. Le second consiste à développer l'équivalent de *[xdhcefq](http://q37.info/computing/epeios/tools/xdhcefq/)*, mais pour les applications web. L'idée et d'avoir un seul et même code *C++*, et pour la version native, et pour la version web d'une application (il restera néanmoins possible, si désiré, d'adapter l'interface pour l'une ou l'autre type d'application).
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/users/epeios/journaux/de-l-utilisation-des-technologies-web-dans-une-application-native.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/users/epeios/journaux/de-l-utilisation-des-technologies-web-dans-une-application-native.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>