Pour bien comprendre le principe utilisé dans direct to java il faut commencer par comprendre celui de WO java client et surtout d'une appli cocoa en particulier.
Tout part de la façon dont sont gérés les évènements sous Cocoa.
Saches que sous cocoa tu manipules des OBJETS et rien d'autre.
Quand tu composes ton interface graphique en utilisant les OBJETS de la Palette d'Interface Builder, tu crées un fichier nib dans lequel ces objets 'dorment'.
Quand tu lances ton appli, la méthode awakeFromNib est la 1ère exécutée par le runtime.
Cette méthode a pour but de réveiller' les objets de la nib.
Le premier objet à recevoir le message c'est la fenêtre de l'appli.
Celle-ci à son tour réveille tous les objets qu'elle contient et ainsi de suite.
Dans ce processus de réveil, chaque objet se dessine en utilisant chacun les fontions de dessin qui le concerne.
Ces fonctions chaque objet les trouve dans les librairies système appelées frameworks.
Apple a appliqué ce même principe pour WO Java client.
Saches que dans le développement d'une application java client on utilise Interface Builder et non WebObject Builder.
Donc on génère bien une NIB..
Lors de l'exécution de cette application, qui ne l'oublions pas est
une appli web, (requête URL...), Cette nib ainsi qu'une applet sont téléchargés sur le poste de travail.
Supposons que c'est un PC sous Windows.
L'applet une fois sur le poste va simuler l'envoi de l'évènement à la nib et va effectuer le même processus décrit plus haut.
sauf que, et c'est TRES IMPORTANT, les objets de l'interface en se dessinant utilsant les fonctions (ou apis swing) du framework java du PC et génèreront dans ce cas une INTERFACE WINDOWS.
Quand je martèle que sous WO l"interface ou la page web est construite de A à Z pendant l'éxécution de la requête, c'est ça.
Vois-tu l'un des points forts de l'objet sous NeXT et cocoa aujourd"hui c'est l'utilisation par les ingénieurs qui ont conçu ses outils, de la notion d'exécution dynamicque de manière extrème.
Quand tu vois bien OS X ce principe est enfoui dans certaines fonctionnalités du système.
Un exemple si dans une appli tu appelles une fonction se trouvant dans un package de fonctions, dans d'autres systèmes gérant l'appel dynamique, c'est tout le package qui est monté. Sous OS X le système attend le dernier moment pour ne monter que la fonction utilisée.
C'est ce qu'on appelle le lazy binding.
Ce principe tu le trouves sans faire attention sosu cocoa quand tu utilises les types IBOutlet ou id pour certaines variables.
C'est parce que le type de l'objet est défini au derbier moment c"est à dire au moment où l'objet reçoit le message.
C'est à ce moment que le runtime détermine son type.
Objective-C est à cet égard fortement dynamique comparé à Java. Quant à C++ c'est pas la peine d'en parler.
Toutes ces 'siouxeries' font le charme de ce langage et de cocoa.
Direct to java est une variante de java client. Cest comme direc to web est une variante de WO html.
Apple a mis au point ces 2 variantes de WO pour permettre de créer très rapidement une appli simple ayant accès à une base de données.
En effet si tu veux faire une appli accèdant à une base et permettant aux utilisateurs d'éffectuer des opérations de lecture et mise à jour, tu te casses pas la tête tu utilises Direct to web pour une appli avec génération de pages web (internet), et Direct to Java client pour une appli avec génération d"une interface graphique (intranet).
J'espère avoir été clair.
A+
[
[29 juin 2001 : message édité par Manu]
