2265U10 – Développement Application Web M. Dominique

publicité
2265U10 – Développement Application Web
M. Dominique GALLAND
2007-01-25
Application « Web »
Ce sont les applications dont on a accès par le Web. Du côté client, on fait appel à un
navigateur qui affiche les pages HTML, sur lequel on peut faire des saisies sous forme HTML
(champs, boutons => soumission). Du côté fournisseur, il y a un serveur Web statique (Web
documentaire) ou dynamique (avec des composants applicatifs)
Document
HTML
Web statique
ou
documentaire
Protocole HTTP
Navigateur
réseau
Serveur Web
Contenu de la
forme
HTTP
dynamique
Serveur de traitement
Composant
applicatif
BD
Web applicatif
Client léger
 Zéro installation sur le poste client => zéro traitement du côté client
Modèle transactionnel
Le modèle interactif plus exigeant sur les transactions réseau et les charges du serveur, par
conséquent, limite la montée des charges applicatives.
Le modèle interactif est plus riche sur le terme de réactivité et d’interface.
Le modèle transactionnel permet de grosses montées des charges applicatives.
Il y a une tendance de faire des traitements du côté client pour combiner les avantages des
deux modèles (plus interactif + plus de montées de charges applicatives).
Ainsi la génération d’utilisation de Javascript.
Les cas particuliers de vrais traitements du côté client :
 Applet
C’est un composant (paragramme) qui s’exécute du côté navigateur.
 Active X :
Universalité
Il est universellement disponible sur l’Internet (sous réserve d’avoir droit d’accès)
Différence : Applications Internet & Intranet
1
Ils sont les mêmes choses, mais les différences se trouvent au niveau applicatif (cf. notion de
couches). Pour avoir accès à l’Intranet, il faut passer par une identification spécifique (alors
que l’Internet est accessible de façon universelle)
Différence : modèle centralisé & modèle à 3 niveaux
Modèle centralisé : pas de traitement au niveau client et tout traitement se fait sur le serveur.
Modèle à 3 niveaux : l’apparition des traitements au niveau client.
Conception coté serveur
Modularité ou non ?
 Séparation des métiers et travailler en équipe
 Réutilisation des certaines modules des applications dans d’autres applications
interopérationnelles
 Maintenance plus facile
Plus compréhensible et maintenable
 Modularité permet la répartition
Rq : on peut faire fonctionner certaines modules sur des machines différentes. La
répartition des traitements peut augmenter la performance.



Affichage génération du HTML
Logique de dialogue
Recevoir, valider la requête
Navigation de l’utilisateur dans l’application
Logique « métier »
C’est le traitement applicatif proprement dit en liaison avec la base de données.
Il est indépendant d’aspect « web » (càd aucun aspect « web »)
Génération du HTML : modèle MVC pour une application Web
MVC : Model View Controler
Rq : on combine 3 aspects :
 Model
Controler
requête
agit
 Logique metier
voir
 Independent des aspects Web
Model
BD
Utilisateur Prépare le
 Éventuellement, legacy (légataire)
contenu
réponse
 Controleur
View
 Logique de dialogue avec
l’utilisateur
 Vue
 Présente le contenu prepare par le controler
 Générer le HTML (ou PDF, ou d’autres)
Rq : sans changer le contenu, on peut le générer sous plusieurs formes de présentation.
Répartition ?
2
Modèle transactionnel
Serveur de traitement
Composant
applicatif
Serveur de traitement
Serveur de traitement
Composant
controler + view
Composant
métier
ou
BD
Web services
C’est au véritable 3 niveaux sur support « web » (càd il y a une sous-traitance de traitement)
Requête de traitement
Serveur de traitement
Application
réseau
Serveur Web
Web service
BD
Poste client
Réponse
Web service :
 Appel de traitement distant sur support WEB
 Requête et réponse données brutes hors présentation codées en XML (un langage de balise
qui écrit un contenu structuré)
Ex :
<actions>
<ibm> 36 </ibm>
</actions>
Schéma (ou DTD)
C’est le document qui décrit ce que doit être le contenu échangé (ex : document XML). Cela
permet de vérifier si le format ou le contenu correspond bien à certains normes.
Dans les sites Web, HTML ne sépare pas le contenu de la présentation.
Exemple des notes
<note>
<emetteur> galland </emetteur>
<titre> Examen </titre>
<contenu> Il aura lieu … </contenu>
</note>
Schéma pure réaliste :
XML
HTML
Navigateur
réseau
Serveur Web
Composant
applicatif
Portail
Serveur Web
réseau
XML
Serveur Web
Eléments du langage HTML
4.1/ La page HTML et les éléments statiques
3
C’est un langage de balise, orienté présentation.
Différence : HTML & XHTML
 XHTML : c’est HTML écrit en conformité avec des règles bien formalisées telles que :
 quoter les attributs
Ex : color = « red » (au lieu de color = red)
 fermer les balises
 soit par une balise fermante
Rq : <br/> = <br> + </br> => « à la ligne »
 soit dans la balise ouvrante (auto-fermant)
Ex : <input … /> (au lieu de <input …>)
Liens hypertexte
Table
4.2/ Eléments de saisie
L’élément de saisie doit se trouver dans une action « form ».
Ex :
<form action = « … »>
…
</form>
Composants de saisie
3 types de composants disponibles :
 <input> : champ texte ou bouton
l’attribut type peut définir les composants suivants :
 text : champ texte mono-ligne
 password : champ texte non affiché
 checkbox : champ à cocher
 radio : bouton « radio », les radios de même name forment un groupe à choix unique
 submit : bouton qui déclenche l’envoi de la forme
 reset :bouton qui réinitialise les valeurs des champs
 hidden : champ caché
le couple (name, value) est le paramètre de la requête. Transmis à l’application
 <select> : liste à choix multiple
 <textarea> : champ texte multi-ligne
4.3/ Javascript
Ex :
<form action = “validation.jsp”>
<input type = “submit” value = “valider”>
<input type = “submit” onsubmit = “this.form.action =“menu.jsp”
</form>
Auto-submit
4
<form action = “validation.jsp”>
onchange =“submit”
</form>
4.4/ Feuilles de style CSS
4.5/ Mise en page
On n’utilise plus de « frame ».
2 méthodes :
 méthode usuelle avec « table »
 méthode moderne avec « div »
2007-02-01
Rappel :
Application Web
 Modèle de répartition
 Web Services
Caractéristique : traitement applicatif sous-traité
 HTML
 A la base :
 un langage d’élément textuel et images
 formes de saisie et leurs composants
 Plus élaboré :
 Javascript  ou +
 CSS
 Mise en page sophistiquée, etc.
 Panorama de quelques solutions pour le développement WEB
Exécution :
 Au sein du serveur WEB généralement par le biais de librairie dynamiques
d’extension au serveur WEB
 A l’extérieur du serveur WEB, le serveur WEB transmet la requête au composant qui
s’exécute dans le serveur de traitement WEB
Serveur de traitement
Serveur Web
Composants Web
BD
Ex :
 le processus APACHE exécute en son sein le PHP grâce à l’extension « modphp »
 IIS exécute en son sein les pages ASP
« thread » : la concurrence interne des ? => multithread pour le bon
fonctionnement su serveur

 CGI (Common Gateway Interface)
5
Lance le processus
q = java
Serveur de traitement
Send cgi
Search.exe
Web
BD
? q = java
HTML
En C ou C++
Exemple : WEBMIN (Interface de gestion d'un serveur web accessible par un
navigateur)
Navigateur
Backup
réseau
Apache
Serveur Web
Backup.exe

Perl (mod-perl)

Python
Python est un langage de programmation interprété, multi-paradigme.

PHP
Langage spécifique au Web.
Page PHP
La page dans laquelle on a la partie fixe (HTML) et la partie dynamique
Ex :
<?php
echo "Hello world"; (la partie dynamique)
?>

ASP (Microsoft « .NET »)
Page ASP
La page HTML avec C# (de moins en moins de VB)

JAVA (J2EE)
Page JSP (Java Server Pages)
Développement Web en Java (J2EE)

Serveur d’application WEB (J2EE)
Ex : TOMCAT (la Fondation Apache)
 Servlet (classe JAVA)
 Page JSP (compilée dans une servlet)
Servlet est orienté vers le code (programme) alors que
JSP est orienté vers la vue.
Ex : lorsqu’il s’agit d’un retour d’un fichier PDF, il est
préférable de choisir le Servlet
 SIMVC (Servlet enchainé sur JSP)
Rq : c’est la solution mixte des 2 solutions précédentes
OS
JVM
Requête +
paramètres
TOMCAT
Servlet
Web
HTML ou
autre
6
Servlet
C’est un simple composant applicatif (pas application). Ainsi, dans le code, il n’y a pas de
« main ».
C’est une classe dérivée de HttpServlet
 2 méthodes :
 doGet : recevoir et traiter une requête GET
 doPost : recevoir et traiter une requête POST
Page JSP
 HTML (partie fixe)
 Directives : <%@ … %>
 Code Java
Traitement :
<%
Code Java
%>
 Code Java
Affichage
<% = ... %>
CategoryList.jsp
<%
CategoryHome categoryHome = CategoryHome.getInstance() ;
Collection c = categoryHome.findAll() ;
Iterator i = c.iterator() ;
%>
<html>
<had>
</head>
<body>
…
<table>
<% while(i.hasNext()){
Category category = (Category).i.next() ;
%>
<tr>
<td> <% = category.getTitle()%></td>
// en faire un lien (hypertexte)
</tr>
<% … %>
</table>
En faire un lien envers booklist.jsp
<a href = “bookList.jsp?categoryID=<%=category.getId()%>”>
<%=category.getTitle()%>
</a>
Dans « booklist.jsp », pb : comment récupérer la valeur du paramètre « categoryId » ?
String id = request.getParameter(“categoryId”) ;
7
Rq: tout revient sous forme de « String » et si besoin, faire appel à la conversion vers
« int », « Date » ou « BigDecimal ».
findById  Category
category.getBooks()
iteration

Mise en œuvre
 Récupérer projet CVS « BookStore_web.start »
 Définir New Server  TOMCAT  répertoire d’installation de TOMCAT
 Vérifier BookStore (BD) (qui marche)
 Start Derby
 Create DB, Populate DB, list BookStore
 Run project on server
Application Web - Révision
2007-03-15
Caractéristiques:
C'est une application accédée par un navigateur.
L'application Web traditionnelle plutot est transactionnelle. Or, la tendance actuelle est d'avoir
des applications Web interactives. Pour ce faire, le navigateur devrait pouvoir exécuter du
JavaScript, du flash, etc.
Réalisation:
Navigateur (poste client)
Réseau (protocole HTTP)
--> Requête
<-- Résultat en HTML
Serveur Web
--> Requête + paramètres (ce sont toutes les valeurs saisies par l'utilisateur)
Rq: il y a souvent des formes (HTML) qui contiennent les paramètres, éventuellement du
JavaScript
<-- Renvoi du HTML
Serveur d'application (composant applicatif)
Serveur BD
Réalisation 3 aspects:
 contrôleur: navigateur de l'utilisateur dans l'application
8


Modèle: Traitement applicatif
Rq: ce sont les traitements applciatifs du métiers qu'on peut utilise quel que soit sur ou non
le Web. (càd ce qui est indépendant du Web).
View: HTML
Quelques techniques
Il y a 3 techniques majeurs sur le marché (90% du marché) :
 PHP
 ASP (Solution Microsoft .NET)
VB ou C#
 JAVA (pages JSP, J2EE)
Rq: ASP (environnement Microsoft) et JAVA sont tout à fait concurrents comme solution
Web.
En Java J2EE
Sevlet: c'est un composant JAVA qui s'exécute au sein du serveur d'applciation (ex:
TOMCAT).
J2EE est la norme d'interopérabilité, ce qui permet aux utilisateurs, quel que soit le
fournisseur, une pérénnité plus grande.
Page JSP:
Différence entre Page JSP et Sevlet
Sevlet est un composant JAVA (donc, un aspect programme). Or, la page JSP est orientée
View. C'est une page HTML qui contient le code applicatif JAVA. C'est donc un mixte.
Ex:
<%
du Java
%>
du HTML
<%
...
%>
Rq: l'inconvient est qu'on mélange les parties documentaire (code HTML) et applicatif (code
JAVA). C'est une solution rapide dans laquelle il y a une absence totale d'aspect modulaire.
Mais on essaie de faire le plus claire possible: au début, on met une grosse partie code JAVA
(partie contrôleur) qui permet de faire des traitements applicatifs. Plus loin, on met des code
JAVA (orienté view) pour l'affichage.
MVC:
On peut avoir des pages JSP sans JAVA, même sans HTML.
On peut faire appel à une balise de haut niveau qui génère tout seul la partie HTML. C'est la
conception MVC.
Rq: Framework
Ex: Eclipse, integrated development environment (IDE)
il y a 2 Frameworks:
9

STRUTS
Rq: un produit ancien, avec des défauts, mais très répendu => un standard
 JSF (Java Server Faces)
Rq: c'est un nouveau qui a tendance à s'imposer dans le futur comme un standard
Rq: si l'on choisit un Framework, il faut qu'on insère les applicatifs dans son cadre.
Cf. tmp.jsp (15 mar 07 12:07)
...
value= « #{catalogBacking.category.books} » // on cherche la category book
...
action= « #{catalogBacking.selectBook} » // selectBook
Page JSF (tmp.jsp (15 mar 07 12:07)) décrit des composants graphiques de haut niveaux (càd
les composants vont plus loin qu'un composant simple usuel) dont les propriétés et les
méthodes sont liées à une classe Java (backing)
Ces conposants savent générer le HTML correspondant. En fait, finalement le langage HTML
est très pauvre et il y a des langages très riche qui n'existent pas en HTML (ex: composant
pickList du JSF, ce qui se réalise très dificilement en HTML).
Demo JSF
 reprndre par CVS : « Bookstore-egb-jsf »
 Aspect BD « Hibernate »
Cf. Book.java (15 mar 07 11:03)
Rq:
@Entity()
avant
la
classe
Book,
@ManyToOne(),
@ManyToMany(targetEntity=model.Author.class)
ces notations permettent à l'Hibernate de lire dans les BD tout seul.
@Transient(),
Réponse: JSF & MVC
1/ l'aspect BD:
Grâce à des notations (ex: @Entity()), l'Hibernate est capable de lire la BD.
2/ En quoi une page JSP différence d'une page JSF
il n'y a plus de JAVA
dans les pages JSF, ?
IceFaces Vori
 component : Showcase
 Auction monitor
Oracle ADF
10
Téléchargement