Child pages
  • Développement de canaux uPortal

Diapositive 1

 

 

Formation au développement de contenus applicatifs pour ESUP-Portail (uPortal)

 


Diapositive 2

 

 

Plan

 


Diapositive 3

 

 

Plan

 


Diapositive 4

 

 

Plan

 


Diapositive 5

 

 

Plan

 


Diapositive 6

 

 

Plan

 


Diapositive 7

 

 

Plan

 


Diapositive 8

 

 

Plan

 


Diapositive 9

 

 

Plan

 


Diapositive 10

 

 

Plan

 


Diapositive 11

 

 

Plan

 


Diapositive 12

 

 

Plan

 


Diapositive 13

 

 

Fonctionnement uPortal

 

Les canaux produisent des informations au format XML.

Le Framework fusionne les arbres XML des canaux s'affichant dans une même page.

Le moteur XSLT choisi la feuille de style correspondant au client et réalise la transformation afin de produire des données correspondant au type de client.

Le rendu est ind é pendant des donn é es produites par l'application

 


Diapositive 14

 

 

Java vs PHP

 


Diapositive 15

 

 

Java vs PHP

 

Allure de la courbe montrant la vitesse de service en fonction du nombre de connexions.

Explication de l'allure de la courbe par le mécanismes des contextes imbriqués.

 


Diapositive 16

 

 

XML vs HTML

 

HTML – Langage de balises restreint

 

Les données sont mélangées aux informations concernant la mise en forme (look)

Lorsque le HTML est généré dynamiquement, il devient très compliqué de faire évoluer le look

 


Diapositive 17

 

 

XML vs HTML

 

XML – Langage de balises généralisé

 

Règles strictes concernant l'imbrication et l'ouverture/fermeture de balises.

Ainsi HTML est un sous-espace de XML.

Si du code HTML est inclus dans un fichier XML quelconque, il est impératif de fermer toute balise ouverte y compris les 'mono' balises :

<br> <br/>

<input type="text" name="toto"> <input />

<meta- > <meta- />

 


Diapositive 18

 

 

XML vs HTML

 

XSL – Sous espace de XML (certains noms de balise sont réservés, ils sont tous préfixés par xsl: )

 

XSL est destiné à la transformation d'arbres XML.

Le langage de sortie après la transformation est quelconque. On peut trouver du XML (ainsi que ses sous-espaces, XML, XSL, HTML…) ou des langages complètement différents (FO pour la création de fichiers PDF, PS pour l'impression directe …)

Dans tous les cas, XSL ne modifie jamais la sémantique des données, il se contente de les mettre en forme.

 


Diapositive 19

 

 

Eclipse

 

http://www.eclipse.org

Miroir pour les téléchargements : http://sunsite.informatik.rwth-aachen.de/eclipse/downloads

 


Diapositive 20

 

 

Perspectives / Vues

 

Une perspective est une collection de vues ayant trait à un thème commun

Ici la perspective Java composée des vues suivantes :

Editeur Java

Outline : vue logique de la classe courante

Package explorer : vue des fichiers du projet

Ant : vue des tâches ANT

LogWatcher : vue du fichier de log de l'application

Console : évènements (compilation, déploiement, exécution etc.)

Problems : erreurs et warning de compilation

 


Diapositive 21

 

 

Perspectives / Vues

 

Ici la perspective Debug composée des vues suivantes :

Editeur Java

Variables : inspection des variables de la classe courante

Debug : vue des threads et commandes d'exécution en mode pas à pas

 


Diapositive 22

 

 

Perspectives / Vues

 

Ici la perspective CVS composée des vues suivantes :

Editeur standard

CVS Repositories : explorateur de CVS

CVS Ressource History : historique des versions du fichier courant

 


Diapositive 23

 

 

Structures XML

 

Deux façons de construire son XML :

Utiliser des attributs de noeud

Utiliser des sous-noeuds

 


Diapositive 24

 

 

Structures XML

 

Utiliser au maximum les attributs de nœuds

Utiliser les sous-nœuds pour les attributs multivalués

 

Éditeurs XML :

XML Buddy pour Eclipse (version gratuite & version payante)

Cooktop (gratuit)

 


Diapositive 25

 

 

Feuilles de style XSL

 

Sous ensemble de XML

Toutes les balises commençant par xsl:XXXX sont des balises réservées.

XSL possède des instructions permettant de naviguer dans un arbre XML et d'appliquer des templates à tout ou portion de cet arbre

 

Éditeurs XSL :

XML Buddy pour Eclipse

Cooktop

 

 


Diapositive 26

 

 

XSLT

 

C'est le moteur qui réalise la transformation du XML à l'aide d'une feuille de style XSL.

Le format de sortie peut être quelconque, les plus courants sont HTML, FO (pour réaliser des PDF) et … XML !

 

Cooktop permet à partir d'une feuille XML et d'une feuille XSL de réaliser la transformation en HTML et de visualiser le résultat.

 


Diapositive 27

 

 

 


Diapositive 28

 

 

 


Diapositive 29

 

 

 


Diapositive 30

 

 

 


Diapositive 31

 

 

 


Diapositive 32

 

 

 


Diapositive 33

 

 

 


Diapositive 34

 

 

 


Diapositive 35

 

 

uPortal CWebProxy Channel

About This Document

This document reflects the current version of CWebProxy. See the old documentation for versions prior to uPortal 2.1. See Changes for a summary of the major changes. The latest version of this document can be found at the CWebProxy home page. There is also a tutorial on creating channels using CWebProxy.

Purpose

CWebProxy allows incorporation of web-based services as channels, regardless of what technology is used to implement them. It provides mechanisms for connecting to and rendering HTML and XML services. Pages are refreshed and kept in-channel when they change. HTTP standards are followed, allowing communication between the browser and dynamic back-end applications. Mechanisms are provided for passing user-specific information to the back-end application, as well as ways to support local interface technologies on a per-channel basis. (Such as encryption, shared secrets, single-sign-on, modification of http request headers, etc.)

How It Works

This section describes the functionality of CWebProxy in general terms. Specifics of configuration and use are covered in the sections following.

Web applications are written to interact directly with users through their browsers. When a portal incorporates such an application, it must intercept this communication to tailor it for the portal environment. This is done by rewriting the application's output appropriately. In particular, rewriting any URLs so that they will go through the portal if appropriate, rather than directly to the back-end application or elsewhere. Other mechanisms allow sharing of information between the portal and the application, to aid application functionality. Caching is available to improve performance.

Rewriting Application Output

The key mechanism is " pass-through ". It is the means for passing request parameters through the portal to the application. There are currently four levels of pass-through supported:

all : all links stay in the channel.

application : references to the application stay in the channel. Other links go outside the portal framework. I.e. they are normal links that replace the portal in the browser window.

marked : the application indicates which links should stay in channel by adding a tag to those URLs.

none : all links will leave the portal framework.

Note that it is possible to change the pass-through type at any point, so if a link is followed that would best be served by another pass-though type, it is a trivial matter to change it at that time.

The output from applications is rewritten in four stages. HTML, XHTML, and WML are supported in the code as distributed.

JTidy : If the cw_tidy attribute is on, the application's output is run through JTidy to convert it from HTML to well-formed XHTML.

AbsoluteURLFilter : This converts relative URLs to absolute ones.

CWebProxyURLFilter : Rewrites URLs according to cw_passThrough or cw_download.

XSL/T : The XML is passed through a stylesheet according to the channel parameters and the media type. Static and runtime data parameters are passed to the stylesheet. This feature is not used by the distributed stylesheets, but may prove useful to custom-written stylesheets, particularly those with no URL Filters.

CWebProxy will use the same method (GET or POST) to call the application as was used to call the portal. Since the portal is intercepting HTTP requests aimed at the application, this will result in the correct method being used, according to what the application expects.

CWebProxy will filter out any attribute/value pairs in the query string which are portal-specific, and hand on any others that were in the URL to the application. Note that querystrings may also contain keywords without using the attribute/value format. In this case they are also passed on to the application. Although you mix this type of querystring with mechanisms that will generate attribute/value pairs, if it sees this happening, CWebProxy will pass the keywords by adding a "keywords" attribute with the appropriate value.

In the case where CWebProxy needs the channel to provide refreshed output, it will call the application with no parameters, as is usual for HTTP.

In some cases, you don't want a link to go through the normal mechanisms, but instead wish it to be handled as a download for an object with its own MIME type. CWebProxy includes a way to indicate this.

Information Sharing

Applications can benefit by getting information from the portal. CWebProxy supports the standard HTTP Cookie mechanism for keeping session and state information between page requests. Additionally, it can pass information on the user from the uPortal IPerson object. There is also support for customizing the communications to fit local policy and technical infrastructure.

Session Support

Support is provided for cookies as specified in the original Netscape specification, as well as RFC 2109 and RFC 2965. Only the Cookie , Cookie2 , Set-Cookie , and Set-Cookie2 headers are currently processed.

Cookies are not maintained between portal logins. Once you logout of the portal, your cookies are discarded.

Applications maintaining sessions via URL rewriting in http query strings should also work. Other forms of URL rewriting to maintain state probably will not work. Most applications use cookies by preference if available, which they are.

IPerson Attribute Passing

uPortal maintains certain user information (called the IPerson object), possibly aggregated from several sources, for each active user session. CWebProxy allows the application to request this information. At publish time, you may configure which information is allowed to be passed to applications, and you may also choose to always pass particular attributes by default. These are sent as additional http request parameters. A uPortal configuration property sets the defaults for channels that do not specify publish-time values.

Local Connection Context

Connecting to, and communicating with, certain applications may require custom modifications to the communications. For example, you might need to add special encryption, shared secret passing, hooks into authentication mechanisms, addition or filtering of headers or cookies, etc. CWebProxy uses a mechanism called Local Connection Context to simplify and modularize this process on a per-channel basis.

Caching

Channel output maybe be cached to improve efficiency. The three aspects of caching are:

Mode : To cache or not to cache. May be none (normally don't cache), or all (cache by default).

Scope : Affects which instances of this channel share cached data. At this time only instance caching is available.

Timeout : How long cached output is valid in "all" mode.

For each of these, defaults are set in uPortal properties which may be overridden for each channel at publish time. Applications may later change the defaults for a channel instance, or override them for a single page request. Cache scope and mode can only be made more restrictive, not less.

According to the HTML specification, "If the processing of a form is is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be GET. Many database searches have no visible side-effects and make ideal applications of query forms...If the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be POST." For this reason, POST requests are not cached.

Configuration

Static Data

Except as noted, parameters are identical for both static and runtime data. The channel state variables are initially set acccording to static data, or defaults. Runtime data modifies the equivalent channel state variables. All parameters are then passed through to the stylesheets based on the current state. The parameters are:

cw_xml : a URI representing the source XML or HTML document. I.e. the backend application.

cw_ssl : a URI representing the corresponding .ssl (stylesheet list) file.

cw_xslTitle : a title representing the stylesheet (optional). If no title parameter is specified, a default stylesheet will be chosen according to the media.

cw_xsl : a URI representing the stylesheet to use. If cw_xsl is supplied, cw_ssl and cw_xslTitle will be ignored.

cw_info : a URI to be called for the info event.

cw_help : a URI to be called for the help event.

cw_edit : a URI to be called for the edit event.

cw_tidy : if set to on , filter the source document through JTidy, converting HTML to XHTML.

cw_passThrough : indicates that runtime data not specific to the portal is to be passed through. If passThrough is supplied, and not set to "none", additional runtime data parameters and values will be passed as request parameters to the cw_xml .
cw_passThrough values:

none : (default). Don't do anything.

marked : If runtime data includes cw_inChannelLink , pass through other runtime data as request parameters.

application : Only URLs referring to the application are kept in-channel.

all : All link URLs are rewritten to go through the channel.

cw_cacheDefaultTimeout - Default timeout in seconds.

cw_cacheDefaultMode - Default caching mode. May be none (normally don't cache), or all (cache everything).

cw_cacheTimeout - override default for this request only. Primarily intended as a runtime parameter, but can user statically to override the first instance.

cw_cacheMode - override default for this request only. Primarily intended as a runtime parameter, but can user statically to override the first instance.

cw_person - IPerson attributes to pass. A comma-separated list of IPerson attributes to pass to the back end application. The static data value will be passed on all requests not overridden by a runtime data cw_person.

cw_personAllow - Restrict IPerson attribute passing to this list. A comma-separated list of IPerson attributes that may be passed via cw_person. An empty or non-existent value means use the default value from the corresponding property. The special value "*" means all attributes are allowed. The value "!*" means none are allowed. Static data only.

upc_localConnContext - LocalConnectionContext implementation class. The name of a class to use when data sent to the backend application needs to be modified or added to suit local needs. Static data only.

Properties

CWebProxy has a few properties which act as portal-wide defaults for equivalent static data (channel publish-time parameters). These are set in the properties/portal.properties configuration file.

cache_default_timeout : Default value for cw_cacheDefaultTimeout .

cache_default_mode : Default value for cw_cacheDefaultMode . If you're not sure what to use, disable caching by default with the value none .

person_allow : Default value for cw_personAllow . An empty value means everything is restricted, disabling this mechanism. A special value of * means no restrictions.

 

 

 


Diapositive 36

 

 

 


Diapositive 37

 

 

 


Diapositive 38

 

 

 


Diapositive 39

 

 

 


Diapositive 40

 

 

Interfaces de programmation

 

IChannel

 


Diapositive 41

 

 

Interfaces de programmation

 

IChannel – Cycle de vie

 


Diapositive 42

 

 

Interfaces de programmation

 

IPrivileged – IPrivilegedChannel

 


Diapositive 43

 

 

Interfaces de programmation

 

IMultithreadedChannel

 

Utile pour réaliser des canaux peu coûteux pour lesquels l'utilisateur courant n'influence pas le comportement du canal.

 


Diapositive 44

 

 

Interfaces de programmation

 

IServant

 


Diapositive 45

 

 

Interfaces de programmation

 

ICacheable

 


Diapositive 46

 

 

Interfaces de programmation

 

ICacheable – Cycle de vie

 


Diapositive 47

 

 

Interfaces de programmation

 

IMimeResponse

 


Diapositive 48

 

 

Interfaces de programmation

 

IMimeResponse – Cycle de vie

 


Diapositive 49

 

 

 


Diapositive 50

 

 

 


Diapositive 51

 

 

 


Diapositive 52

 

 

 


Diapositive 53

 

 

 


Diapositive 54

 

 

 


Diapositive 55

 

 

 


Diapositive 56

 

 

 


Diapositive 57

 

 

 


Diapositive 58

 

 

 


Diapositive 59

 

 

generateKey

Cette méthode doit générer une clé qui décrit l'état courrant du canal.
Elle est appelé a chaque affichage du canal.

Elle renvoie un objet ChannelCacheKey qui peut être généré comme suit :

Portée

Instance

Si vous avez deux fois le même canal dans votre environment (donc 2 instances) chaque instance utilisera un cache différent même si les clés sont les même.

k.setKeyScope(ChannelCacheKey.INSTANCE_KEY_SCOPE);

Système

Le cache est partagé par toutes les instances d'un même canal pour une même clé.

k.setKeyScope(ChannelCacheKey.SYSTEM_KEY_SCOPE);

Validité

On peut utiliser un objet afin de tester la validiter du cache.

Lors de la création de la clé on la lie a un objet. Lors du test de validité du cache on pourra accéder à cette objet. (Exemple : on stocke le timestamp lors de la création de la clé)

k.setKeyValidity(new Long(System.currentTimeMillis()));

 

 


Diapositive 60

 

 

isCacheValid

Si elle renvoie TRUE on ne rafraichit pas le cache dans le cas contraire (FALSE) on relance tous le traitement du canal.

Cette méthode un objet. Cet objet est celui qi a été stocké lors de l'opération setKeyValidity.

 

 

 


Diapositive 61

 

 

 


Diapositive 62

 

 

 


Diapositive 63

 

 

 


Diapositive 64

 

 

 


Diapositive 65

 

 

 


Diapositive 66

 

 

 


Diapositive 67

 

 

 


Diapositive 68

 

 

 


Diapositive 69

 

 

 


Diapositive 70

 

 

 


Diapositive 71

 

 

 


Diapositive 72

 

 

 


Diapositive 73

 

 

 


Diapositive 74