FR 2976373 A1 20121214 FR 1155131 A 20110610 DOMAINE TECHNIQUE GENERAL La présente invention concerne un procédé de développement d'un portail 5 Web, le portail Web étant mis en oeuvre localement par un navigateur d'un dispositif. Elle concerne également un système mettant en oeuvre le procédé et un produit programme d'ordinateur correspondant. ETAT DE L'ART 10 On connaît des décodeurs dans le domaine des télécommunications. Un décodeur est un dispositif électronique, relié à un téléviseur, qui convertit des signaux audiovisuels (parfois codés et transmis habituellement par câble coaxial, par ligne téléphonique ou par satellite) sous une forme leur permettant d'être correctement reçus et traités par le téléviseur. Il est 15 ainsi nécessaire d'utiliser un décodeur pour avoir accès à des chaînes ou à des programmes de télévision qui ne peuvent être disponibles qu'à certaines conditions fixées par un diffuseur ou un distributeur. En général, le fonctionnement du décodeur est géré grâce à un portail (« portal » en anglais), affiché au moins en partie sur le téléviseur, et 20 permettant notamment une interaction avec un utilisateur du décodeur. Les portails connus des décodeurs connus utilisent la technologie Web, à savoir une technologie fondée sur l'utilisation des hypertextes et des données hypermédias (c'est-à-dire une extension de l'hypertexte à des données multimédias, permettant d'inclure des liens entre des éléments 25 textuels, visuels et sonores). La technologie Web permet notamment la recherche d'information dans une arborescence, l'accès à cette information et sa visualisation, grâce à un navigateur Web, c'est-à-dire un logiciel capable d'exploiter les ressources hypertextes et hypermédias. 30 Un portail connu pour un décodeur connu se présente ainsi comme un site Web, où sont stockées des données accessibles par le navigateur Web, et proposant notamment des liens entre des informations et des fonctionnalités. Le portail est donc constitué d'un point d'entrée (une page d'accueil) et d'un ensemble de modules qui interagissent entre eux et/ou répondent à des évènements extérieurs. Un portail connu est en général créé en utilisant des langages connus 5 de programmation Web, comme par exemple - le langage HTML (HyperText Markup Language), c'est-à-dire un langage de balisage de texte, qui permet la création de documents hypertextes affichables par le navigateur Web ; - le langage Javascript, c'est-à-dire un langage de rédaction de 10 script (un script est un programme constitué d'une suite de commandes dispensant les utilisateurs de les saisir, et permettant d'effectuer une fonction particulière ou de contribuer à l'exécution d'un autre programme), le langage de rédaction Javascript étant notamment destiné aux utilisateurs non 15 spécialistes, et permettant d'intégrer des instructions préprogrammées dans la construction d'un document Web ; - le langage PHP (PHP Hypertext Preprocessor) ; - les feuilles de style en cascade (ou Cascading Style Sheets (CSS)), c'est-à-dire des fichiers texte qui contiennent une liste 20 de marqueurs HTML, ainsi que le formatage associé à chacun, et qui permettent de définir avec exactitude la police, la taille, la couleur et la disposition des éléments d'une page Web les uns par rapport aux autres... 25 En pratique, si un diffuseur ou un distributeur désire développer un portail pour un décodeur, il doit monter en interne une équipe dédiée de développement Web, ou externaliser le développement Web s'il ne possède pas ce type de connaissances ou s'il ne veut pas le développer en interne. De plus, le développement d'une nouvelle fonctionnalité par un 30 développeur nécessite la création de pages de tests afin de vérifier le bon fonctionnement du portail. Une fois le développement effectué, l'intégrateur doit lui aussi créer une page de test et il en va de même pour la partie validation. Ainsi, chaque évolution ultérieure du portail nécessite une étape supplémentaire d'intégration et une étape supplémentaire de validation, qui ne sont pas toujours aisées et qui demandent par conséquent du temps. De même, une correction de bogue dans le portail ne peut pas être partagée avec d'autres portails, et l'on doit apporter une correction à chaque bogue de chaque portail. PRESENTATION DE L'INVENTION L'invention propose de pallier au moins un de ces inconvénients, en facilitant le développement de portails. A cet effet, on propose selon l'invention un procédé de développement d'un portail Web, le portail Web étant mis en oeuvre localement par un navigateur d'un dispositif, le procédé étant caractérisé en ce qu'il comporte - une étape de configuration du portail, selon laquelle une interface d'un ordinateur permet la sélection et l'organisation d'un ensemble de modules de fonctionnalité et/ou de modules de gestion d'évènement formant le portail Web, un code stocké sur un serveur étant associé à chacun desdits modules ; - une étape de compilation, selon laquelle un processeur de l'ordinateur génère, à partir de l'ensemble, un fichier d'instructions pouvant être mises en oeuvre par le navigateur ; et - une étape de déchargement, selon laquelle le processeur décharge le fichier d'instructions et un groupe de codes associés aux modules sur le dispositif. L'invention est avantageusement complétée par les caractéristiques suivantes, prises seules ou en une quelconque de leur combinaison 25 techniquement possible : - la sélection des modules de fonctionnalité et/ou des modules de gestion d'évènement s'effectue à partir d'une bibliothèque de modules ; - le processeur génère le fichier d'instructions par l'intermédiaire du serveur comportant un module PHP, le fichier étant en format d'objet orienté web 30 utilisant des technologies W3C, préférentiellement HTML, JavaScript, CSS, XML, XSLT ou CGI ; - chaque module est construit sous une même structure standard ; - le fichier d'instructions comporte des instructions selon lesquelles les évènements sont gérés par une pile de modules de gestion d'évènement ou de modules de fonctionnalités ; et - le procédé comporte de plus une étape de test du fichier d'instructions 5 avant l'étape de déchargement. L'invention concerne également un système mettant en oeuvre le procédé, et un produit programme d'ordinateur correspondant. L'invention présente de nombreux avantages. Elle permet à un diffuseur ou à un distributeur de développer un portail 10 par exemple pour un décodeur, sans monter en interne une équipe dédiée de développement Web, ni externaliser ce développement Web. L'invention permet en effet un détachement total des aspects logiciels et des langages de programmation Web, et permet donc à tout utilisateur de créer un portail, sans avoir de connaissances en développement Web. L'invention permet 15 notamment de modifier rapidement le contenu d'un portail sans nécessité de connaissances en développement web. L'invention permet de développer un portail à partir de briques logicielles déjà construites, ce qui permet de mutualiser les développements de fonctionnalités, les corrections de bogues, et d'ajouter de nouvelles 20 fonctionnalités facilement. L'invention permet notamment de mutualiser le développement entre développeurs, intégrateurs, et valideurs, notamment en ce qui concerne les pages de tests. L'invention permet des ajouts, des suppressions, et des modifications 25 des éléments constitutifs d'un portail, de manière dynamique, ce qui permet par exemple de tester rapidement des options différentes pour des fonctionnalités. Un portail développé par un procédé selon l'invention ne nécessite pas de serveur PHP pour fonctionner. 30 Il présente également des gains en performance d'affichage. PRESENTATION DES FIGURES D'autres caractéristiques, buts et avantages de l'invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels : - la figure 1 représente schématiquement un mode de réalisation possible d'un système selon l'invention ; - la figure 2 représente schématiquement une mise en oeuvre possible d'un procédé selon l'invention ; - la figure 3 représente schématiquement une structure possible d'une base 10 de données d'un serveur d'un système selon l'invention ; - la figure 4 représente schématiquement une structure possible d'un répertoire contenant un code source pour un portail ; - les figures 5 à 10 représentent schématiquement des formulaires possibles d'une interface d'un ordinateur d'un système selon l'invention, 15 pour le développement d'un portail ; - la figure 11 représente schématiquement une étape de génération d'un fichier d'instructions à partir d'un ensemble de modules et de codes ; - la figure 12 représente schématiquement une gestion possible d'évènement sur un dispositif d'un système selon l'invention ; et 20 - la figure 13 représente schématiquement un formulaire possible d'une interface d'un ordinateur d'un système selon l'invention, pour la création d'un module ; Sur l'ensemble des figures, les éléments similaires portent des références numériques identiques. 25 DESCRIPTION DETAILLEE Les figures 1 et 2 représentent schématiquement un procédé possible selon l'invention mis en oeuvre sur un système possible selon l'invention, le système comportant un dispositif 1, un ordinateur 2 et un serveur 3. Un procédé possible de développement d'un portail Web comporte 30 principalement - une étape S1 de configuration du portail, - une étape S2 de compilation, et - une étape S4 de déchargement d'un fichier d'instructions et d'un groupe de codes sur le dispositif 1, le dispositif comportant un navigateur utilisant la technologie Web et pouvant mettre en oeuvre le fichier d'instructions et le groupe de codes. En effet, le portail Web est destiné à être mis en oeuvre localement par le navigateur 11 Web du dispositif 1 lorsque le dispositif 1 est en fonctionnement normal. Le dispositif 1 peut être de tout type, comme par exemple un décodeur (« set top box » (STB) en anglais), un ordinateur, une passerelle (ou « gateway » en anglais), un compteur électrique, ou tout autre système embarqué possédant un navigateur. Le dispositif 1 comporte ainsi notamment une interface 12. L'interface 12 du dispositif 1 peut comprendre un écran et/ou une série de voyants lumineux et/ou un clavier et/ou une souris et/ou une télécommande (comportant par exemple un pavé numérique et/ou des touches colorées, avec les couleurs rouge, vert, jaune et bleu par exemple). Le dispositif 1 est autonome en ce sens qu'il n'est pas relié, en fonctionnement normal, à un serveur distant du type du serveur 3. Par exemple lorsque le dispositif 1 est un décodeur, il est, en fonctionnement normal, relié à un téléviseur et convertit des signaux audiovisuels (parfois codés et transmis habituellement par câble coaxial, par ligne téléphonique ou par satellite) sous une forme leur permettant d'être correctement reçus et traités par le téléviseur. Le serveur 3 du système est équipé - d'un serveur 32, utilisant la technologie Web, de préférence http (HyperText Transfer Protocol), - d'un module 33 PHP (PHP : Hypertext Preprocessor), ainsi que - d'une base 31 de données (du type « MySQL » par exemple). L'ordinateur 2 comporte classiquement une interface 21 et un processeur 22. Le processeur 22 comporte tous les moyens classiques de mémoire, de communication et de calcul pour la mise en oeuvre du procédé selon l'invention, et n'est donc pas repris en détail dans la suite de la présente description. L'interface 21 comporte un écran et/ou des formulaires pouvant être affichés sur l'écran (et décrits plus en détail dans la suite de la présente description) et/ou un clavier et/ou une souris et/ou une télécommande de dispositif 1. Lors de l'étape S1, l'interface 21 de l'ordinateur 2 permet la sélection et l'organisation d'un ensemble E1 formant le portail Web et constitué 10 - de modules 211 de fonctionnalité, et/ou - de modules 212 de gestion d'évènement souhaités par un utilisateur pour le portail. L'ensemble El correspond à un squelette du portail Web souhaité sur le dispositif 1, et les modules 211 et 212 correspondent à des actions 15 exécutables notamment via le navigateur 11 du dispositif 1. On explicite ici la différence entre un module 211 et un module 212. Un module 211 de fonctionnalité est exécuté par le navigateur 11 lorsqu'une fonction de démarrage (fonction « start » en anglais) est appelée par le navigateur 11. On peut également prévoir qu'un module 211 soit 20 exécuté via un autre module 211 ; dans ce cas, le module appelant l'exécution de l'autre module est un module du type « menu » (comme le menu principal du portail par exemple). Des exemples non limitatifs de modules 211 sont ainsi : des pages d'information sur le dispositif 1 (affichage du numéro de série, ...), des 25 pages de configuration d'options audio, ... Un module 212 de gestion d'évènement est exécuté par le navigateur 11 lorsqu'il y a apparition d'au moins un évènement donné. Les modules 212 sont traités plus en détail dans la suite de la présente description, mais on précise ici qu'un évènement est par exemple une pression d'une touche 30 sur la télécommande de l'interface 12 du dispositif 1, l'extraction d'une carte électronique du dispositif 1 ou l'arrivé d'un nouveau signal au niveau du dispositif 1. Un module 212 est non accessible par le menu, comme la gestion du volume sonore par exemple. En lien avec les modules 211 et 212, la base 31 de données du serveur 3 stocke des tables 321, 322, 323 et 324 représentées sur la figure 3. Chaque table 321, dénommée par exemple scp_project, contient les 5 informations globales pour un projet de portail donné. Certaines des informations ne sont pas paramétrables et ont donc un usage exclusivement interne, alors que d'autres permettent de paramétrer chaque projet de portail. Les informations peuvent être saisies par un utilisateur grâce à des 10 formulaires de l'interface 21, comme décrit dans la suite de la présente description. Chaque table 321 comporte ainsi - un identifiant du projet (projectld) - un nom du projet (projectName) 15 - une version du portail (portal Version) - une langue du portail (defaultLanguage). La table 321 permet d'inclure éventuellement un module 212 dans le projet. Elle comporte ainsi une ligne (eventModuleList) qui contient la liste des modules qui ne sont déclenchés que par des évènements. 20 La table 321 permet d'inclure éventuellement un module 211 dans le projet. Elle comporte ainsi une ligne (startingModuleld) permettant de spécifier le premier module qui sera lancé à l'exécution du portail, et qui pourra également appeler d'autres modules. Elle contient aussi une ligne (templateld) permettant d'indiquer quel 25 style d'interface (template en anglais) est utilisé par le projet. Les styles sont des modules qui possèdent des fonctions supplémentaires par rapport aux autres modules 211 ou 212. Chaque style est regroupé dans une table 323, par exemple dénommée scp_template, qui permet de sauvegarder les différentes informations du style, tel que son 30 identifiant (Id), son nom (name), son chemin d'accès (path), ainsi que ses paramètres (param). Chaque table 322, dénommée par exemple scp_module, contient les informations permettant de créer et configurer les modules 211 ou 212. Comme on l'expliquera plus en détail dans la suite, chaque module 211 ou 212 possède un identifiant (moduleld) et un certain nombre de paramètres. Chaque module 211 ou 212 est ainsi répertorié dans la base 31 de données. Chaque table 324, par exemple dénommée scp_icons, permet de simplifier l'utilisation des icônes au sein de la base de donnée 31, en associant au chemin d'accès de l'icône un identifiant qui pourra être ensuite utilisé dans les paramètres de modules 211 ou 212. Les icônes sont également liées à un style. La base 31 contient de plus des liens vers des codes 42 sources, contenus dans des fichiers 420, chaque code 42 correspondant à un module 211 ou 212. A cet effet, comme le montre la figure 4, chaque code 42 est copié dans un répertoire 420 spécifique du serveur 3. Le répertoire 420 est 15 dénommé par le nom du module 211 ou 212. Le code 42 est copié sous la forme d'un fichier source du module 211 ou 212, au format Javascript ou HTML. Chaque fichier de code 42 est dénommé par le nom du module 211 ou 212, préférentiellement suivi du numéro de version du module, par exemple 20 sur trois caractères. L'utilisateur peut donc sélectionner une version particulière du module 211 ou 212 en fonction de l'architecture du dispositif 1 (archi V1 ou archi V2 par exemple). Bien entendu, le répertoire spécifique 420 peut contenir d'autres répertoires, pour des ressources 41 spécifiques du module (icônes, images, sons, etc.). 25 On donne ci-après un exemple possible de mise en oeuvre de l'étape S1. Lors de l'étape S1, l'utilisateur indique un identifiant d'un projet de portail dans l'interface 21. A cet effet, l'interface 21 comporte un formulaire HTML connu de 30 l'homme du métier. Les formulaires HTML utilisent des fonctions connues HTML exécutées par l'ordinateur 2, comme par exemple la fonction suivante qui permet de récupérer un objet de type « fenêtre ». UI U tli nindo:a(.?idth, h ight, opacitl-) Classiquement une fenêtre comporte trois zones distinctes : - une zone de titre, - un contenu, et - un pied de page. Les fonctions HTML ci-dessous permettent de compléter chacune de ces zones. indo.updatTit1(tit1.); ?aindo. updateCont,nt (content ; indo- updat Foot r(foot_r); On connaît également une fonction HTML permettant de positionner la fenêtre dans l'interface 21. Les valeurs « top » et « left » doivent être indiquées en nombre de 15 pixels ou bien en utilisant une chaine de caractères 'CENTER'. On connaît également les fonctions d'affichage et de masquage d'une fenêtre. :i.. :-1io.; (optio 1 ) ; ;aindow. hile ( ) ; 20 Les options de la fonction show peut être toute association des valeurs 'TITLE', 'CONTENT', et 'FOOTER', séparées par le caractère '1'. Un exemple de formulaire HTML permettant à l'utilisateur d'indiquer un identifiant d'un projet de portail est représenté sur la figure 5. Le formulaire de l'interface 21 comporte notamment des champs 101, 25 102, 103 et 104. Le champ 101 est le nom courant du portail. Les champs 102 permettent de modifier ou de sélectionner - le nom du portail (« Portal name »), - le numéro de version du portail (« Portal version number »), 30 - un module (« Live module ») exécuté au démarrage du portail (champ non renseigné sur la figure 5), ainsi que - le style du module (« Template module ») à appliquer. Les champs 103 permettent de configurer le style à appliquer, comme par exemple : - la taille du menu (« Menu size »), - l'opacité du menu (« Opacity »), ainsi que - la couleur (« color ») utilisée. Le champ 104 « Save » permet une sauvegarde des configurations. Les informations saisies dans les champs 101 à 103 sont donc copiées dans la table 321 correspondante sur le serveur 3. Toujours lors de l'étape S1, l'interface 21 permet la sélection et 10 l'organisation de l'ensemble El de modules 211 ou 212 formant le portail Web. A cet effet, l'interface 21 comporte un formulaire HTML d'arborescence du portail (« portal tree »), par exemple conforme à celui représenté sur la figure 6. 15 Il est possible à l'utilisateur d'obtenir l'affichage du formulaire de l'arborescence du menu principal du portail, notamment en sélectionnant un onglet 20 (sélection par la souris de l'interface 21 ou par pression sur la touche jaune sur la télécommande de l'interface 21 par exemple). Comme on peut le constater sur la figure 6, le formulaire HTML 20 comporte notamment des champs 201 à 210. Le champ 201 est le titre du formulaire, présentant l'arborescence du portail sous forme de tableau comportant des colonnes. Le tableau montre donc une partie El' de l'ensemble El, ladite partie El' étant constituée de modules 211 de fonctionnalité souhaités par 25 l'utilisateur. La colonne 202 correspond à un numéro identifiant chaque module 211 de fonctionnalité. La colonne 203 permet de supprimer un module du portail. Cette suppression est préférentiellement définitive. 30 La colonne 205 montre le type de module : « menu » ou « - ». On rappelle qu'un module ne peut pas être exécuté via un module du type « - », mais uniquement via un module du type « menu ». La colonne 206 montre le nom du module tel qu'il apparaîtra dans le portail (« Label »). La colonne 207 montre le nom du module dans une bibliothèque (« Library »). La colonne 208 permet de modifier la position d'un module dans l'arborescence du portail. En sélectionnant le champ 209 en association avec un module du type « menu », la bibliothèque, contenant notamment les modules 211 de fonctionnalité disponibles pour l'utilisateur, apparaît sur l'interface 21. Un exemple de formulaire HTML possible de l'interface 21 et représentant la bibliothèque, pour l'ajout d'un module 211 à un module du type « menu » est représenté sur la figure 7. Comme on peut le constater sur la figure 7, le formulaire HTML comporte des champs 301 et 302. Le champ 301 dénomme la bibliothèque et les champs 302 représentent les modules 211 ou 212 disponibles pour l'utilisateur, sous forme d'icônes. Le formulaire de la figure 7 permet d'ajouter à la partie E1' un module 211 souhaité audit module du type « menu », par clic de souris sur l'icône 20 du module souhaité par exemple. Par ailleurs, en sélectionnant le champ 210 sur le formulaire de la figure 6, il est possible d'ajouter un module de type « menu » à un autre module de type « menu », pour ajouter un « sous-menu » dans l'arborescence du portail. 25 Un exemple de formulaire HTML possible de l'interface 21 pour l'ajout d'un sous-menu à un menu, et s'affichant après la sélection du champ 210, est représenté sur la figure 8. Comme on peut le constater sur la figure 8, le formulaire HTML comporte notamment des champs 303, 304 et 305. 30 Le champ 305 donne le titre courant du nouveau sous-menu. Le champ 303 donne le nom du nouveau sous-menu. Les champs 304 permet de sélectionner un numéro d'identifiant d'icônes associées. La colonne 204 du tableau de la figure 6 permet d'éditer et de modifier un sous-menu, la figure 9 montrant un formulaire possible de l'interface 21, le formulaire contenant des champs 306 et 307. Comme le montre la figure 9, le formulaire édité par sélection de la colonne 204 offre les mêmes possibilités de modifications du sous-menu que pour un menu de l'arborescence du menu principal (ajout de modules par le champ 306 et suppression de modules par le champ 307). L'ensemble El comporte également des modules 212 de gestion d'évènement. Un exemple de formulaire HTML possible de l'interface 21 est représenté sur la figure 10. Le formulaire représente une partie El" de l'ensemble El, la partie El" regroupant sous forme de tableau des modules 212 de gestion d'évènement. Ce formulaire s'affiche par exemple en sélectionnant l'onglet 40 de l'interface 21, la sélection s'effectuant par la souris ou par la touche bleue sur la télécommande de l'interface 21. Comme on peut le constater sur la figure 10, le formulaire HTML comporte des champs 401 à 408. Le champ 401 est le titre du formulaire. La colonne 402 correspond à un numéro identifiant chaque module 212. La colonne 403 permet de supprimer un module du portail. Cette suppression est préférentiellement définitive. La colonne 404 montre le nom du module dans la bibliothèque. La colonne 405 montre le nom du module tel qu'il apparaîtra dans le portail (« Label »). La colonne 406 montre le chemin vers un code 42 au format Javascript par exemple et associé au module 212. La colonne 407 montre les évènements gérés par le module 212. Dans l'exemple de la figure 10, le portail ne comporte que le module 212 « volume », qui permet de gérer l'appui sur les touches V+ et V-(évènements 63235 et 6234). En sélectionnant le champ 408, la bibliothèque, contenant notamment les modules 212 de gestion disponibles pour l'utilisateur, apparaît sur l'interface 21. L'interface 21 permet d'ajouter à l'ensemble El un module 212 souhaité comme décrit précédemment pour un module 211. Lors de la sélection d'un module 211 ou 212 dans la bibliothèque de la figure 7, le nom du module 211 ou 212 correspondant est copié dans la table 321 correspondant au projet sur le serveur 3. Une fois que l'utilisateur estime que l'ensemble El, constitué des parties El' et El" et regroupant les modules 211 et 212 est complet, il indique au processeur, grâce à l'interface 21, que tel est le cas. Il peut le faire par exemple grâce à un message sur l'interface 21. Lors de l'étape S2 de compilation, le processeur 22 de l'ordinateur 2 génère, à partir de l'ensemble El, un fichier E3 d'instructions pouvant être mises en oeuvre par le navigateur 11. A cet effet, un formulaire de l'interface 21 permet à l'utilisateur d'indiquer au processeur 2 l'identifiant du portail pour lequel le fichier E3 doit être généré. Un exemple de code pouvant être prévu pour le formulaire HTML de l'interface 21 est par exemple: De manière classique, le formulaire HTML est ainsi défini avec les balises et . L'attribut "action" de la balise permet de spécifier la page qui traitera les données fournies dans le formulaire par l'utilisateur : il s'agit ici de la page « main ». L'attribut "method' montre que la méthode de transmission est la méthode POST, également connue de l'homme du métier. Le processeur 22 envoie donc une requête au module 33 PHP, pour que ce dernier exécute le fichier « main.php » correspondant au portail. La distinction entre différents projets de portails se fait par exemple en spécifiant en argument, dans le nom du fichier, l'identifiant du projet souhaité. Dans un premier temps, les fichiers Javascripts classiques sont 5 chargés par le module 33. Les fichiers classiques sont les fichiers contenant par exemple les constantes, les objets et fonctions globales, les fonctions de gestion des évènements ou encore les fichiers de traduction. Une instruction possible pour ce chargement est par exemple : >cript tan suage "Ja] t crrpt" src="Jr con_.tar " scri cript language="JasaScript" utilsu serInt_rfac ..s": script` cript lanruage. "JamaScript" src="main.j_" sors 15 Ensuite vient le chargement par le module 33 des fichiers Javascripts contenant les codes 42 sources des modules 211 ou 212 utilisés par le portail. Une instruction possible pour ce chargement est par exemple : ; _.g1Iodule : dat lbas_ qu .r_. SELECT modulePath FROII ocp module dHERE module Id = module List['±]. if (;module ; reghlodule fetch O ) echo .,oript language="JavaScript" src.Smodul.e['modulePath'] ''. sczipt:, r _gT.Iodule clos, Cursor O ; ?> Le langage PHP est utilisé par le module 33 du serveur 3 pour interpréter le code PHP précédent et générer du code qui pourra être interprété par le navigateur 11, comme par exemple XHTML, HTML, CSS ou JavaScript, ici préférentiellement HTML et Javascript. 35 Ensuite, les paramètres du portail sont convertis en variables Javascripts par le module 33. Une instruction possible pour cette conversion est par exemple : 10 20 25 30 g proj_ctHame ; q portalLan iu z T = ; Une table (g_iconTable) contenant les chemins d'accès aux icônes est 5 créée par le module 33. Une instruction possible pour cette création est par exemple : ;r _~lues>t databa SELECT iconPath FROII r-,cp icone- v écho iconfable.push(nea terra_-("'.$iconldLis Sicon['iconPath'].);'; '- tique t clo eCurr_cor () ; ?> 20 Une autre table (g_moduleTable), contenant les objets Javascripts correspondant aux modules inclus dans le portail grâce à l'ensemble E1, est créée par le module 33, et chaque constructeur de module est appelé. Une instruction possible pour cette création est par exemple : r_gModule rdatabac_ guerl('SELECT moduleLab2 moduleHame, modul.ePath, moduleParam FROI-I ocp module if ( $module 'IL egModu1 _ fetch O ) echo T moduleTable.p T 1 (new o. indow [' j odule [ ' moduleHame nodu1 Lir t $module ['module Label']. ÿmodule['moduleParam']. Sr- Module c1oo urcor O ; ?> Ainsi, comme le montre la figure 11, à partir de l'ensemble El, et des fichiers comportant les codes 42 Javascripts ou HTML correspondant aux 45 modules 211 et 212 de l'ensemble El, le processeur génère le fichier E3. Le fichier E3 ne contient que du code objet orienté web, utilisant des 10 15 25 30 35 40 technologies connues W3C (par exemple HTML, JavaScript, CSS, XML, XSLT, CGI...). Le fichier main.php peut ainsi être renommé main.html par exemple. On appelle E2 le groupe de codes 42 utilisés par le portail. On comprend que pendant les étapes S1 et S2 décrites ci-dessus, il faut un lien entre l'ordinateur 2 et le serveur 3. Lors de l'étape S4 de déchargement, le processeur 22 décharge - le fichier E3 d'instructions, et - le groupe E2 de codes 42 associés aux modules 211 et 212 de l'ensemble El à partir du serveur 3 sur le dispositif 1, comme le montre la figure 1. Ceci suppose donc un lien entre le serveur 3 et le dispositif 1. A l'issue de l'étape S4, la connexion entre le serveur 3 et le dispositif 1 est rompue, et le dispositif 1 peut prendre un fonctionnement normal. Le lien 15 entre l'ordinateur 2 et le serveur 3 peut également être rompu. Pour prendre son fonctionnement normal, le navigateur 11 du dispositif 1 exécute une fonction, par exemple dénommée load_main() et contenue dans le fichier main.js, et qui permet : - de lancer un module de démarrage du portail (référencé par le 20 champ startingModuleld dans la table 321), et - de créer un gestionnaire d'évènement K de pression de touche (un évènement K est un relâchement d'une touche d'un clavier d'ordinateur ou d'une télécommande de décodeur par exemple). En effet, comme le montre la figure 12, on distingue deux types 25 d'évènements, à savoir : - les évènements K de pression de touche, et dont le point d'entrée est une fonction par exemple dénommée keypress_eventHandler() ; et - les évènements Event, apparus et détectés par le navigateur, 30 dont le point d'entrée est la fonction par exemple dénommée EventHandler(). Le gestionnaire d'évènement K de pression de touche créé et/ou le gestionnaire d'évènement Event appellent la fonction par exemple dénommée MainEventHandler(). Une instruction possible pour cet appel est par exemple : document. addE..entList_ner ( } up' function(.) Main E entHandler( f Lors d'un évènement Event ou K, chaque évènement est converti en un objet de type event_object, avec plusieurs paramètres sous forme de tableau, lors d'une étape A. Les objets évènements sont alors gérés par la fonction mainEventHandler() lors des étapes B, C, D, E ou F. Comme le montre la figure 11, le fichier E3 d'instructions comporte en effet des instructions renvoyant vers le code 42 par exemple dénommé event.js, instructions selon lesquelles les évènements sont gérés par une pile de modules 212 de gestion d'évènement ou de modules 211 de fonctionnalités si ceux-ci sont actifs. Ainsi, lors d'une étape B, l'objet évènement est transmis au module actif se situant sur le haut d'une pile de modules. Lors d'une étape C, l'objet évènement est pris en compte par ledit 20 module. La fonction mainEventHandler() détermine en D si l'objet évènement est géré par ledit module. Si la réponse est oui, alors l'objet est traité et c'est la fin de la fonction main EventHandler(). 25 Si la réponse est non, la fonction mainEventHandler() détermine en E si ce même objet évènement doit déclencher un (ou plusieurs) modules parmi une table g_eventTable. Lors d'une étape F, dans le cas de plusieurs modules devant être déclenchés, un paramètre permet de spécifier la priorité associée. 30 On passe alors à l'étape C déjà décrite. Comme le montre la figure 13, l'interface 21 comporte un formulaire HTML permettant d'ajouter à la bibliothèque un nouveau module. De manière très préférentielle, tous les modules 211 ou 212 possèdent la même structure standard avec notamment : - un constructeur, - un identifiant (également appelé « id »), - un nom (également appelé « Label »), et - un type du module, précisant la fonction de démarrage « start » pour les modules 211 ou la méthode de gestion d'évènement pour les modules 212. Le formulaire de la figure 13 comporte des champs 501, 502, 503 et 504. Les champs 502 comportent des champs obligatoires, notamment concernant le nom (Name), le nom du module tel qu'il apparaîtra dans le portail (« Label »), et le type du module. Suivant le type de module sélectionné, plus ou moins d'options supplémentaires peuvent apparaître. Le champ 503 permet de saisir une description du module, à l'attention de l'utilisateur. Le champ 504 permet la sauvegarde de la saisie. Lors de la sauvegarde, une nouvelle table 322 est créée sur le serveur 3. De même, préalablement ou postérieurement, un code 42 correspondant est créé sur le serveur 3. Les codes 42 des modules sont codés en HTML mais très préférentiellement en Javascript, par exemple sous la forme function modulename(id, 1abe1, parameter variable c., publiqu this.id = id; this.label = label; iariah1e var internat ar = t. t. constructeur fonction de lancement du module this.atart = function(caller) 30 35 estionnai e d _renément du module this.~tentHandler = function( vent) fonction publique ..upplémentai e this.enternalFunction = function( lent) fonction prie__- supplémentaire var internalFunction = function(argument) L'ordinateur 2 peut être incorporé en tout ou partie au dispositif 1. Le procédé peut de plus comporter une étape S3 facultative de test du 25 fichier E3 d'instructions avant l'étape S4 de déchargement. L'étape S3 de test concerne les modules 211 et 212, disponibles dans la bibliothèque commune à l'ensemble des projets de portail, de sorte que l'étape de test sert pour les évolutions ultérieures du portail ou pour un autre portail également. 30 De même, la correction des bogues sur les modules 211 ou 212 sert pour les évolutions ultérieures du portail ou pour un autre portail également. L'invention concerne également un produit programme d'ordinateur comportant des instructions qui, une fois chargées sur une mémoire d'un 35 ordinateur, permettent la mise en oeuvre d'un procédé selon l'invention. Le produit peut être sur tout support informatique, comme par exemple une mémoire ou un CD-Rom. 10 15 20 REVENDICATIONS1. Procédé de développement d'un portail Web, le portail Web étant mis en oeuvre localement par un navigateur (11) d'un dispositif (1), le procédé étant 5 caractérisé en ce qu'il comporte - une étape (S1) de configuration du portail, selon laquelle une interface (21) d'un ordinateur (2) permet la sélection et l'organisation d'un ensemble (El) de modules (211) de fonctionnalité et/ou de modules (212) de gestion d'évènement formant le portail Web, un code (42) stocké sur un serveur (3) 10 étant associé à chacun desdits modules (211, 212) ; - une étape (S2) de compilation, selon laquelle un processeur (22) de l'ordinateur (2) génère, à partir de l'ensemble (El), un fichier (E3) d'instructions pouvant être mises en oeuvre par le navigateur (11) ; et - une étape (S4) de déchargement, selon laquelle le processeur (22) 15 décharge le fichier (E3) d'instructions et un groupe (E2) de codes (42) associés aux modules (211, 212) sur le dispositif (1). 2. Procédé selon la revendication 1, dans lequel la sélection des modules (211) de fonctionnalité et/ou des modules (212) de gestion d'évènement 20 s'effectue à partir d'une bibliothèque de modules (211, 212). 3. Procédé selon l'une des revendications 1 ou 2, dans lequel le processeur génère (S2) le fichier (E3) d'instructions par l'intermédiaire du serveur (3) comportant un module (33) PHP, le fichier (E3) étant en format d'objet 25 orienté web utilisant des technologies W3C, préférentiellement HTML, JavaScript, CSS, XML, XSLT ou CGI. 4. Procédé selon l'une des revendications 1 à 3, dans lequel chaque module (211, 212) est construit sous une même structure standard. 30 5. Procédé selon l'une des revendications 1 à 4, dans lequel le fichier (E3) d'instructions comporte des instructions selon lesquelles les évènementssont gérés par une pile de modules (212) de gestion d'évènement ou de modules (211) de fonctionnalités. 6. Procédé selon l'une des revendications 1 à 5, comportant de plus une 5 étape (S3) de test du fichier (E3) d'instructions avant l'étape (S4) de déchargement. 7. Système de développement d'un portail Web, comportant - un dispositif (1) comportant un navigateur (11) mettant en oeuvre 10 localement le portail Web - un ordinateur (2) comportant une interface (21) et un processeur (22), et - un serveur (3) comportant une base de données (31), le système étant caractérisé en ce que - l'interface (21) est configurée pour permettre la sélection et l'organisation 15 d'un ensemble (El) de modules (211) de fonctionnalité et/ou de modules (212) de gestion d'évènement formant le portail Web ; - le processeur (22) est configuré pour générer, à partir de l'ensemble (El), un fichier (E3) d'instructions pouvant être mises en oeuvre par le navigateur (11);et 20 - le processeur (22) est configuré pour décharger le fichier (E3) d'instructions et un groupe (E2) de codes (42) associés aux modules (211, 212) sur le dispositif (1), à partir du serveur (3). 13. Système selon la revendication 7, dans lequel l'ordinateur (2) est en tout 25 ou partie dans le dispositif (1). 14. Système selon l'une des revendications 7 ou 8, dans lequel le dispositif (1) est tout dispositif embarqué possédant un navigateur, préférentiellement un décodeur. 15. Produit programme d'ordinateur comportant un ensemble d'instructions qui, une fois chargées sur un ordinateur, permettent la mise en oeuvre d'un procédé selon l'une des revendications 1 à 6. 30