EP2718810A1 - Procédé de développement d'un portail web, système de mise en oeuvre et produit programme d'ordinateur correspondant - Google Patents

Procédé de développement d'un portail web, système de mise en oeuvre et produit programme d'ordinateur correspondant

Info

Publication number
EP2718810A1
EP2718810A1 EP12729084.9A EP12729084A EP2718810A1 EP 2718810 A1 EP2718810 A1 EP 2718810A1 EP 12729084 A EP12729084 A EP 12729084A EP 2718810 A1 EP2718810 A1 EP 2718810A1
Authority
EP
European Patent Office
Prior art keywords
modules
portal
module
file
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP12729084.9A
Other languages
German (de)
English (en)
Inventor
Thomas Landais
Bertrand DESSON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sagemcom Broadband SAS
Original Assignee
Sagemcom Broadband SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sagemcom Broadband SAS filed Critical Sagemcom Broadband SAS
Publication of EP2718810A1 publication Critical patent/EP2718810A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Definitions

  • the present invention relates to a method of developing a web portal, the web portal being implemented locally by a browser of a device.
  • Decoders are known in the field of telecommunications.
  • a set-top box is an electronic device, connected to a television, that converts audiovisual signals (sometimes coded and usually transmitted by coaxial cable, telephone line or satellite) in a form that allows them to be properly received and processed by the television. It is thus necessary to use a decoder to access channels or television programs that can only be available under certain conditions set by a broadcaster or a distributor.
  • the operation of the decoder is managed through a portal ("portai" in English), displayed at least in part on the television, and in particular allowing interaction with a user of the decoder.
  • a portal in English
  • the known portals of known decoders use web technology, which is a technology based on the use of hypertexts and hypermedia data (i.e., an extension of hypertext to multimedia data, to include links between textual, visual and sound elements).
  • Web technology allows the search for information in a tree structure, access to this information and its visualization, thanks to a web browser, that is to say software able to exploit hypertext and hypermedia resources. .
  • a known portal for a known decoder is thus like a website, where are stored data accessible by the web browser, and especially offering links between information and features.
  • the portal therefore consists of an entry point (a home page) and a set of modules that interact with each other and / or respond to external events.
  • a known portal is usually created using known Web programming languages, for example
  • HyperText Markup Language that is a text-based language, which allows the creation of hypertext documents that can be displayed by the Web browser
  • the Javascript language that is to say a scripting language (a script is a program consisting of a series of commands that dispense users from entering them, allowing them to perform a particular function or to contribute to the execution of another program)
  • the writing language is a scripting language (a script is a program consisting of a series of commands that dispense users from entering them, allowing them to perform a particular function or to contribute to the execution of another program), the writing language
  • Javascript is particularly intended for non-technical users, and allows to integrate pre-programmed instructions in the construction of a Web document; PHP (Hypertext Preprocessor);
  • CSS text files that contain a list of HTML markers, as well as the formatting associated with each, and that accurately define the font, size, color, and layout of the HTML markers. elements of a web page relative to each other ...
  • a bug fix in the portal can not be shared with other portals, and each bug in each portal must be fixed.
  • the invention proposes to mitigate at least one of these drawbacks by facilitating the development of portals.
  • a method of developing a web portal the web portal being implemented locally by a browser of a device, the method being characterized in that it comprises
  • a step of configuring the portal according to which an interface of a computer allows the selection and organization of a set of function modules and / or event management modules forming the web portal, a code stored on a server being associated with each of said modules;
  • a compilation step according to which a processor of the computer generates, from the set, a file of instructions that can be implemented by the browser;
  • an unloading step in which the processor unloads the instruction file and a group of codes associated with the modules on the device.
  • the processor generates the instruction file via the server comprising a PHP module, the file being in a web oriented object format using W3C technologies, preferably HTML, JavaScript, CSS, XML, XSLT or CGI; - each module is built under the same standard structure;
  • W3C technologies preferably HTML, JavaScript, CSS, XML, XSLT or CGI;
  • the instruction file includes instructions that the events are managed by a stack of event management modules or feature modules;
  • the method further comprises a step of testing the instruction file before the unloading step.
  • the invention also relates to a system implementing the method, and a corresponding computer program product.
  • the invention has many advantages.
  • the invention allows a broadcaster or a distributor to develop a portal for example for a decoder, without internally mounting a dedicated web development team, or outsource this web development.
  • the invention allows a total detachment of software aspects and Web programming languages, and therefore allows any user to create a portal without having knowledge of Web development.
  • the invention makes it possible in particular to quickly modify the content of a portal without the need for knowledge in web development.
  • the invention makes it possible to develop a portal from already built software bricks, which makes it possible to share feature developments, bug fixes, and add new features easily.
  • the invention makes it possible in particular to pool the development between developers, integrators, and validators, particularly with regard to the test pages.
  • the invention allows additions, deletions, and modifications of the constituent elements of a portal, dynamically, which allows for example to quickly test different options for features.
  • a portal developed by a method according to the invention does not require a PHP server to function.
  • FIG. 1 shows schematically a possible embodiment of a system according to the invention
  • FIG. 2 diagrammatically represents a possible implementation of a method according to the invention
  • FIG. 3 diagrammatically represents a possible structure of a database of a server of a system according to the invention
  • FIG. 4 diagrammatically represents a possible structure of a directory containing a source code for a portal
  • FIGS. 5 to 10 diagrammatically represent possible forms of an interface of a computer of a system according to the invention, for the development of a portal;
  • FIG. 1 schematically shows a step of generating an instruction file from a set of modules and codes
  • FIG. 1 represents schematically a possible event management on a device of a system according to the invention.
  • FIG. 13 diagrammatically represents a possible form of an interface of a computer of a system according to the invention, for the creation of a module
  • FIGS. 1 and 2 diagrammatically represent a possible method according to the invention implemented on a possible system according to the invention, the system comprising a device 1, a computer 2 and a server 3.
  • a possible method of developing a web portal is mainly
  • step S2 of compilation and a step S4 of unloading an instruction file and a group of codes on the device 1, the device comprising a browser using Web technology and can implement the instruction file and the code group.
  • the web portal is intended to be implemented locally by the web browser 1 of the device 1 when the device 1 is in normal operation.
  • the device 1 can be of any type, such as for example a set-top box (STB), a computer, a gateway (or gateway), an electricity meter, or any other system. embedded with a browser.
  • STB set-top box
  • computer a computer
  • gateway or gateway
  • electricity meter or any other system. embedded with a browser.
  • the device 1 thus comprises in particular an interface 12.
  • the interface 12 of the device 1 may comprise a screen and / or a series of lights and / or a key and / or a key and / or a remote control (comprising, for example, a keypad and / or colored keys, with the colors red, green, yellow and blue for example).
  • the device 1 is autonomous in the sense that it is not relié, in normal operation, to a remote server of the type of the server 3.
  • the device 1 is a decoder, it is, in normal operation, connected to a television and converts audiovisual signals (sometimes coded and transmitted usually by coaxial cable, telephone line or satellite) in a form allowing them to be properly received and processed by the television.
  • the server 3 of the system is equipped
  • a server 32 using Web technology, preferably http (HyperText Transfer Protocol),
  • the computer 2 conventionally comprises an interface 21 and a processor 22.
  • the processor 22 comprises all the conventional means of memory, communication and calculation for the implementation of the method according to the invention, and is therefore not repeated in detail in the remainder of this description.
  • the interface 21 comprises a screen and / or forms that can be displayed on the screen (and described in more detail later in this description) and / or a keyboard and / or a mouse and / or a device remote control 1.
  • step S1 the interface 21 of the computer 2 allows the selection and organization of a set E1 forming the web portal and constituted
  • modules 21 1 of functionality and / or
  • the set E1 corresponds to a skeleton of the desired Web portal on the device 1, and the modules 21 1 and 21 2 correspond to executable actions notably via the browser 1 1 of the device 1.
  • a module 21 1 of functionality is executed by the browser 11 when a start function ("start" function) is called by the browser 11. It is also possible to provide a module 21 1 to be executed via another module 21 1; in this case, the module calling the execution of the other module is a module of the "menu" type (like the main menu of the portal for example).
  • modules 21 1 are thus: information pages on the device 1 (display of the serial number, etc.), configuration pages of audio options, etc.
  • An event management module 212 is executed by the browser 1 1 when there is appearance of at least one given event.
  • the modules 212 are treated in more detail in the remainder of the present description, but it is specified here that an event is for example a pressure of a key on the remote control of the interface 12 of the device 1, the extraction of an electronic card of the device 1 or the arrival of a new signal at the device 1.
  • a module 212 is not accessible through the menu, such as sound volume management.
  • the data base 31 of the server 3 stores tables 321, 322, 323 and 324 shown in FIG. 3.
  • Each table 321, named for example scp_project, contains the global information for a given portal project.
  • the information can be entered by a user through forms of the interface 21, as described in the following description.
  • Each table 321 thus comprises
  • the table 321 can optionally include a module 212 in the project. It includes a line (eventModuleList) that contains the list of modules that are triggered only by events.
  • the table 321 can optionally include a module 21 1 in the project. It thus contains a capita (startingModuleld) allowing to specify the first module which will be launched at the execution of the portal, and which can also call other modules.
  • startingModuleld a member of the project.
  • the models are m od ul es which have additional functions compared to the other modules 21 1 or 212.
  • Each style is grouped in a table 323, for example called scp_template, which makes it possible to save the various information of the style, such as as its identifier (Id), its name (name), its path (path), as well as its parameters (param).
  • Each table 322, denominated for example scp_module, contains the information making it possible to create and configure the modules 21 1 or 212.
  • each module 21 1 or 212 has an identifier (moduleld) and a certain number of parameters.
  • Each module 21 1 or 21 2 is thus listed in the database 31 of data.
  • Each table 324 for example called scp_icons, makes it possible to simplify the use of the icons within the database 31, by associating with the path of the icon an identifier which can then be used in the parameters of modules 21 1 or 21 2. Icons are also linked to a style.
  • the base 31 further contains links to source codes 42 contained in files 420, each code 42 corresponding to a module 21 1 or 212.
  • each code 42 is copied into a specific directory 420 of the server 3.
  • the directory 420 is referred to by the name of the module 21 1 or 212.
  • the code 42 is copied as a source file of the module 21 1 or 212, in Javascript or HTML format.
  • Each code file 42 is denominated by the name of the module 21 1 or 212, preferably followed by the version number of the module, for example on three characters. The user can therefore select a particular version of the module 21 1 or 212 depending on the architecture of the device 1 (archi V1 or V2 archi for example).
  • the specific directory 420 may contain other directories for specific resources of the module (icons, images, sounds, etc.).
  • step S1 the user indicates an identifier of a portal project in the interface 21.
  • the interface 21 includes an HTML form known to those skilled in the art.
  • HTM formulas L use are functions HTM L con knues executed by the computer 2, such as the following function that retrieves a "window" type object.
  • UI_getNewWindo width, height, opacity
  • a window typically has three distinct areas:
  • An HTML function is also known for positioning the window in the interface 21.
  • top and left must be indicated in number of pixels or by using a string 'CENTER'.
  • the display and masking functions of a window are also known.
  • the options of the show function can be any association of values
  • the form of the interface 21 comprises in particular fields 101, 102, 103 and 104.
  • Field 101 is the current name of the portal.
  • the fields 102 make it possible to modify or to select
  • the fields 103 make it possible to configure the style to be applied, as for example:
  • Optity opacity of the menu
  • the field 104 "Save" allows a backup of the configurations.
  • the information entered in the fields 101 to 103 are therefore copied into the corresponding table 321 on the server 3.
  • the interface 21 allows the selection and organization of the set E1 of modules 21 1 or 212 forming the web portal.
  • the interface 21 comprises an HTML form of portal tree ("portai tree"), for example according to that shown in FIG. 6.
  • the form HTM L notably comprises fields 201 to 210.
  • Field 201 is the title of the form, presenting the portal tree as a table with columns.
  • the table thus shows a part E1 'of the set E1, said part E1' consisting of modules 21 1 of functionality desired by the user.
  • Column 202 corresponds to a number identifying each module 21 1 of functionality.
  • Column 203 deletes a module from the portal. This deletion is preferably final.
  • Column 205 shows the module type: "menu” or "-”. It is recalled that a module can not be executed via a module of the type "-”, but only via a module of the type "menu”. Column 206 shows the name of the module as it will appear in the portal ("Label").
  • Column 207 shows the name of the module in a library ("Library").
  • the library By selecting the field 209 in association with a module of the "menu" type, the library, containing in particular the models 21 1 of functionality available to the user, appears on the interface 21.
  • FIG. 7 An exemplary HTM L possible form of the interface 21 and representing the library, for the addition of a module 21 1 to a module of the "menu" type is shown in FIG. 7.
  • the form HTM L comprises fields 301 and 302.
  • the name 301 denominates the cell and the channels 302 represent the modules 21 1 or 21 2 available to the user, in the form of icons.
  • FIG. 7 makes it possible to add to the part E1 'a desired module 21 1 to said module of the "menu" type, by a click of the mouse on the icon of the desired module for example.
  • FIG. 21 An example of a possible HTML form of the interface 21 for adding a submenu to a menu, and displayed after the selection of the field 210, is shown in FIG.
  • the form HTM L notably comprises fields 303, 304 and 305.
  • Field 303 gives the name of the new submenu.
  • the fields 304 makes it possible to select an identifier number of associated icons.
  • Column 204 of the table of FIG. 6 makes it possible to edit and modify a submenu, FIG. 9 showing a possible form of interface 21, the form containing fields 306 and 307.
  • the form edited by selection in column 204 offers the same sub-menu modification possibilities as for a menu of the main menu tree (adding modules by the field 306 and deleting modules by the field 307).
  • the set E1 also includes modules 21 2 for event management.
  • FIG. 21 An example HTM form L possible of the interface 21 is shown in FIG.
  • the form represents a part E1 "of the set E1, the part E 1" grouping in tabular form modules 21 2 of event management.
  • This form is displayed for example by selecting the tab 40 of the interface 21, the selection being made by the mouse or by the blue key on the remote control of the interface 21.
  • the HTML form has fields 401 to 408.
  • Field 401 is the title of the form.
  • Column 403 deletes a module from the portal. This deletion is preferably final.
  • Column 404 shows the module name in the library.
  • the colon 406 shows the path in a code 42 in Javascript format for example and associated with the module 212.
  • the gate comprises only the module 21 2 "volume", which makes it possible to manage the pressing on the keys V + and V- (events 63235 and 6234).
  • the library containing in particular the management modules 21 2 available to the user, appears on the interface 21.
  • the interface 21 makes it possible to add to the set E1 a desired module 212 as described previously for a module 21 1.
  • the processor 22 of the computer 2 generates, from the set E1, a file E3 instructions that can be implemented by the browser 1 1.
  • a form of the interface 21 allows the user to indicate to the processor 2 the identifier of the portal for which the file E3 must be generated.
  • An exemplary code that can be provided for the HTML form of the interface 21 is for example:
  • the HTML form is defined with the ⁇ form> and ⁇ / form> tags.
  • the "action” attribute of the ⁇ form> tag is used to specify the page that will process the data provided in the form by the user: this is the "main” page.
  • the "method” attribute shows that the transmission method is the POST method, also known to those skilled in the art.
  • the processor 22 sends a request to the module 33 PHP, so that the latter executes the file "main. php "corresponding to the portal.
  • the distinction between different projects of portals is made for example by specifying in argument, in the name of the file, the identifier of the desired project.
  • the classic Javascripts files are loaded by the module 33.
  • Typical files are files containing, for example, constants, global objects and functions, event management functions, and translation files.
  • a possible instruction for this loading is for example:
  • a possible instruction for this loading is for example:
  • the PH P language is used by the module 33 of the server 3 to interpret the previous PH P code and generate code that can be interpreted by the browser 1 1, such as XHTML, HTML, CSS or JavaScript, here preferably HTML and Javascript.
  • portal parameters are converted into variables
  • g_portalLanguage ⁇ ? php echo '"'. $ defaultLanguage. '"'; ?>;
  • a table (g_iconTable) containing the paths to the icons is created by the module 33.
  • a possible instruction for this creation is for example:
  • Another table (gjnoduleTable), containing the Javascripts objects corresponding to the modules included in the portal through the set E1, is created by the module 33, and each module builder is called.
  • a possible instruction for this creation is for example:
  • the processor From the set E1, and files comprising the codes 42 Javascripts or HTML corresponding to the modules 21 1 and 212 of the set E1, the processor generates the file E3.
  • the E3 file contains only web-oriented object code, using known technologies W3C (for example HTML, JavaScript, CSS, XML, XSLT, CGI ).
  • W3C for example HTML, JavaScript, CSS, XML, XSLT, CGI .
  • the main file. php can be renamed main.html for example.
  • the group of codes 42 used by the portal is called E2.
  • step S4 the connection between the server 3 and the device 1 is broken, and the device 1 can take normal operation.
  • the link between the computer 2 and the server 3 can also be broken.
  • the browser 1 1 of the device 1 executes a function, for example named load_main () and contained in the main.js file, and which allows:
  • K is a release of a key from a computer keyboard or a decoder remote control for example.
  • keypress_eventHandler the keypress K events, whose entry point is a function for example called keypress_eventHandler ();
  • Event events that appeared and were detected by the browser whose entry point is the function named for example
  • EventHandlerQ The keypress event handler K created and / or the event handler called slow call the function for example named MainEventHandler ().
  • a possible instruction for this call is for example:
  • each event is converted into an object of type event_object, with several parameters in tabular form, during a step A.
  • the instruction file E3 in fact comprises instructions returning to the code 42, for example called event.js, instructions according to which the events are managed by a stack of event management modules 21 2 or modules 21 1 of features if they are active.
  • the event object is transmitted to the active module located on the top of a stack of modules.
  • the event object is taken into account by said module.
  • the mainEventHandler () function determines in D whether the event object is managed by the module.
  • the mainEventHandler () function determines in E whether this same event object should trigger one (or more) modules from a g_eventTable table. During a step F, in the case of several modules to be triggered, a parameter makes it possible to specify the associated priority.
  • the interface 21 includes an HTML form making it possible to add a new module to the library.
  • all the modules 211 or 212 have the same standard structure with, in particular:
  • FIG. 13 includes fields 501, 502, 503 and 504.
  • the fields 502 include mandatory fields, especially concerning the name, the name of the module as it will appear in the portal ("Label"), and the type of the module. Depending on the type of module selected, more or fewer additional options may appear.
  • the field 503 makes it possible to enter a description of the module, to the attention of the user.
  • the codes 42 of the modules are coded in HTML but very preferentially in Javascript, for example in the form
  • the computer 2 may be incorporated wholly or partly into the device 1.
  • the method may further include an optional step S3 of testing the instruction file E3 prior to the unloading step S4.
  • the test step S3 concerns the modules 21 1 and 212, available in the library shared by all the portal projects, so that the test step is used for the subsequent evolutions of the portal or for another portal as well.
  • the bug correction on the modules 21 1 or 212 is used for subsequent evolutions of the portal or for another portal as well.
  • the invention also relates to a computer program product comprising instructions which, when loaded onto a memory of a computer, allow the implementation of a method according to the invention.
  • the product can be on any computer support, such as a memory or a CD-Rom.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

La présente invention concerne un 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 caractérisé en ce qu'il comporte - une étape de configuration du portail, selon laquelle une interface (21) d'un ordinateur (2) permet la sélection et l'organisation d'un ensemble (E1) 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) étant associé à chacun desdits modules (211, 212); - une étape de compilation, selon laquelle un processeur (22) de l'ordinateur (2) génère, à partir de l'ensemble (E1), un fichier (E3) d'instructions pouvant être mises en oeuvre par le navigateur (11); et - une étape de déchargement, selon laquelle le processeur (22) décharge le fichier (E3) d'instructions et un groupe (E2) de codes (42) associés aux modules (211, 212) sur le dispositif (1). Elle concerne également un système mettant en oeuvre le procédé et un produit programme d'ordinateur correspondant.

Description

Procédé de développement d'un portail Web, système de mise en œuvre et produit programme d'ordinateur correspondant
DOMAINE TECHNIQUE GENERAL
La présente invention concerne un procédé de développement d'un portail Web, le portail Web étant mis en œuvre localement par un navigateur d'un dispositif.
Elle concerne également un système mettant en œuvre le procédé et un produit programme d'ordinateur correspondant.
ETAT DE L'ART
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 ainsi nécessaire d'utiliser un décodeur pour avoir accès à des chaînes ou à des programmes de télévision qu i ne peuvent être d ispon ibles 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 (« portai » en anglais), affiché au moins en partie sur le téléviseur, et 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 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 à u n navigateu r Web, c'est-à-d ire un logiciel capable d'exploiter les ressources hypertextes et hypermédias.
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 notam ment d es l iens entre des i nformation s et d es 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 de programmation Web, comme par exemple
le langage HTML (HyperText Markup Language), c'est-à-dire un langage de bal isage 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 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 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 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...
En pratique, si un diffuseur ou un distributeur désire développer un portail pou r un décodeu r, il doit monter en interne u ne équ ipe déd ié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 fonctionnal ité par un 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 pall ier au moins un de ces inconvén ients, 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 œuvre 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 œuvre 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 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 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 avant l'étape de déchargement.
L'invention concerne également un système mettant en œuvre 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 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 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 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 des éléments constitutifs d'un portail, de manière dynamique, ce qui permet par exemple de tester rapidement des options d iffé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.
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 œuvre possible d'un procédé selon l'invention ;
- la figure 3 représente schématiquement une structure possible d'une base 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, pour le développement d'un portail ;
- la figure 1 1 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 fig u re 1 2 représente schématiq uement u ne gestion possi bl e d'événement sur un dispositif d'un système selon l'invention ; et
- 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.
DESCRIPTION DETAILLEE
Les figures 1 et 2 représentent schématiquement un procédé possible selon l'invention mis en œuvre 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 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 œuvre le fichier d'instructions et le groupe de codes. En effet, le portail Web est destiné à être mis en œuvre localement par le navigateu r 1 1 Web du d ispositif 1 lorsq ue le d ispositif 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 ord inateur, 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 l u m i neux et/ou u n cl avier et/ou u ne sou ris et/ou u ne 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 d ispositif 1 est autonome en ce sens qu'il n'est pas rel ié, 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 classiq uement u ne interface 21 et u n processeur 22.
Le processeur 22 comporte tous les moyens classiques de mémoire, de communication et de calcul pour la mise en œuvre 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é
- de modules 21 1 de fonctionnalité, et/ou
de modules 212 de gestion d'événement
souhaités par un utilisateur pour le portail.
L'ensemble E1 correspond à un squelette du portail Web souhaité sur le dispositif 1 , et les modules 21 1 et 21 2 correspondent à des actions exécutables notamment via le navigateur 1 1 du dispositif 1 .
On explicite ici la différence entre un module 21 1 et un module 212. Un module 21 1 de fonctionnalité est exécuté par le navigateur 1 1 lorsqu'une fonction de démarrage (fonction « start » en anglais) est appelée par le navigateur 1 1 . On peut également prévoir qu'un module 21 1 soit exécuté via un autre module 21 1 ; 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 21 1 sont ainsi : des pages d'information sur le dispositif 1 (affichage du numéro de série, ...), des pages de configuration d'options audio, ...
Un module 212 de gestion d'événement est exécuté par le navigateur 1 1 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 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 l ien avec les modules 21 1 et 21 2, 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 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 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)
- une version du portail (portalVersion)
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.
La table 321 permet d'inclure éventuellement un module 21 1 dans le projet. Elle comporte ainsi une l igne (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 style d'interface (template en anglais) est utilisé par le projet.
Les styl es so n t d es m od u l es q u i possèdent des fonctions supplémentaires par rapport aux autres modules 21 1 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 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 21 1 ou 212. Comme on l'expliquera plus en détail dans la suite, chaque module 21 1 ou 212 possède un identifiant (moduleld) et un certain nombre de paramètres. Chaque module 21 1 ou 21 2 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'util isation 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 util isé dans les paramètres de modules 21 1 ou 21 2. 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 21 1 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 dénommé par le nom du module 21 1 ou 212.
Le code 42 est copié sous la forme d'un fichier source du module 21 1 ou 212, au format Javascript ou HTML.
Chaque fichier de code 42 est dénommé par le nom du module 21 1 ou 212, préférentiellement suivi du numéro de version du module, par exemple sur trois caractères. L'util isateur peut donc sélectionner une version particulière du module 21 1 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.).
On donne ci-après un exemple possible de mise en œuvre 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 l'homme du métier.
Les formu la i res HTM L util isent des fonctions con n ues HTM L 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_getNewWindo (width, height, opacity)
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 .updateTitle (title) ;
window. updateContent (content)
indow. updateFooter ( footer) ;
On connaît également une fonction HTML permettant de positionner la fenêtre dans l'interface 21 .
windo . setPosition (top, left)
Les valeurs « top » et « left » doivent être indiquées en nombre de pixels ou bien en utilisant une chaîne de caractères 'CENTER'.
On connaît également les fonctions d'affichage et de masquage d'une fenêtre.
window. show (options) ;
window . hide ( ) ;
Les options de la fonction show peut être toute association des valeurs
'TITLE', 'CONTENT', et 'FOOTER', séparées par le caractère '|'.
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 , 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 (« Portai name »),
le numéro de version du portail (« Portai version number »), - 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 l'organisation de l'ensemble E1 de modules 21 1 ou 212 formant le portail Web.
A cet effet, l'interface 21 comporte un formulaire HTML d'arborescence du portail (« portai tree »), par exemple conforme à celui représenté sur la figure 6.
II 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 HTM L 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 E1 ' de l'ensemble E1 , ladite partie E1 ' étant constituée de modules 21 1 de fonctionnal ité souhaités par l'utilisateur.
La colonne 202 correspond à un numéro identifiant chaque module 21 1 de fonctionnalité.
La colonne 203 permet de supprimer un module du portail . Cette suppression est préférentiellement définitive.
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 mod u les 21 1 de fonctionnalité disponibles pour l'utilisateur, apparaît sur l'interface 21 .
U n exemple de form ula ire HTM L possible de l ' interface 21 et représentant la bibliothèque, pour l'ajout d'un module 21 1 à un module du type « menu » est représenté sur la figure 7.
Comme on peut le constater sur la figure 7, le formulaire HTM L comporte des champs 301 et 302.
Le ch am p 301 dénom me l a b i bl ioth èq u e et les cha m ps 302 représentent les modules 21 1 ou 21 2 disponibles pour l'utilisateur, sous forme d'icônes.
Le formulaire de la figure 7 permet d'ajouter à la partie E1 ' un module 21 1 souhaité audit module du type « menu », par clic de souris sur l'icône 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 » d a n s l'arborescence du portail.
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 HTM L comporte notamment des champs 303, 304 et 305.
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 E1 comporte également des modules 21 2 de gestion d'événement.
Un exemple de formulaire HTM L possible de l 'interface 21 est représenté sur la figure 10.
Le formulaire représente une partie E1 " de l'ensemble E1 , la partie E 1 " regroupant sous forme de tableau des modules 21 2 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 1 0, 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 colon ne 406 montre le chem in vers u n 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 21 2.
Dans l'exemple de la figure 10, le portail ne comporte que le module 21 2 « 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 21 2 de gestion disponibles pour l'utilisateur, apparaît sur l'interface 21 . L'interface 21 permet d'ajouter à l'ensemble E1 un module 212 souhaité comme décrit précédemment pour un module 21 1 .
Lors de la sélection d'un module 21 1 ou 212 dans la bibliothèque de la figure 7, le nom du module 21 1 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 E1 , constitué des parties E1 ' et E1 " et regroupant les modules 21 1 et 21 2 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 E1 , un fichier E3 d'instructions pouvant être mises en œuvre par le navigateur 1 1 .
A cet effet, un formulaire de l'interface 21 permet à l'util isateur 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:
<form name="generatePortal" action="main.php" method="post">
<input type="hidden" name="projectld" id="projectld_generate" value="13"/>
</form>
De manière classique, le formulaire HTML est ainsi défini avec les balises <form> et </form>. L'attribut "action" de la balise <form> 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 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 :
Ensuite vient le chargement par le module 33 des fichiers Javascripts contenant les codes 42 sources des modules 21 1 ou 212 utilisés par le portail.
Une instruction possible pour ce chargement est par exemple :
Le langage PH P est util isé par le module 33 du serveur 3 pour interpréter le code PH P précédent et générer du code qui pourra être interprété par le navigateur 1 1 , comme par exemple XHTML, HTML, CSS ou JavaScript, ici préférentiellement HTML et Javascript.
Ensu ite, les paramètres d u portail sont convertis en variables
Javascripts par le module 33.
Une instruction possible pour cette conversion est par exemple : g_projectName = <?php echo ' " ' . $projectName . ' " ' ; ?>;
g_portalLanguage = <?php echo ' " ' . $defaultLanguage . ' " ' ; ?>;
Une table (g_iconTable) contenant les chemins d'accès aux icônes est créée par le module 33.
Une instruction possible pour cette création est par exemple :
Une autre table (gjnoduleTable), 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 :
Ainsi, comme le montre la figure 1 1 , à partir de l'ensemble E1 , et des fichiers comportant les codes 42 Javascripts ou HTML correspondant aux modules 21 1 et 212 de l'ensemble E1 , le processeur génère le fichier E3. Le fichier E3 ne contient que du code objet orienté web, utilisant des 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 21 1 et 212 de l'ensemble E1
à 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 entre l'ordinateur 2 et le serveur 3 peut également être rompu.
Pour prendre son fonctionnement normal, le navigateur 1 1 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 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 1 2, on distingue deux types 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, dont le point d'entrée est la fonction par exemple dénommée
EventHandlerQ. Le gestionnaire d'événement K de pression de touche créé et/ou le gestionna ire d 'événement Event appel lent la fonction par exemple dénommée MainEventHandlerQ.
Une instruction possible pour cet appel est par exemple :
document . addEventListener ( ' keyu ' ,
function(e) {MainEventHandler (e) ; }, false) ;
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.
Le s o bj ets évé n e m e n ts so n t a l o rs g é ré s pa r l a fo n ct i o n mainEventHandler() lors des étapes B, C, D, E ou F.
Comme le montre la figure 1 1 , 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 21 2 de gestion d'événement ou de modules 21 1 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 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 mainEventHandler().
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.
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
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 fichier E3 d'instructions avant l'étape S4 de déchargement.
L'étape S3 de test concerne les modules 21 1 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.
De même, la correction des bogues sur les modules 21 1 ou 212 sert pour les évolutions ultérieures du portail ou pour un autre portail également.
L'invention concerne également un produ it programme d'ord inateur comportant des instructions qui, une fois chargées sur une mémoire d'un ordinateur, permettent la mise en œuvre 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.

Claims

REVENDICATIONS
1 . Procédé de développement d'un portail Web, le portail Web étant mis en œuvre localement par un navigateur (1 1 ) d'un dispositif (1 ), le procédé étant 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 (E1 ) de modules (21 1 ) de fonctionnalité et/ou de modules (212) de gestion d'événement formant le portail Web, un code (42) stocké sur un serveur (3) étant associé à chacun desdits modules (21 1 , 212) ;
- une étape (S2) de compilation, selon laquelle un processeur (22) de l'ordinateur (2) génère, à partir de l 'ensem ble (E 1 ), un fich ier (E3) d'instructions pouvant être mises en œuvre par le navigateur (1 1 ) ; et
- une étape (S4) de déchargement, selon laquelle le processeur (22) décharge le fichier (E3) d'instructions et un groupe (E2) de codes (42) associés aux modules (21 1 , 212) sur le dispositif (1 ).
2. Procédé selon la revendication 1 , dans lequel la sélection des modules (21 1 ) de fonctionnalité et/ou des modules (212) de gestion d'événement s'effectue à partir d'une bibliothèque de modules (21 1 , 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 orienté web utilisant des technologies W3C, préférentiellement HTML, JavaScript, CSS, XML, XSLT ou CGI.
4. Procédé selon l'une des revend ications 1 à 3, dans lequel chaque module (21 1 , 212) est construit sous une même structure standard.
5. Procédé selon l'une des revendications 1 à 4, dans lequel le fichier (E3) d'instructions comporte des instructions selon lesquelles les événements sont gérés par une pile de modules (212) de gestion d'événement ou de modules (21 1 ) de fonctionnalités.
6. Procédé selon l'une des revendications 1 à 5, comportant de plus une é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 (1 1 ) mettant en œuvre 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 d'un ensemble (E1 ) de modules (21 1 ) 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 (E1 ), un fichier (E3) d'instructions pouvant être mises en œuvre par le navigateur (1 1 ) ; et
- le processeu r (22) est config u ré pou r décharger le fich ier (E3) d'instructions et un groupe (E2) de codes (42) associés aux modules (21 1 , 212) sur le dispositif (1 ), à partir du serveur (3).
8. Système selon la revendication 7, dans lequel l'ordinateur (2) est en tout ou partie dans le dispositif (1 ).
9. 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.
10. Produit programme d'ordinateur comportant un ensemble d'instructions qui, une fois chargées sur un ordinateur, permettent la mise en œuvre d'un procédé selon l'une des revendications 1 à 6.
EP12729084.9A 2011-06-10 2012-06-08 Procédé de développement d'un portail web, système de mise en oeuvre et produit programme d'ordinateur correspondant Withdrawn EP2718810A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1155131A FR2976373B1 (fr) 2011-06-10 2011-06-10 Procede de developpement d'un portail web, systeme de mise en oeuvre et produit programme d'ordinateur correspondant
PCT/EP2012/060872 WO2012168417A1 (fr) 2011-06-10 2012-06-08 Procédé de développement d'un portail web, système de mise en oeuvre et produit programme d'ordinateur correspondant

Publications (1)

Publication Number Publication Date
EP2718810A1 true EP2718810A1 (fr) 2014-04-16

Family

ID=46331284

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12729084.9A Withdrawn EP2718810A1 (fr) 2011-06-10 2012-06-08 Procédé de développement d'un portail web, système de mise en oeuvre et produit programme d'ordinateur correspondant

Country Status (6)

Country Link
US (1) US20140129926A1 (fr)
EP (1) EP2718810A1 (fr)
CN (1) CN103782271B (fr)
BR (1) BR112013031520A2 (fr)
FR (1) FR2976373B1 (fr)
WO (1) WO2012168417A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105242913A (zh) * 2015-07-06 2016-01-13 临沂优狐网络科技有限公司 Yyuc-php框架

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080091663A1 (en) * 1998-12-08 2008-04-17 Inala Suman K Software Bundle for Providing Automated Functionality to a WEB-Browser
US6721713B1 (en) * 1999-05-27 2004-04-13 Andersen Consulting Llp Business alliance identification in a web architecture framework
US7890926B2 (en) * 2005-01-04 2011-02-15 Vaakya Technologies Private Limited System and method for application development and deployment
US20060294496A1 (en) * 2005-06-27 2006-12-28 Bea Systems, Inc. System and method for improved web portal design through control tree file creation
US8429630B2 (en) * 2005-09-15 2013-04-23 Ca, Inc. Globally distributed utility computing cloud
CN100535900C (zh) * 2005-12-06 2009-09-02 国际商业机器公司 用于提供异步门户页的方法和系统
CN101004680B (zh) * 2006-11-23 2011-06-22 福建顶点软件股份有限公司 一种以直接对象模型定义为核心的灵活快捷的软件开发方法及支持系统
US8639743B1 (en) * 2007-12-05 2014-01-28 Appcelerator, Inc. System and method for on-the-fly rewriting of JavaScript
US8789130B2 (en) * 2009-07-08 2014-07-22 Centurylink Intellectual Property Llc Set top box browser control via a wireless handset
US9552123B1 (en) * 2010-05-27 2017-01-24 Amazon Technologies, Inc. Integrating applications in a portal
WO2011149558A2 (fr) * 2010-05-28 2011-12-01 Abelow Daniel H Réalité alternée
CN101909082B (zh) * 2010-07-29 2013-03-13 中国运载火箭技术研究院 一种基于模型驱动的网格门户配置系统及配置方法
WO2012127481A1 (fr) * 2011-03-23 2012-09-27 Infosys Technologies Limited Cadre d'interface utilisateur unifiée permettant de créer des portails web configurables au moyen d'options de menu

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2012168417A1 *

Also Published As

Publication number Publication date
WO2012168417A1 (fr) 2012-12-13
CN103782271A (zh) 2014-05-07
BR112013031520A2 (pt) 2016-12-13
FR2976373B1 (fr) 2013-06-14
FR2976373A1 (fr) 2012-12-14
CN103782271B (zh) 2017-11-10
US20140129926A1 (en) 2014-05-08

Similar Documents

Publication Publication Date Title
US9454363B1 (en) Mobile application development system and method
Subramanian Pro Mern Stack: Full Stack Web App Development with Mongo, Express, React and Node
EP2151773B1 (fr) Conversion de page web synchrone vers asynchrone
US20140040862A1 (en) Copying Reusable Components from a Remote Source
US7685609B1 (en) Using a distributed form object model to facilitate form event processing
US8275099B2 (en) World wide telecom web voice applications
US20260017037A1 (en) Method and system for hosting third-party web widgets for application development
Reddy Beginning Spring Boot 2: Applications and microservices with the Spring framework
CN101937335B (zh) 一种生成Widget图标的方法、Widget摘要文件的生成方法及Widget引擎
FR2980605A1 (fr) Procede de restitution d&#39;une representation d&#39;un document web annote, programme d&#39;ordinateur et dispositif electronique associes
CN116594676A (zh) 一种应用打包方法、装置、设备及存储介质
EP2187321B1 (fr) Procédé et dispositif d&#39;édition d&#39;un objet représenté dans une page web
Yuan et al. JBoss seam: simplicity and power beyond Java EE
EP2219113B1 (fr) Procédé d&#39;affichage, dispositif et produit programme d&#39;ordinateur correspondant
EP2718810A1 (fr) Procédé de développement d&#39;un portail web, système de mise en oeuvre et produit programme d&#39;ordinateur correspondant
Guo The first line of code
Allen et al. Beginning Android 4
CN112487322B (zh) 一种第三方应用Loading页面的加载方法及显示设备
WO2007107534A1 (fr) Procédé, dispositif et système de gestion d&#39;informations structurées au sein d&#39;une scène graphique
Freeman Essential Angular for Asp. Net Core MVC
Vavru et al. Android programming: Complete application programming guide
CN121187562A (zh) 一种智能低代码构建及自动部署多端应用全栈解决方法
Bendoraitis Web Development with Django Cookbook
Hoang Finnish scanner mobile application
FR2985336A1 (fr) Procede de simulation de l&#39;interface homme-machine d&#39;un appareil

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20131217

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SAGEMCOM BROADBAND SAS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190328

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20220104