Version imprimable du sujet

Écrit par : Tecka 8 Mar 2008, 15:48

C'est le grand jour je me lance, ras le bol de passer pour un gros noob
je me lance dans la programmation mais il faut que je reprenne tout
depuis le début , ma dernière expérience en programmation remonte
à la calculatrice Casio FX850-P. Il me faudrait en premier un environnement
pour faire du Java, vous avez quelque chose de simple et gratos ?
Et si en plus il y a un petit didacticiel c'est encore mieux
Sinon des titres de livres genre "le Java pour les nuls".
Merci

Edit :Je viens de DL Eclipse 3.3 et NetBeans 6.0.1

Écrit par : Grimaldus 8 Mar 2008, 16:45

Ben justement java pour les nuls est un bon débuts, faut que je m'y mette aussi mais j'ai pas le temps actu il faut d'abord que je finisse les entretiens

Écrit par : Ogur 8 Mar 2008, 16:57

Je bosse sous Eclipse et pour le moment je n'ai absolument rien à lui redire (De plus c'est compatible toutes plateformes).

Pour apprendre le java il doit y avoir une floppée de bouquins qui se valent probablement tous en ce qui concerne "l'introduction" à la programmation java.

Écrit par : atarxerxes 8 Mar 2008, 17:09

Comme plate-forme de développement je plébiscite aussi Eclipse (personnellement j'utilise au boulot une distribution enrichie pour le développement web MyEclipse, c'est dire si c'est bien ).

Des liens :
- Eclispe donc : http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/europa/winter/eclipse-java-europa-winter-macosx-carbon.tar.gz
- in english le tutorial J2SE (la partie Java qui ne concerne pas le web) de Sun : http://java.sun.com/docs/books/tutorial/ au moins pour survoler un peu
- les tutoriaux de base de developpez.com : http://java.developpez.com/cours/#cours
- la faq Eclipse de developpez.com : http://java.developpez.com/faq/eclipse/

Je conseille d'abord de créer des programmes en ligne de commande, le temps de maîtriser les classes de base et les concepts du langage, et d'après éventuellement chercher à des applications avec interface graphique.

Le mieux quand même (indispensable selon moi) c'est d'avoir des notions d'algorithmique. En gros savoir comment se résolvent les problèmes de programmation simples (comment calculer une factorielle,...). Le jeu est ensuite de savoir découper un problème complexe, en problèmes de plus en plus simples, jusqu'à obtenir plein de petits problèmes faciles à résoudre.

Pour réaliser rapidement un premier exemple :
- lancer Eclipse
- choisir "File -> New -> Project...", puis "Java -> Java Project"
- choisir "Next"
- choisir un nom pour le projet, puis "Finish"
- ouvrir le répertoire du projet, puis le répertoire "src"
- créer une classe "TestJava" : File -> New -> Class
- choisir un nom puis "Finish"
- copier le contenu de la classe pour ressembler à celu-là :

- cliquer sur la flèche verte en haut dans la barre des actions (Run as Java Application)
- la console en bas affiche normalement le résultat de l'exécution du programme : "Il est actuellement : 17:45:08" => ça marche

(par contre sur MacOSX je sais pas écrire des accolades dans eclipse, comment qu'on fait? )

Écrit par : Tecka 8 Mar 2008, 18:07

tu fait comme ça » «
Alt+7 et shift + Alt +7

Écrit par : atarxerxes 8 Mar 2008, 18:18

Ah ok, parce que le raccourci standard n'est pas "maj+alt+4"? Ou alors c'est que je développe trop sur Windows où c'est "AltGr+4"?

Écrit par : Gamoul 8 Mar 2008, 18:21

Pour faire les accolades { }, c'est Alt Parenthèse (5 ou °) et pour faire les crochets [ ] , il suffit de rajouter Maj.

Écrit par : atarxerxes 8 Mar 2008, 19:02

Effectivement Gamoul, c'est bien ça dans TextEdit

Mais pourquoi tu veux développer Tecka? Juste pour le fun, ou tu as un but (faire une application de gestion de ton stock, briller devant ta famille,...)?

Écrit par : Ogur 8 Mar 2008, 20:46

Les buts viennent tout seuls Atar

J'avais aucune idée pour quoi j'allais me servir de java quand j'ai commencé (bon, c'était un cours obligatoire et j'étais tout de même intéressé...). Mais depuis peu je planche sur un petit programme chargé d'analyser mon temps de parcours entre ma coloc' et l'école selon le chemin que j'emprunte et un programme chargé de gérer le classement des joueurs et équipes de Baby-Foot (nous sommes de petits joueurs invétérés ).

Une fois qu'on a les bases et de la motivation il n'y a qu'à laisser galoper son imagination...

Écrit par : atarxerxes 8 Mar 2008, 21:00

Le problème (et je parle d'après mon expérience ) c'est que pour apprendre à programmer ça va demander un effort de plusieurs mois. Or, des efforts aussi longs, si on est à l'école ou à l'armée (bref si on n'a pas le choix) on peut les maintenir sur une telle durée, mais si on n'a pas une grosse motivation, ou des buts réguliers à atteindre, c'est dur. Si c'est juste pour le fun quoi, va falloir une grande rigueur morale pour aboutir

Écrit par : Gamoul 8 Mar 2008, 21:10

Je suis d'accord, si on a pas le temps de vraiment s'y mettre, on risque de faire les choses trop vite et d'acquérir de mauvais réflexes.

Écrit par : Diurn 9 Mar 2008, 05:23

pourquoi tu commences avec le java ( juste par curiosité ) ?

Écrit par : Tecka 9 Mar 2008, 10:22

Je fais ça pour ma culture personnel sans vraiment de but précis , du temps on en trouve
toujours avec de la bonne volonté . J'aime bien savoir comment ça marche et ce pour tout
depuis tout petit je me suis toujours amusé à tout démonter et remonter.
J'ai deux gros mémento médical , un traité sur la mécanique des fluides , deux ou trois
bouquins sur la psychologie , une bible , un Coran ...............
J'ai pris le Java car il me semble que c'est le langage le plus utilisé en info et le plus "facile"
pour commencer,le C++ me parait un peu plus obscure

Écrit par : Tecka 9 Mar 2008, 10:24

Je fais ça pour ma culture personnel sans vraiment de but précis , du temps on en trouve
toujours avec de la bonne volonté . J'aime bien savoir comment ça marche et ce pour tout
depuis tout petit je me suis toujours amusé à tout démonter et remonter.
J'ai deux gros mémento médical , un traité sur la mécanique des fluides , deux ou trois
bouquins sur la psychologie , une bible , un Coran ...............
J'ai pris le Java car il me semble que c'est le langage le plus utilisé en info et le plus "facile"
pour commencer,le C++ me parait un peu plus obscure

Écrit par : Tecka 9 Mar 2008, 10:23

Je fais ça pour ma culture personnel sans vraiment de but précis , du temps on en trouve
toujours avec de la bonne volonté . J'aime bien savoir comment ça marche et ce pour tout
depuis tout petit je me suis toujours amusé à tout démonter et remonter.
J'ai deux gros mémento médical , un traité sur la mécanique des fluides , deux ou trois
bouquins sur la psychologie , une bible , un Coran ...............
J'ai pris le Java car il me semble que c'est le langage le plus utilisé en info et le plus "facile"
pour commencer,le C++ me parait un peu plus obscure

Écrit par : Tecka 9 Mar 2008, 10:25

Je fais ça pour ma culture personnel sans vraiment de but précis , du temps on en trouve
toujours avec de la bonne volonté . J'aime bien savoir comment ça marche et ce pour tout
depuis tout petit je me suis toujours amusé à tout démonter et remonter.
J'ai deux gros mémento médical , un traité sur la mécanique des fluides , deux ou trois
bouquins sur la psychologie , une bible , un Coran ...............
J'ai pris le Java car il me semble que c'est le langage le plus utilisé en info et le plus "facile"
pour commencer,le C++ me parait un peu plus obscure

Écrit par : Tecka 9 Mar 2008, 10:21

Je fais ça pour ma culture personnel sans vraiment de but précis , du temps on en trouve
toujours avec de la bonne volonté . J'aime bien savoir comment ça marche et ce pour tout
depuis tout petit je me suis toujours amusé à tout démonter et remonter.
J'ai deux gros mémento médical , un traité sur la mécanique des fluides , deux ou trois
bouquins sur la psychologie , une bible , un Coran ...............
J'ai pris le Java car il me semble que c'est le langage le plus utilisé en info et le plus "facile"
pour commencer,le C++ me parait un peu plus obscure

Écrit par : Gamoul 9 Mar 2008, 13:06

lol t'as même pas encore commencé le java que tu bug déjà

Écrit par : DeviSor 9 Mar 2008, 13:10

LOL le Tecka quoi.
Posté 5 fois de suite, c'est très classe

Écrit par : atarxerxes 9 Mar 2008, 13:21

Voilà qui faisait ramer le forum ce matin par ses envois multiples...

Mais si tu veux savoir "comment ça marche" c'est pas plutôt des cours d'électronique basique + architecture hardware + théorie des compilateurs qu'il te faut? Un langage y'a rien à comprendre, c'est comme apprendre l'anglais, non pas pour s'en servir mais pour savoir "comment ça marche" : ben en fait l'anglais (ou le Java), il n'y a rien à comprendre d'intrinsèque au langage lui-même, c'est juste un ensemble de conventions comme tous les moyens de communication.
Apprendre comment marche un ordi (par exemple la manière dont est effectuée une multiplication en terme de signaux électriques qui se baladent entre le CPU et les mémoires), et ce que fait un compilateur (comment est traduit une instruction conditionnelle en assembleur qui est forcément linéaire, qu'est-ce qui se passe quand on appelle une fonction, au niveau du code produit, qu'est-ce qui différencie une classe d'une source C,...) me semble plus intéressant pour comprendre un ordinateur de manière générale.
Le mieux c'est peut-être de se tourner vers le CNED si c'est pour la culture générale (ou alors je peux te faire parvenir mes cours d'ingénieur?)

Écrit par : Grimaldus 9 Mar 2008, 14:23

Je trouve Tecka trop balaise car il post 5fois et ces posts ne s'affiche même pas dans l'ordre chronologique (ça c'est le plus fort )

Écrit par : Sire Diablo III 9 Mar 2008, 14:32

Ah ouais carement En fait le titre de Tecka devrait être "Champ de Bouletisme Aigu", car il fait buguer tous les appareils autour de lui

Écrit par : Diurn 9 Mar 2008, 16:33

faut se lancer dans l'assembly code au moins une fois pour comprendre ( même si c'est chiant comme pas possible ).. ou encore le machine code mais y'a pas grand intêret

Écrit par : atarxerxes 9 Mar 2008, 16:55

L'assembly code, c'est bien beau, mais tous les choix d'organisation qui y sont faits, découlent directement de comment sont faits les compilateurs de nos jours. Donc autant étudier les compilateurs (et comme TD écrire un compilateur Java simplifié), c'est très intéressant (même si ça ne sert vraiment que quand on cherche à optimiser au max son code).
Enfin par exemple moi je m'en suis inspiré la semaine dernière pour écrire une petite application qui me génère, à partir d'un ensemble de tables SQL liées entre elles, un module complet pour administrer ces tables (depuis les classes de communication avec la BDD jusqu'aux pages JSP)

Écrit par : atarxerxes 10 Mar 2008, 07:47

A la limite Tecka ça m'intéresse de m'entraîner à faire de la formation.
Je peux essayer de concocter un tutorial en plusieurs étapes (1 par semaine par exemple) pour développer une petite application de gestion de stock en partant de zéro connaissance en Java. Ça t'interesserait?
Y'en aurait au moins pour une vingtaine de leçons je pense.

Écrit par : Tecka 10 Mar 2008, 08:45

Je suis partant ça commence quand?
J'avoue être pour l'instant un peu perdu sur Eclipse entre
les différents onglets sur la droite car je démarre toujours
en JRE et pas SDK toute aide est la bien venu

Écrit par : Sire Diablo III 10 Mar 2008, 08:52

Si je trouve le temps ça pourrait m'intéresser aussi

Écrit par : Gamoul 10 Mar 2008, 12:53

Moi aussi, la dernière fois que j'ai fait du java, c'était tout en ligne de commande

Écrit par : atarxerxes 10 Mar 2008, 13:12

Vendu alors, j'essaie de réfléchir à une première leçon cette semaine

Écrit par : Gamoul 10 Mar 2008, 13:28

Cool, merci

Écrit par : CantKillemAll 10 Mar 2008, 17:33

Y'a de la place pour la session JPLNBA* ?







* : Java Pour Les Nuls By Atarxerxes

Écrit par : Ogur 10 Mar 2008, 20:17

Atar, j'ai les transparents et exercices de mon premier semestre. Tu veux que je te/leur montre ça ? (Si tu complètes un peu, ça peut le faire )

Écrit par : atarxerxes 10 Mar 2008, 21:18

Trop tard (mais bon tu peux les mettre, ça peut compléter). N'hésitez pas à souligner si un truc est pas clair, j'ai du mal à définir la barrière "ceci est évident"/"ceci demande certaines connaissances préalables".


Leçon 0 : le langage Java

Un langage de programmation est un langage dans lequel s'exprime le développeur pour donner des ordres à la machine, afin d'automatiser certaines tâches.
A l'origine (moderne, donc Unix) de la programmation était le C.

C pas compliqué
Le C est un langage à programmation impérative classique. La motivation à la base de la création du C est d'avoir une manière facile, puissante et efficace de donner des ordres à la machine. Le C est la base de Unix.
Il se caractérise principalement par les particularités suivantes.
Le développeur écrit des fichiers en texte clair (de l'anglais simplifié et un peu bizarre). On appelle ceux-là les fichiers sources.
La machine ne comprend pas directement ce qu'écrit le développeur dans ces fichiers (sinon on lui donnerait des ordres directement à la voix). Il faut d'abord les transformer dans le seul langage que comprend un ordinateur : le code assembleur (ce sont directement une suite d'appels à des instructions du processeur). Le traducteur, qui s'occupe de produire ce code assembleur à partir des fichiers sources est un compilateur.
Pour le C, un fichier source a pour extension ".c" et un fichier source compilé ".o" (en général).
Rappel : une fonction, en mathématique comme en programmation est une boîte noire qui prend un certain nombre de paramètres pour produire un retour à parti de ceux-ci. Par exemple, on peut définir que une fonction "somme" qui prend deux paramètres a et b, et dont le retour est a+b.
Le C n'est qu'une suite d'appels de fonctions : il existe une fonction spéciale (main(...)) dont le nom, les paramètres et le retour sont toujours les mêmes, par convention. Cette fonction sera toujours le point d'entrée d'une application en C : chaque fois qu'on demande l'exécution d'un code compilé C, c'est sa méthode main(...) qui est appelée.
Donc un programme C se décompose comme cela :
- on demande l'exécution du code compilé
- cela appelle la fonction main(...) du code compilé
- les différentes instructions à l'intérieur de la méthode main(...) sont exécutées
- la méthode main(...) renvoie sa valeur de retour, qui constitue le code retour du code compilé (on peut par exemple trouver ce code retour écrit dans la console lorsqu'une application plante).
Le but d'un programme est d'effectuer un traitement d'informations de manière automatique (c'est de là que vient le terme français "informatique"). Or les informations ne sont pas abstraites, elles se traduisent en types simples (entier, chaînes de caractères) ou plus compliqués (un ensemble de types simples).
En C, par défaut on ne trouve que des types simples (int pour un entier, char pour un caractère) et une manière de définir des types compliqués à partir de ces types simples.
A ce propos, que sont les instructions? En fait il s'agit de tout ordre complet, donc presque tout en C. Les instructions sont séparées par un ";" en général
(sauf quelques unes qui ne nécessitent pas de séparateur).
"int a;" est une instruction qui définit une variable de type entier (une variable est une boîte où stocker une valeur)
"a = 4;" est une instruction qui affecte la valeur 4 à la variable a de type entier.
De la même manière l'appel à une fonction est une instruction :
"int c; c = somme(3,5);" en définissant la fonction somme(...) comme expliqué ci-dessus. On peut aussi écrire "c = somme(a,5);" en réutilisant la valeur qui est stockée en a (4) pour produire la somme de 4 et de 5 et la stocker dans la variable c.
On peut séparer ses fichiers sources en plusieurs fichiers ".c", puis ensuite appeler des méthodes d'un autre fichier, une fois qu'on l'a importé (c'est-à-dire qu'on a dit au début du fichier qu'on allait l'utiliser).
Bien sûr on peut donc utiliser des types plus compliqués en c, par exemple on peut définir un type "point" comme étant un float (nombre à virgule) pour l'abscisse et un float pour l'ordonnée. Pour cela on utilise le mot-clef "struct" :
struct point {
float abscisse;
float ordonnee;
}
On peut même aller plus loin en créant un type compliqué qui utilise d'autres types compliqués. Par exemle, un cercle peut être défini comme un point et un float pour le rayon.

Les limites du C
Les problèmes du C sont les suivants :
- très peu de conventions : les conventions ne sont pas des contraintes en programmation, mais des garde-fous qui permettent au développeur d'être plus direct en le guidant plus efficacement. Il est évident qu'il est plus facile d'utiliser le code c d'un autre développeur si son code se rapproche du nôtre
- il n'est pas évident de créer une documentation claire et formattée
- dans le même esprit de collaboration entre développeurs, lorsqu'on veut utiliser un type compliqué C développé par un autre, il faut déjà récupérer la définition du type, puis les fonctions qui les utilisent (souvent dans un autre fichier). Et le pire est que la moindre adaptation est impossible : si un développeur a défini le type "rectangle" et a créé les fonctions de calcul basique associés (périmètre, surface,...), si on créé le type "carré" on aimerait bien pouvoir réutiliser les fonctions de calcul des rectangles mais on ne peut pas : le compilateur C nous dira que le carré n'est pas un rectangle du point de vue des types C
- problème plus technique : la gestion des réservations mémoires (car il faut bien stocker les informations quelque part dans l'ordinateur pendant l'exécution du code) est lourde et contraignante, surtout à une époque où la mémoire coule à flot dans nos ordinateurs. En plus dès qu'on se trompe, ou si on oublie de réserver la place ou assez de place, l'application se plante avec un message d'erreur incompréhensible. En effet le c ne fournit pas de vrai moyen de gérer les erreurs pendant l'exécution du code
Le langage Java est une réponse à ces défauts.

Les caractéristiques de base du Java
Java est un langage objet. Un objet est à comprendre au sens de composant, comme des pièces de Lego : il est facile d'utiliser ensemble les composants, et il est facile de s'approprier un composant défini par quelqu'un d'autre pour le spécialiser. Un exemple près de nous : le composant "champ de texte" Cocoa (écrit en Objective-C, un autre langage objet) est utilisé dans les applications Cocoa. Il suffit à Apple de l'enrichir d'une fonction de vérification de l'orthographe, pour qu'une simple recompilation de notre application hérite de la fonctionnalité.
Le maître mot ici est "hériter". En fait en Java tous les types compliqués seront en relation de filiation avec un autre type compliqué. Ce sont ces types compliqués qu'on appelle des objets (le code définissant ces objets étant une classe, l'équivalent du code source simple de C) (par la suite on ne distinguera plus trop une classe d'un objet, la classe étant plutôt le type, et un objet l'instanciation de la classe, c'est-à-dire une variable de type la classe).
L'ancêtre commun à tous ces objets, puisqu'il en faut bien un est la classe Object. Il n'a pas beaucoup de code associé réutilisable puisqu'il ne fait pas grand chose. Une autre classe intéressante, qui descend directement de Object, est String, qui représente une chaîne de caractères. Par exemple, on va pouvoir en Java définir l'objet MyString, une chaîne de caractère dont la première lettre serait toujours en majuscule. En indiquant que la classe MyString hérite de la classe String, on peut en particulier utiliser la méthode qui calcule la longueur d'une String sur un objet MyString. C'est donc beaucoup plus facile de réutiliser du code existant pour l'enrichir et l'adapter à nos besoins particuliers. Une classe Java, c'est donc un peu à la fois le struct C, plus les fonctions associées directement intégrées dans le même fichier, plus la possibilité de réutiliser les fonctions pour une classe fille. En Java, les fonctions s'appellent plutôt des méthodes (essentiellement par convention).
Les conventions en Java ont été définies depuis le début :
- les noms de classe commencent par une majuscule : Object
- les noms des variables, des méthodes commencent par une minuscule : Object monObjet;
-...
Un outil est directement intégré à Java pour facilement produire une documentation HTML de son code : la Javadoc. Pour moi c'est la clarté et la complétude de la Javadoc produite par Sun (qui a inventé le Java) pour les très très nombreuses classes de base du langage qui a facilité son développement : pour savoir comment marche la méthode substring de la classe String, il suffit de taper "java String substring" dans google pour tomber en une demi-seconde sur la documentation.
Enfin la gestion des erreurs à l'exécution est directement intégrée dans le système. Comment est-ce possible? En fait la compilation Java ne produit pas un code dans un langage compréhensible par l'ordinateur (il produit du byte code et pas du code assembleur), la machine a besoin d'un traducteur intermédiaire qui s'appelle la JVM (Java Virtual Machine). En fait, sous le capot, la JVM n'est qu'un petit programme, qui lit les fichiers classes compilés (les .class) comme s'il s'agissait de fichiers textes comportant des suite d'instructions qu'il a à exécuter. Et ce petit programme n'est pas bête : si les instructions qu'on lui demande d'exécuter plantent, il nous avertit en langage presque humain. Quand on oublie d'initialiser un objet, au lieu d'un "segmentation fault" à la C, il nous dit "NullPointerException" et nous indique dans quel endroit du code le problème est survenu. On dit que Java intègre la gestion des Exceptions.
Concernant la réservation mémoire, Java simplifie à moitié le problème : en C il faut allouer et libérer la mémoire à la main. En Java on a juste à allouer la mémoire (avec une syntaxe simplifiée par rapport au C), la libération de la mémoire se fait automatiquement (en fait un process de la JVM, le garbage collector (ou ramasse-miettes en français), regarde de temps en temps les objets en mémoire : ceux qui ne sont plus utilisables sont détruits). La syntaxe pour allouer de la mémoire est la suivante (par exemple pour un objet Object) : "Object objet = new Object();".
Mais me direz-vous, tout est donc objet en Java? En fait pour des raisons de performances, Sun a laissé dans le système quelques types simples à la C (ils sont appelés types primitifs en Java pour les distinguer des objets, et sont une poignée seulement). Les types primitifs s'appellent en général comme en C : int, float, char,... On les distingue, en tant que type, des objets car ils sont écrits en minuscules (alors que le type d'un objet aura sa première lettre en majuscule). Pour les types simples, comme en C, il n'est pas question de méthodes ou d'allocation mémoire : ils sont identiques en fonctionnalités et en utilisation aux mêmes types simples en C. Il est un peu compliqué quand on commence le Java à comprendre cette bivalence entre types primitifs et objets. Par exemple, on a à la fois un type primitif "int" et un objet "Integer" : le premier est un type primitif, le second un objet à part entière (qui est en fait défini en interne comme un attribut de type int et un ensemble de méthode de travail sur les Integer). Dans la classe Integer, on a des méthodes pour récupérer un int à partir d'un Integer et inversement.


Prochaine leçon : rapide présentation des différentes librairies utiles fournies avec Java et réalisation d'un premier programme Java avec Eclipse.


[edit]J'avais oublié quelques trucs à la fin

Écrit par : Ogur 11 Mar 2008, 14:12

impec, atar!
concernant eclipse, je vais jeter un oeil à mes fiches sitôt rentré. De mémoire elles contiennent quelques info intéressantes quand on débute.

edit : j'en ai déjà retrouvé 2 :
http://blog.colboa.net/Divers/Eclipse%20basics%201.pdf et http://blog.colboa.net/Divers/Eclipse%20basics%202.pdf.

Écrit par : CantKillemAll 11 Mar 2008, 17:20

Bon, je viens d'apprendre quelques trucs, là... Cool

Écrit par : DBSor 11 Mar 2008, 22:51

Très intéressant atarxerxes, je ne connais absolument pas la java.
Je te trouve tout de même u peu dur avec le C, disons que c'est un langage qui force à réfléchir un minimum (contrairement au basic avec lequel j'ai commencé en ... 198x , gestion de la mémoire par exemple). Le C++ est assez sympa comme langage objet mais je trouve l'objective-C vraiment bien fait, quand tes élèves auront bien travailler, ils pourront y passer

Écrit par : atarxerxes 11 Mar 2008, 23:13

Ba l'Objective-C 2.0 c'est encore plus convergent avec le Java non? Y'avait pas des modifications dans ce goût pour la gestion de la mémoire par exemple?

La force du C, c'est que ça t'oblige à comprendre ce qu'est un pointeur, et une fois que tu as pigé ça normalement, quelque soit le langage tu ne te trompes plus pour savoir si tu dois affecter de la mémoire ou pas.

Écrit par : DBSor 11 Mar 2008, 23:36

Je continue à (essayer de) gérer ma mémoire à l'ancienne, je n'utilise pas le garbage collector
Et oui, il faut savoir ce qu'est un pointeur, c'est le pilier sur lequel repose l'ensemble

Écrit par : W@T3RC00L3d 12 Mar 2008, 22:04

Et l'héritage?

Écrit par : Gamoul 12 Mar 2008, 22:26

C'est pas un concept généralisé comme en java.

Écrit par : atarxerxes 13 Mar 2008, 07:17

Ouais, en C on peut toujours ruser mais c'est un peu tordu.

Écrit par : DBSor 13 Mar 2008, 09:12

D'où le C++

Écrit par : Tecka 17 Mar 2008, 16:11

La suite..................

Écrit par : atarxerxes 17 Mar 2008, 17:05

Vu que y'a le printemps du cinéma ce soir et demain soir, je sais pas si la suite n'arrivera pas avant Mercredi soir (mais elle est déjà commencée)

Écrit par : Tecka 17 Mar 2008, 18:30

Pfffffffff si maintenant les profs sèchent les cours

Écrit par : ZenZen 17 Mar 2008, 20:14

Bon alors déjà, bonjour à tous... (je suis de retour normalement )
Je vais mettre mon petit grain...

Voila le java c'est bien...Quoique au bout de 2 ans de java intensif je crois que j'ai le cerveau formatté maintenant

Pour ceux qui veulent un tuto rapide et concis sur Eclipse, j'ai un prof qui en a un pas mauvais...j'avais trouvé à l'époque. Mais je conseille d'apprendre tout d'abord avec un éditeur de texte basique (qui a dit vim ?)...

http://www-igm.univ-mlv.fr/~forax/ens/java-avance/cours/pdf/Eclipse%20pour%20les%20null.pdf

Si y'en a qui ont des questions sur Eclipse je peux aussi y répondre, j'ai tellement galéré avec ce soft...

à plus, je repasserai vite !!!!

Écrit par : Diurn 17 Mar 2008, 20:55

j'aime bien le gros jeu de mot en première page

Écrit par : Ogur 18 Mar 2008, 11:55

en effet

Écrit par : appleseed 19 Mar 2008, 14:37

Bon il suffit que je ne passe plus pendant un moment pour que l'on fasse des choses interessantes....
mais je ne veux pas trop ramener "ma pomme" sur ce sujet car je trouve tres bien l'auto pedagogie... surtout en groupe ....

Une remarque: pour moi, "java pour les nulls" et un bouquin nullissime (comme la serie)... Pour le prix de 28e (prohibitif pour cette (pour moi) daube) il y a bien d'autres bouquins qui permettent d'apprendre et que l'on peut conserver ensuite. Par exemple les livres de http://www.amazon.fr/Programmer-en-Java-Claude-Delannoy/dp/2212119887/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1205933805&sr=8-2. Les http://www.amazon.fr/s/ref=nb_ss_b?__mk_fr_FR=%C5M%C5Z%D5%D1&url=search-alias%3Dstripbooks&field-keywords=java+O%27reilly&Go.x=0&Go.y=0&Go=Go sont (for me) dables mais à utiliser plutot comme bouquins de references voir cependant dans cette collection: http://www.amazon.fr/Introduction-%C3%A0-Java-Patrick-Niemeyer/dp/2841772349/ref=sr_1_4?ie=UTF8&s=books&qid=1205939707&sr=1-4.

Écrit par : atarxerxes 24 Mar 2008, 14:11

Leçon 1 : à la découvert des packages

(pour la partie concernant la création d'un projet Eclipse, se reporter aux documents de Ogur et appeler à l'aide en cas de difficultés).

Petit point de langage :
- j2se désigne le pack de classes destinés à la production d'applications en ligne de commande ou à interface graphique
- j2ee désigne le pack de classes (complémentaires à j2se) destinées plus spécialement au développement d'application Internet/Intranet (des applications qu'on utilise par un navigateur web en gros)
- les numéros de version de Sun sont bizarres, on peut distinguer essentiellement les versions suivantes :
--- 1.3.x : vieille version à qui il manque des classes de base (les expressions régulières faciles à utiliser entre autres), mais encore de temps en temps utilisée dans les applications développées il y a 5 ans ou plus et qui n'ont pas été migrées
--- 1.4.2 : la plus stable des versions, celle qu'on rencontre le plus, pas vraiment de manque au niveau des classes de base
--- 1.5 : commence à supplanter de temps en temps la 1.4.2, n'apporte pas vraiment de classes indispensables en plus mais juste des simplifications du langage (le problème étant, en développement internet que des serveurs d'applications majeurs en version d'il y a 2 ou 3 ans ne comprendront pas des classes développées en 1.5 (par exemple Oracle Application Server 10.1.2))
--- 1.6 : très peu utilisé actuellement, n'apporte pas a priori de classes indispensables mais simplifie encore un peu le langage (les simplifications en 1.5 et 1.6 consistent souvent à demander moins de travail au développeur, et un peu plus au compilateur)

Le langage Java n'est pas fourni nu, il comprend par défaut de nombreuses librairies d'objets déjà tout fait qu'il suffit soit de récupérer et d'utiliser tel quel, soit d'adapter en héritant les objets pour les spécialiser à ses besoins propres.
La page d'accueil de la documentation des classes fournies se trouve ici : http://java.sun.com/j2se/1.4.2/docs/api/overview-summary.html (pour la version j2se 1.4.2).
On remarque déjà la dénomination assez conventionnelles des packages.

La première ligne du fichier d'une classe est la déclaration du package auquel appartient la classe (et qui doit correspondre à l'arborescence des répertoires où se trouve la classe). Exemple : "package fr.iclan;".
Pour utiliser une classe d'un package, on insère ensuite une ligne du type "import java.util.List;" au début du fichier de sa classe, après la déclaration du package (Eclipse peut insérer cette ligne semi-automatiquement lui-même avec l'auto-complétion (CTRL+espace)).
On peut inclure directement toutes les classes qui sont dans un package (mais ça ne prend pas en compte les packages fils) par "import java.util.*;".
On met autant de ligne que de classe qu'on a besoin d'utiliser (avec le cas particulier de l'inclusion d'un package entier, et sachant que les classes du même package que celui de la classe qu'on écrit sont implicitement incluses).
(dans le texte suivant, j'ai dit inclure pour ne pas m'embêter mais c'est un import qui est réalisé. En fait la différence include/import est aussi un avantage du Java par rapport à C/C++ ou un inconvénient suivant l'obédience des analystes. J'ai jamais trop creusé la question moi-même cela dit mais la différence se situe au niveau du travail que doit effectuer le compilateur et l'optimisation possible du code qui en découle).

Les packages qu'on utilise à chaque fois ou presque :
- java.lang : comporte les objets de base du système (en particulier les types : Boolean, Integer,...). Il est importé automatiquement
- java.io : comporte les classes qui servent à lire/écrire un fichier (ou n'importe quel flux de données, avec des flux au sens Unix). On y trouve par exemple les classes File, FileReader, FileWriter
- java.math : comporte juste deux classes : BigDecimal et BigInteger, qui permettent de travailler sur des nombres aussi gros qu'on veut sans perdre en précision (utile pour mapper les colonnes d'identifiants de base de données (c'est à dire faire transiter une information entre un objet Java et un autre type de données))
- java.sql : les classes de base JDBC (le langage universel de communication avec les BDD en Java, quelque soit le type réel de BDD sous-jacent) : les objets connexion, ResultSet, PreparedStatement
- java.util : comporte toutes les structures de données de base (Vector, List, Date, Iterator). Très utile donc.
- javax.swing (et les packages fils) : comporte tous les objets d'affichage SWING (le système d'affichage de Java pour les applications standard (les applications qui fonctionnent de manière indépendante et pas dans un navigateur Web) et pour les Applets (l'équivalent des ActiveX ou du Flash (grosso modo pour le Flash)). On peut y trouver des objets comme les boutons (JButton), les listes de données (JTable), les checkbox (JCheckbox). En général les classes SWING commencent par un "J"
[Le package s'appelle javax, cela signifie "java extension", comme tous les packages additionnels au langage de base, même s'ils font désormais partie à part entière du langage].

Prochaine leçon : la théorie du MVC (en fait plutôt l'http://fr.wikipedia.org/wiki/Architecture_trois_tiers sans doute), avec pour objectif de pouvoir commencer à réfléchir à notre problème de gestion de stocks.

Écrit par : CantKillemAll 24 Mar 2008, 19:46

Merci Maître

Écrit par : Tecka 29 Mar 2008, 22:01

Merde j'ai séché le cours mais c'est bon maintenant j'ai recopié
Comme mon camarade de classe.
Merci maître

Écrit par : atarxerxes 29 Mar 2008, 22:29

Comme l'a indiqué appleseed, les livres de O'Reilly sont vraiment hors-normes. Là je lis "Design Patterns" dans la série "Tête la première", ça se lit comme un roman et c'est plein d'humour à la Monty Python, c'est beaucoup plus rigolo que le spectacle ou le film d'un comique français (bon en même temps, les deux auteurs sont des utilisateurs de Mac, ça aide pour apprendre l'humour rigolo et non vulgaire visiblement).

Écrit par : Darknight670 1 Apr 2008, 16:42

Suppression du message pour non respect de la charte.

Écrit par : atarxerxes 1 Apr 2008, 21:50

Ici on n'aime pas les étrangers pirates, étranger pirate (le photoco-pillage tue le livre)

Écrit par : Darknight670 2 Apr 2008, 17:06

Pas la peine d'être agressif De plus je possède la plupart des livres parce que lire sur un écran de Mac tout un livre c'est vraiment la misère...

Écrit par : Darknight670 2 Apr 2008, 17:11

Sinon pour le Java:
http://java.developpez.com/cours/
http://www.jmdoudoux.fr/accueil_java.htm

Pour le Cocoa la Doc d'Apple est très bien faites je trouve ( je commence a essayer a l'apprendre avec celle ci...) mais considère que vous avez deja les bases minimum en C

Écrit par : atarxerxes 2 Apr 2008, 17:14

Je ne suis pas agressif mais dans la charte du forum il y a or il est illégal de proposer des livres en pdf ou autres gratuitement quand on n'en possède pas les droits ou qu'ils ne sont pas libres

Écrit par : Darknight670 2 Apr 2008, 17:48

C'est vrai j'avais tort et je m'en excuse.

Écrit par : DBSor 2 Apr 2008, 21:07

Ok, tu peux faire un bisou à Atar maintenant (tu vas voir l'effet magique du bisou à moustaches)

Écrit par : Tecka 2 Apr 2008, 21:17

MMMMMMMMMMHHHHHHHHH

Écrit par : appleseed 4 Apr 2008, 14:14

Sinon il y a des livres gratuits sur java

- http://penserenjava.free.fr/ ou en http://www.janiry.com/bruce-eckel/
- ftp://ftp.univ-tours.fr/priv/discala/fichpdf/JavaTout.pdf

@+

[HS] http://www.google.fr/ig?hl=fr c'est vraiment bien [/HS]

Écrit par : atarxerxes 13 Apr 2008, 09:32

Pour la suite des leçons, vous devrez attendre début Mai (j'aurai quelques congés à prendre à cette période). Là entre Mario Kart, le boulot, Mario Kart, les sorties, Mario Kart, le temps de dodo et Mario Kart j'ai pas trop le temps.

Écrit par : Tecka 6 May 2008, 06:52

Écrit par : atarxerxes 17 May 2008, 11:03

Leçon 2 : le MVC/l'architecture N-tiers

Quand on développe un nouveau logiciel, il y a un but et deux logiques s'affrontent pour y parvenir :
- le but est de faire un logiciel qui correspond au cahier des charges initial
- la première logique est de développer le logiciel le plus rapidement possible pour augmenter la rentabilité du produit
- la seconde logique est de penser à la maintenabilité et l'évolutivité du logiciel ("un logiciel qui ne change plus est un logiciel mort", un logiciel dont personne se sert quoi)

Suivant la taille du projet et les circonstances on peut déplacer le curseur entre ces deux logiques à différents endroits.
Pour simplifier pour les petits projets ça sera plus proche de la première logique.
Pour les projets à plusieurs dizaines de jours de développement et dont la durée de vie cible est de 4 ou 5 ans, on favorisera la seconde logique.

Développer en suivant la première logique consiste grosso modo à faire un ou plusieurs gros "scripts" de code (comme du BASIC par exemple). On appelle cela du http://en.wikipedia.org/wiki/Spaghetti_code.

A contrario, la seconde logique impose un développement plus structuré, pas forcément plus lisible de manière globale en première approche mais plus sûrement modifiable au final. Pour se structurer on peut suivre sa propre intuition mais sans garantie de résultat, ou plus simplement suivre les exemples des personnes intelligentes qui se sont réunies pour réfléchir ensemble et en tirer des modèles fiables.

Dans les années 80, avec l'apparition des applications avec interface graphique un tel modèle est apparu : le MVC (Modèle-Vue-Contrôleur). Je ne vais réexpliquer ce qui est dans l'article de wikipédia, mais en gros on distingue donc trois rôles, trois sortes de travail dans une application et on essaie de répartir correctement ces rôles : un bouton sera créé/réglé dans une partie du code consacrée à la Vue, les calculs métier seront dans le Modèle,...
C'est un modèle efficace pour les applications traditionnelles ou client/serveur (iTunes par exemple, le serveur étant l'iTS dans ce cas). Mais il est assez peu efficace pour les applications Internet/Intranet (qui s'exécutent dans un navigateur web en gros) sauf à prendre des modes de travail un peu plus compliqué (comme http://fr.wikipedia.org/wiki/Google_Web_Toolkit).

Vu que ces applications ont quand même plus le vent en poupe que les applications traditionnelles grâce à leurs qualités (déploiement, maintenance,...) et malgré leurs défauts certains (interface limitée par le HTML, plus lent,...), un nouveau modèle s'est dégagé : l'architecture N-tiers (http://fr.wikipedia.org/wiki/Architecture_trois_tiers dans sa forme la plus utilisée).
Tout d'abord, non ! "tiers" ne signifie par "1/3" mais interlocuteur à l'anglaise, il n'y a donc pas forcément 3 tiers .
Pour résumer le modèle, au lieu d'avoir trois interlocuteurs qui dialoguent librement entre eux comme dans le MVC, on a ici une répartition stricte en couches : 3 couches, chacune ne pouvant échanger des informations qu'avec la couche au-dessus ou en dessous d'elle. Le dialogue est unidirectionnel : couche 1 vers couche 2 ou couche 2 vers couche 1 (en pratique ça se traduit dans le code par :
- couche 1 vers couche 2 : la couche 1 appelle une fonction de la couche 2 en lui passant certains paramètres : la méthode choisie et les paramètres constituent les informations apportées par la couche 1 à la couche 2 dans son dialogue
- couche 2 vers couche 1 : la méthode de couche 2 renvoie une valeur qui est l'information qui est amenée par la couche 2 à la couche 1

Les trois couches sont (de la plus proche de l'utilisateur de l'application à la plus lointaine) : présentation, métier, données persistantes.

Les dialogues dans l'application sont :
- présentation <- métier : récupération des données métiers nécessaires à la construction des pages web de l'application
- client <- présentation : génération des pages web
- client -> présentation : clic sur un lien/validation d'un formulaire/ouverture d'une requête Javascript/...
- présentation -> métier : transfert des informations de l'utilisateur après validation et mise en forme de celles-ci
- métier -> données : après transformation/traitement, passage des informations à sauver
- données -> système de persistance (fichiers, base de données,...) : écriture des données
- données <- système de persistance : chargement des données sauvées précédemment
- métier <- données : après transformation des données brutes en objets métier, passage de ceux-ci

Dans une application http://fr.wikipedia.org/wiki/Apache_Struts (sans framework définie de gestion de la persistance), cela se traduit par exemple par :
- des pages JSP, des classes Action, des classes Form : couche présentation
- des classes Manager, des classes d'objets métier (Business Objects) (par exemple un article dans notre application de gestion des stocks) : couche métier
- des classes DAO, des classes DTO/Value Objects : couche données


La prochaine leçon, on commencera par établir le cahier des charges de notre application de gestion de stocks.

Écrit par : Tecka 20 May 2008, 15:25

aaaaaaaah enfin la suite.
Merci mon lapin

Écrit par : DBSor 20 May 2008, 15:59

Intéressant, étrange (pour un pur jus assembleur/pascal/c comme moi) mais intéressant. Merci atarxerxes, vivement la suite.

Écrit par : fre2x3 20 May 2008, 16:27

Ah tient ! ça me rappelle le boulot. Avec l'AS3 kiff kiff.

Écrit par : atarxerxes 10 Jun 2008, 18:36

Leçon 3 : le cahiers des charges

Notre but est de réaliser une petite application de gestion d'un stock d'articles quelconques.
Les actions possibles doivent être :
- listing de l'ensemble des types d'article du stock
- ajout d'un nouveau type d'article
- ajout d'articles pour un type d'article donné
- retrait (pour vente ou autre raison) d'articles pour un type d'article donné
NB : on distingue les types d'articles (par exemple les clous CL-2145 d'un article (un clou CL-2145 donné que l'on peut tenir dans sa main)). Dans notre application on va supposer qu'on s'occupe de petits articles de ce type et on va uniquement s'intéresser à suivre l'évolution du nombre de types d'articles. Pour des types d'articles plus conséquents, on aurait pu avoir à s'intéresser aux articles (par exemple pour des télés assez chères, on aurait sans doute voulu suivre précisément chaque télé du stock, avec un numéro d'inventaire unique pour chacune pour des raisons évidentes (détecter les vols, gérer les garanties,...).
On ne permettra pas de modifier un type d'article, ce sera à l'utilisateur d'en créer un nouveau si le type d'article évolue (en effet c'est logique car les articles de ce type que l'on a déjà en stock ne vont pas évoluer d'un coup de baguette magique car le fournisseur a modifié son mode de travail).
On choisit de ne pas gérer les prix de ventes ou d'achats sachant qu'ils sont évolutifs dans le temps ou peuvent avoir des règles de gestion ponctuelles (remise exceptionnelle,...). Le prix serait sans doute stocké (si on voulait le gérer) dans une table historique des opérations sur les types d'articles (exemple : on garderait la trace de l'ajout de 45 articles au prix unitaire d'achat de 1,25€, on garderait la trace de la vente de 12 articles au PU HT de vente de 7,95€,...). Pour le moment on peut se limiter à la gestion des quantités d'articles uniquement.
On pourrait aussi avoir une gestion plus poussée des fournisseurs (avec leurs propres informations à part) mais on va se contenter de ne juste garder que leurs noms.

Les informations que l'on veut stocker sur le type d'article :
- identifiant unique : long
- code : string
- nom : string
- date d'entrée au catalogue : date
- fournisseur : string
- quantité en stock : long
- date de dernière modification de la quantité : date

A côté de chaque champ, le type de donnée probable que l'on utilisera.
Pourquoi distinguer un identifiant unique et un code? Le code sera utile pour les employés du magasin, il est sans doute aisément mémorisable par les utilisateurs, mais c'est une string. En règle générale c'est plus sûr d'avoir pour identifiant interne unique un nombre (affecté par le système). Cela dit on aurait pu effectivement utiliser ce code comme identifiant unique.

Pour modéliser notre type d'article, on va créer une classe TypeArticleBean (on rajoute le terme Bean à la fin du nom car on va respecter les conventions des http://fr.wikipedia.org/wiki/JavaBeans).
Notre application va donc se contenter de jongler avec des TypeArticleBean lorsqu'on lui demandera d'effectuer une opération (listing, ajout,...).

Prochaine leçon :
- on commencera par installer http://www.eclipse.org/downloads/moreinfo/jee.php
- on créera notre projet dans Eclipse
- on créera notre classe TypeArticleBean
- on créera une application de test de cette classe

Écrit par : Tecka 12 Jun 2008, 05:26

oups j'ai séché le cours .........
Il faut se remettre au boulot j'ai rien fait depuis 1 mois presque

Écrit par : Ogur 16 Jun 2008, 23:28

Atar, petite question à la sauvette car je n'ai pas encore pris le temps de m'intéresser à la question :

Y a t'il moyen, en java, d'assembler des images (de très grande résolution) sans bouffer trop de RAM ? Par exemple, 4 images à assembler en une seule en carré.

Je bricole actuellement sur des fractales avec deux potes et on se posait la question (parce qu'il s'agit vraiment de très grandes images).

Je donnerai plus de détails quand mon petit projet avancera, mais pour le moment les 2 Go de RAM de mon MBP ont de la peine à suivre

Écrit par : atarxerxes 17 Jun 2008, 06:17

Il faudrait voir le code exact.
"Assembler" ça veut dire quoi en Java? Créer une Image à partir des quatres autres?
Tu utilises des Image, BufferedImage, ou autres?

Il faudrait voir peut-être dans la doc de Java2D s'il n'y pas un truc là-dessus : http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec.html / http://java.sun.com/docs/books/tutorial/2d/index.html.

J'ai jamais eu à réfléchir à ces problématiques mais on doit sans doute trouver sur Internet soit dans les stratégies de programmation des jeux, soit des logiciels de traitement d'images (satellite par exemple) des exemples de stratégies.
Enfin ça dépend de ce que tu veux faire exactement : si c'est ouvrir 4 grosses images pour les assembler en 1 seule pour créer le fichier d'une très grosse image, il faut peut-être passer par une autre stratégie (par exemple créer le fichier de la grosse image à la bonne taille mais vide, puis ouvrir chaque image l'une après l'autre pour l'écrire dans le fichier de la grosse image).

D'un point de vue plus pratique, j'imagine que tu as déjà augmenté les paramètres de mémoire de ta JVM.

Écrit par : Ogur 17 Jun 2008, 13:31

En effet en ce qui concerne la mémoire (avec les 64 mo alloués par défaut je suis limité à des "BufferedImages" d'une taille d'environ 6000 pixels par 6000.).

Je vais regarder si c'est faisable en se servant des flux, mais pour le moment je bricole encore une autre partie du programme.

Pour les curieux, il s'agit de repartir le calcul d'une fractale (de Mandelbrot) sur plusieurs postes en découpant l'image a calculer en sous-parties. Le but étant d'obtenir la résolution la plus haute possible afin de pouvoir s'amuser (oui oui, s'amuser) à zoomer très loin dans l'image.

Actuellement, sur mon MacBook pro, je suis limité à une image carrée d'environ 24000 pixels de largeur.

Je me suis fait ce petit "exercice" parce que j'adore les fractales et que je m'intéresse également au calcul distribué (je gère toute la répartition des tâches, mais je serais également curieux de savoir comment faire via xGrid). Je précise car on m'a déjà conseillé plusieurs fois de faire une application qui recalcule uniquement la zone que l'on souhaite afficher ; perso je préfère plutôt faire mouliner les ordis de ma coloc le plus longtemps possible, c'est plus rigolo

Quand on aura de belles images j'en montrerai quelques unes ici, et si jamais, la Fractale en elle-même n'est vraiment pas difficile à calculer !

Écrit par : atarxerxes 25 Sep 2008, 11:56

Peut-être du nouveau bientôt !

Écrit par : Tecka 25 Sep 2008, 13:02

aaaaaaaaah la reprise des cours après les vacances

Écrit par : atarxerxes 29 Sep 2008, 16:11

Pour cette rentrée, on va s'éloigner un peu de l'exemple (légèrement) entamé pour réaliser une petite application qui brasse pas mal de technologies différentes.
En plus cette application sera utile (enfin j'espère au moins pour Heimdal !).

Le but sera de mettre en place une application qui produit un flux RSS (ou Atom, on verra par la suite, en tout cas un flux de syndication). Ce flux permettra de suivre l'actualité des jeux vidéos (sorties,...) (ça permettra de remplacer le calendrier que j'avais commencé et que j'ai la flemme de continuer ).

L'application sera assez simple :
- une partie administrative pour faire du http://fr.wikipedia.org/wiki/CRUD sur nos actualités
- une partie publique qui fournira le flux de syndication


D'un point de vue technologie, on aura a priori :
- une base MySQL pour stocker nos données
- notre application J2EE (partie publique offerte par une servlet, partie administrative par des pages JSP)
- un serveur Tomcat pour faire tourner notre application
- la génération et la manipulation d'un fichier XML (avec XSLT)
- une page html de test d'affichage du flux par Ajax (pour ceux qui ne veulent pas passer par un logiciel dédié)

Écrit par : Gamoul 29 Sep 2008, 16:22

Cool

Écrit par : Heimdal50 29 Sep 2008, 16:50

Ça c´est une bonne nouvelle J´ai tendance à tout mélanger avec les css, les php, les javascripts...

Écrit par : atarxerxes 29 Sep 2008, 17:18

Enfin, là je disais que l'application te serait utile surtout parce que tu étais le seul à consulter mon calendrier

Écrit par : W@T3RC00L3d 29 Sep 2008, 17:47

Bonne idée, je vais suivre ça, je connais encore mal XML/XSLT!

Écrit par : atarxerxes 30 Sep 2008, 08:06

Cette fois je vais essayer de finir l'application exemple AVANT de faire les "cours" pour arriver à finaliser quelque chose (elle est à 25%-30% actuellement, j'espère la finir ce week end)

Écrit par : atarxerxes 5 Oct 2008, 12:23

L'application qu'on va réaliser en pas à pas est grosso modo fonctionnelle (même s'il y a encore des trucs à améliorer, surtout niveau présentation).
Elle peut être visualisée ici : http://atarxerxes3.hd.free.fr:8080/vg_actus/ (présentation testée uniquement sous Safari, il peut rester des trucs louches sous Firefox, et IE j'en parle même pas).

Premier article en guise de pré-requis prévu dans la journée (si j'arrive à ne pas lancer FIFA aujourd'hui, sinon dans la semaine) : installation et configuration de mysql/tomcat/eclipse.

Écrit par : Ogur 5 Oct 2008, 14:32

Tiens, ça m'intéresse de savoir comment coder un servlet, c'est différent en quoi d'un(e) applet ? (Dans le code en fait, dans la pratique je vois très bien).

Écrit par : Sire Diablo 5 Oct 2008, 14:44

Pourquoi tu veux coder un cervelet ? Ok vous savez où me trouver.

Vive le C (ce que je fais en cours).

Écrit par : atarxerxes 5 Oct 2008, 15:10

- applet = application à part entière (c'est une application Java standard avec quelques conventions et limitations à observer)
- servlet = juste une classe qui sert à écrire une réponse HTTP à une requête HTTP (post, get,...). C'est juste une classe tout bête avec certaines fonctions bien définies à implémenter

Écrit par : atarxerxes 5 Oct 2008, 15:56

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse, mise en place du log
5. mise en place de l'authentification Tomcat
6. connexion Java-MySQL
7. récupérations d'informations dans la base
8. génération du flux XML des actualités
9. transformation et affichage du flux XML
10. construction du modèle des pages HTML
11. écriture des requêtes de modification/ajout/suppression
12. écriture des pages de modification/ajout/suppression
13. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
14. saisie facile des dates
15. validation des données saisies
16. écriture de la servlet publique
17. génération du flux Atom

Première étape : les installations (explications minimales, ne pas hésiter à se manifester si quelque chose bloque !)

- Installation de MySQL : http://www.mac4ever.com/articles/macos/935/activer_php_et_mysql_sous_leopard_mac_os_x_10_5/ sous Léopard (on peut aussi en profiter pour activer php sous Apache2, ça mange pas de pain).
Les réglages par défaut sont :
- utilisateur root (pas de mot de passe) sur la machine localhost en tant qu'administrateur

- Installation de MySQL Tools : http://dev.mysql.com/downloads/gui-tools/5.0.html. Cela installe deux applications :
- MySQL Administrator (sert à créer les utilisateurs, les tables,... de manière graphique)
- MySQL Query Browser (sert à créer les utilisateurs, les tables,... et les données par requête SQL)

- Tomcat : http://tomcat.apache.org/download-55.cgi (le package Core en 5.5.27 suffira).
Il suffit de le dézipper dans un répertoire (par exemple dans /Applications).
A priori les scripts sh ne sont pas exécutables par défaut après dézippage : un petit coup de "chmod +x *.sh" dans le répertoire bin de tomcat répare cela.
Si on veut lancer tomcat à la main, cela se fait par un "./startup.sh" (respectivement "shutdown.sh" pour l'éteindre) après s'être déplacé dans le répertoire bin de tomcat (si des permissions denied apparaissent, un petit coup de sudo chown sur le répertoire (et en particulier sur le contenu du répertoire de logs) devrait remettre les choses d'aplomb) .
Pour vérifier que le serveur se lance correctement, il suffit de lancer un navigateur à l'adresse "http://localhost:8080/" (normalement c'est le port par défaut, sinon il suffit d'aller dans le fichier conf/server.xml à la ligne 77 environ voir le port utilisé).
On va aussi en profiter pour ouvrir le fichier conf/tomcat-users.xml et pour supprimer les rôles différents de tomcat, ainsi que les utilisateurs qu'on remplace par notre propre utilisateur (à vous de définir son nom et son mot de passe).
Par exemple :


- Eclipse Ganymede : http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/ganymede/SR1/eclipse-jee-ganymede-SR1-macosx-carbon.tar.gz, à dézipper et placer dans /Applications par exemple.
On peut vérifier en double-cliquant sur l'application qu'elle se lance correctement.
On peut ne profiter pour rajouter notre serveur Tomcat dans l'onglet Serveur (clic-droit dans l'onglet -> New -> Server -> Tomcat 5.5, indiquer le répertoire).

Du coup (en s'assurant qu'il est éteint) on peut lancer et éteindre notre serveur tomcat depuis Eclipse (clic-droit Start, respectivement Stop).

Dans l'onglet Console, on récupère même les messages qui s'affichent dans le fichier de log Catalina.out.

Écrit par : Acid 5 Oct 2008, 19:09

Applet: application chez le client en general avec interface graphique. Indication via un tag dans la page HTML


Exemple d'applet




Servlet: application chez le serveur, sortie page HTML ou XML ... lancement par le serveur.

Exemple de servlet

Écrit par : atarxerxes 5 Oct 2008, 21:54

A noter qu'une servlet peut produire vraiment n'importe quoi, et pas seulement du contenu "textuel".
Exemples courants d'utilisation obligée d'une servlet où le contenu est du binaire :
- une servlet d'affichage : on lui passe un nom d'image par exemple, et on reçoit le flux de l'image en réponse (exemple : <img src="http://monsite.com/maSuperServlet?img=toto.jpg"/>)
- un échange d'objets Java sérialisés (par exemple un client qui reçoit des objets Java métier d'un serveur)

Écrit par : Ogur 5 Oct 2008, 23:14

Okay ! Donc c'est bien le serveur qui exécute des "scripts" java qu'on a placé puis appelé sur celui-ci ? Je vais ressortir mon livre sur Java, ces implémentations côté serveur m'intéressent bigrement...

Écrit par : atarxerxes 6 Oct 2008, 06:02

En fait Java sur un serveur tomcat c'est un peu comme php sur un Apache sur lequel php est activé.
Une différence technique : Apache détecte qu'il doit lancer php.exe d'après l'extension des url en général, alors que les serveurs J2EE sont eux-mêmes des applications Java (en fait on n'a qu'une seule grosse application Java qui est le serveur et suivant les URLs demandées cet application appelle certaines de nos classes (essentiellement des servlets ou des pages JSP)).

Écrit par : atarxerxes 6 Oct 2008, 07:13

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse, mise en place du log
5. mise en place de l'authentification Tomcat
6. connexion Java-MySQL
7. récupérations d'informations dans la base
8. génération du flux XML des actualités
9. transformation et affichage du flux XML
10. construction du modèle des pages HTML
11. écriture des requêtes de modification/ajout/suppression
12. écriture des pages de modification/ajout/suppression
13. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
14. saisie facile des dates
15. validation des données saisies
16. écriture de la servlet publique
17. génération du flux Atom

Seconde étape : les spécifications

Il faut savoir ce qu'on veut que notre application puisse faire.
On va partir sur :
- un jeu vidéo a un titre unique, un éditeur, une description, une liste de liens de previews, une liste de liens de tests
- il peut sortir sur un seul support (Wii par exemple) ou sur plusieurs (X360, PS3,...). Chaque version peut avoir quelques spécificités (par exemple utilisation de la Wii Balance Board sur Wii, inferior version sur PS3,... )
- il peut sortir dans un seul territoire (les territoires sont : Japon, USA, Europe). La sortie sur un territoire est datée. Elle peut avoir quelques spécificités (par exemple le sang enlevé sur No More Heroes en Europe mais pas aux USA).

Au niveau fonctionnalités de l'application on voudra (au moins dans un premier temps) :
- partie administration : liste des jeux, création/modification d'un jeu, suppression d'un jeu. La modification/création d'un jeu permet la planification de la sortie (en plus bien sûr de la modification des caractéristiques du jeu et de la spécification de ses supports)
- partie publique : juste un flux Atom regroupant les différents jeux récemment modifiés (on pourra limiter le nombre de jours à récupérer afin de ne pas faire sauter le serveur quand il sera bien plein dans quelques années)

Au niveau technique :
- base MySQL pour stocker les données
- serveur tomcat
- application J2EE standard
- partie administration : pilotage par pages JSP, protection light en utilisant les mécanismes incorporés à tomcat
- partie publique : servlet qui produit le flux XML

Écrit par : Heimdal50 6 Oct 2008, 15:27

[moitié HS]C´est nickel, ton flux rss d´actualité des jeux [/moitié HS]

Écrit par : atarxerxes 6 Oct 2008, 15:45

En fait c'est pas si HS que ça, je vais utiliser ce flux pour indiquer les jeux qui ont l'air intéressants, ça ira plus vite que de passer par un calendrier iCal (par contre il faut que je vois si je peux améliorer l'organisation des infos dans le flux, un tri par date de sortie européenne serait pas mal quand même)

Parmi les améliorations dans les tuyaux :
- le support indiqué en plus dans le titre (déjà fait, juste à redéployer l'application)
- insertion des liens vers les focus et les tests Gamekult (ou autre) (bientôt dispo)
- des images pour les supports (petits gifs des consoles) et les formats (petits gifs des drapeaux) (d'ici 10 jours)
- éventuellement, insertion de liens vers les screenshots Gamekult (ou autre) (ou alors présentation de ceux-ci en utilisant une adaptation de ce code PHP/JS : http://194.95.111.244/~countzero/myCMS/index.php?c_id=5&s_id=21) (à plus longue échéance)
-...

Écrit par : Heimdal50 6 Oct 2008, 19:13

Pour Tomcat et Eclipse, pas de problèmes; par contre MySQL Manager n´arrive pas à établir de connexion (il trouve le serveur localhost quand je le ping) En laissant la touche command appuyée il m´affiche skip et je vois d´autres options mais je n´arrive pas à lancer le serveur (tomcat fonctionne avec http://localhost:8080/). C´est bon j´ai trouvé (oublié de télécharger MySQL, quel noob cet Heimdal )

Écrit par : atarxerxes 6 Oct 2008, 19:41

Effectivement j'ai peut-être oublié de dire qu'il faut démarrer le serveur mysql par la commande :

dans le répertoire /usr/local/mysql/bin Ca marche mieux?

Sinon :
Fonctionnalités disponibles !

Écrit par : Heimdal50 6 Oct 2008, 19:43

Non quand tu installes MySQL (du site Mac4ever), tu as un paquet MySQLStartupitem qui te démarre MySQL automatiquement Tout fonctionne maintenant

Écrit par : atarxerxes 6 Oct 2008, 19:46

En tout cas sur mon mini, c'était déjà tellement le merdier au niveau des installs que j'ai du le démarrer à la main, MyStartupitem n'y arrivait pas.

Ca te dit quoi quand tu le démarres à la main?

Écrit par : Heimdal50 6 Oct 2008, 19:52

J´ai configuré MySQL Administrator comme suit: Préférences, dans le dossier connexions appuyé sur le +, connexion name: localhost, user: root, password: laisser vide, hostname: localhost, port:8080. Eclipse trouve Tomcat et je peux lancer le serveur à partir de là (menu contextuel, start).

Écrit par : atarxerxes 6 Oct 2008, 20:23

Alors attention :
- une seule application/processus peut écouter sur un port donné (sinon c'est comme deux personnes qui liraient le même courrier : seul le premier arrivé lit la lettre)
- 8080 est le port de Tomcat
- le port par défaut de MySQL est le 3306

Essaie avec ce port plutôt : 3306 sur localhost

Écrit par : Heimdal50 6 Oct 2008, 20:37

C´est corrigé

Écrit par : atarxerxes 6 Oct 2008, 22:35

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse, mise en place du log
5. mise en place de l'authentification Tomcat
6. connexion Java-MySQL
7. récupérations d'informations dans la base
8. génération du flux XML des actualités
9. transformation et affichage du flux XML
10. construction du modèle des pages HTML
11. écriture des requêtes de modification/ajout/suppression
12. écriture des pages de modification/ajout/suppression
13. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
14. saisie facile des dates
15. validation des données saisies
16. écriture de la servlet publique
17. génération du flux Atom

Troisième étape : création de la base et des tables

(en passant, les étapes correspondent grosso modo aux étapes que je suis quand je développe une application. Une application même modeste c'est un gros truc (une vingtaine d'heures pour celle là en comptant les recherches sur google et les essais). C'est pour ça qu'il est important de se fixer des petits pas, toujours plus ou moins les mêmes, à réaliser les uns après les autres pour avancer, sinon on a vite fait de partir dans tous les sens sans avancer réellement).


En analysant les spécifications, on peut distinguer plusieurs entités de différentes natures :
- un jeu bien sûr
- un éditeur (Sony, Activision,...)
- un support (Wii, PSP, PS3,...)
- un format (ou territoire) (EU, US, Jap)
- une sortie

Si on s'intéresse aux relations entre ces objets on a d'après les spécifications :
- un jeu a un éditeur unique, mais un éditeur peut produire plusieurs jeux
- un jeu peut sortir sur plusieurs supports, et un support peut accueillir plusieurs jeux
- un jeu, sur un support donné, peut sortir sur plusieurs territoires (une seule fois pour chaque au maximum) et un territoire peut avoir plusieurs jeux différents qui sortent dessus
- une sortie se caractérise donc par un jeu sur un support dans un territoire

En terme relationnels on a donc (par convention N signifie ici "nombre quelconque") :
- jeu-éditeur : relation 1-N (un seul éditeur par jeu, N jeux par éditeur)
- jeu-support : relation N-N (N supports par jeu, N jeux par support)
- jeu-format : relation N-N? En fait le format d'un jeu n'est intéressant pour nous que si le jeu est associé à un support (exemple : sur XBox360 Final Fantasy XIII ne sortira pas au Japon, contrairement à la PS3). Donc :
- jeu-format-support : triplet définissant de manière unique une sortie
(il n'y a pas de solution unique, certaines interprétations des spécifications peuvent être fausses, c'est pour ça qu'il est utile de s'assurer auprès du client à chaque étape qu'on comprend bien son besoin. Ici vu que c'est moi le client je suis d'accord avec moi-même )

Une fois qu'on a dégagé ces relations, le plus dur est fait au niveau du design de la base de données.
En effet :
- relation 1-N => l'identifiant de la table unique va se retrouver dans la table N
- relation N-N => une table de liaison intermédiaire entre nos deux tables est nécessaire pour obtenir cette articulation

Ce qui donne :
- une table éditeur toute simple
- une table support toute simple
- une table format toute simple
- une table jeu, comportant l'identifiant de son éditeur
- une table de liaison entre un jeu et un support
- une table de liaison entre un jeu, un support et un format (ce sera notre table "sortie")


Avant d'attaquer nos tables, créons notre base (explications minimales, ne pas hésiter à se manifester si quelque chose bloque !) :
- Vérifier que le démon mysqld est lancé par le prefpane MySQL
- Avec l'application MySQL Administrator, se connecter (root sans mot de passe sur localhost:3306 par défaut)
- Créer un utilisateur (Accounts) videogames (mot de passe videogames)
- Choisir cet utilisateur dans la liste et configurer les hosts (enlever % et ajouter localhost, 127.0.0.1 et le nom de l'ordinateur (mini.local pour moi par exemple) (sur mon image j'ai aussi configuré une plage d'IP (192.168.0.%) pour me connecter à la base depuis mon MacPro pour développer car Eclipse ramait trop sur le mini...)


- Sur l'onglet Catalogs, créer le schéma videogames_db (ne pas tenir compte des tables qu'on voit dans cette image, on va les créer juste après)


- Sur l'ongle users, pour chaque host de l'utilisateur videogames, choisir tous les droits et les ajouter pour le schéma videogames_db


On va ensuite créer les tables par script (en effet graphiquement, par l'application d'administration il y a quelques limitations, en particulier pour la création des dates).
On lance donc l'application MySQL Query Browser et on se connecte comme ceci :


On tape les scripts directement dans un onglet "Query", puis "Execute" pour les exécuter :


En script (My)SQL cela donne :
- table format :

Explications :
- form_id est l'identifiant de la table, c'est un nombre qui peut être grand (BIGINT), non nul (NOT NULL), qui s'incrémente seul si non spécifié lors d'une insertion de données (AUTO_INCREMENT) et qui sera l'accès privilégié à la table comme moyen de récupération d'une information en particulier (PRIMARY KEY)
- form_label est le nom du format, c'est une chaîne de caractères (64 maximum) qui ne peut être nulle

- table éditeur :

Idem format

- jeu :

Explications :
- jeu_id idem
- jeu_titre : le titre du jeu, ne peut être nul
- jeu_editeur_id : notre identifiant caractérisant l'éditeur unique d'un jeu. Ne peut être nul
- jeu_description : texte long (idem pour jeu_previews et jeu_tests qui recevront des liens vers previews et tests)
- jeu_date_creation : date-heure non nulle
- jeu_date_modification : idem jeu_date_creation

- table support :

Explications : idem tables éditeur et format

- liaison jeu-support :

Explications :
- jesu_jeu_id : l'identifiant du jeu concerné
- jesu_supp_id : l'identifiant du support concerné
- jesu_description : un petit texte précisant les spécificités du jeu sur le support (ex: compatible Balance Board)

- liaison jeu-support-format :

Explications : notre table des sorties
- jesf_jeu_id / jesf_supp_id / jesf_form_id : les identifiants standard
- jesf_date : la date de la sortie, peut-être nulle si la date est encore inconnue
- jesf_description : un petit texte décrivant les spécificités éventuelles de la sortie du jeu sur ce support (ex: pas de sang sur No More Heroes européen)



On va ensuite insérer quelques données pour pouvoir commencer à travailler (commit permet de valider l'insertion de données, rollback permet de les annuler) :
- les formats :


- les supports :


- les éditeurs (on ajoutera ultérieurement une page pour administrer cela, pour le moment on se contente d'en mettre quelques uns pour tester tout ça) :



[Edit]Un petit mot sur les règles de nommage des tables et colonnes : ça peut sembler chiant ou illisible mais ça fait en fait gagner énormément de temps d'avoir une règle immuable appliquée bêtement. En l'occurrence :
- les tables sont préfixées par un surnom unique pour la base ("vg_")
- les tables d'entités ont un nom lisible, les tables de liaison ont le nom accolé des tables qu'elles lient
- une colonne hérite du nom de la colonne qui la contraint au préfixe de table près (ex : "jesf_jeu_id" pour "jeu_id") (seul contre-exemple : j'aurai du appeler la colonne jeu_editeur_id "jeu_edit_id" pour être cohérent mais ça m'a échappé, tant pis )
- les noms de colonnes sont préfixés par quatre lettres (ou moins, cf "jeu") représentatives du nom de la table. De fait tout nom de colonne est unique dans la base, ça évite de devoir lever soi-même les ambiguïtés dans les requêtes SQL.

Écrit par : atarxerxes 12 Oct 2008, 13:25

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse
5. mise en place du log
6. mise en place de l'authentification Tomcat
7. connexion Java-MySQL
8. récupérations d'informations dans la base
9. génération du flux XML des actualités
10. transformation et affichage du flux XML
11. construction du modèle des pages HTML
12. écriture des requêtes de modification/ajout/suppression
13. écriture des pages de modification/ajout/suppression
14. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
15. saisie facile des dates
16. validation des données saisies
17. écriture de la servlet publique
18. génération du flux Atom

Création du projet Eclipse

Dans Eclipse, on va créer notre projet (New -> Dynamic Web Project), on lui choisit un nom intéressant ("vg_actus" par exemple).
Le reste des réglages devraient être corrects (normalement Eclipse choisit comme cible de développement notre serveur Tomcat déjà configuré (Target Runtime)).

On va passer le format du projet en UTF-8 : clic-droit sur le répertoire du projet -> Propriétés -> Resource -> Text file encoding : Other : UTF-8 -> Ok (pour ne pas être embêté ultérieurement par le format Mac (qui est un Unicode trafiqué (= qui ne respecte pas le standard) si je ne me trompe pas) lorsqu'on écrira des messages à afficher dans les classes Java.

Eclipse crée l'arborescence de notre projet :
- les pages à afficher dans un navigateur (et tout ce qui va avec : images, css, scripts,...) iront dans le répertoire WebContent
- les classes Java iront dans le répertoire src (Java Resources: src)
- le répertoire des fichiers de configuration de l'application (WEB-INF) ira ans WebContent

Un fichier important : web.xml dans WebContent/WEB-INF est le fichier principal de configuration de notre application.

----------------------------
Petit point important : qu'est-ce qu'une application J2EE?
En résumé c'est surtout un fichier web.xml. Les autres composants de l'application (scripts, pages html,...) sont communs aux autres applications web, mais c'est vraiment le fichier web.xml qui fait sa spécificité. C'est le document qui décrit le déploiement de l'application.
Plus d'informations sur ce qu'est une application web Java : http://java.sun.com/j2ee/1.4/docs/tutorial/doc/WebApp3.html
----------------------------

----------------------------
Deuxième point important : servlet? JSP?
Historiquement les servlets sont arrivées avant les JSPs. Une servlet est une classe Java, héritant de la classe HttpServlet. Cette classe servlet sera utilisée par le serveur chaque fois que certaines URLs seront demandées sur le serveur.
Quelles URLs? C'est en fait le développeur qui dira lesquelles prendre en compte (on verra ça dans une leçon ultérieure). A ce propos, une chose importante à comprendre : une URL ne représente rien (mais vraiment rien) à partir de la partie à droite du nom de l'application :
- cela ne dit rien sur l'organisation réelle des pages sur le serveur, ni même sur leur existence
- le serveur Java va analyser la partie droite de l'URL et chercher dans une grande table des matières s'il peut appeler une servlet correspondante. Sinon il essaiera de trouver un fichier à l'endroit indiqué à l'intérieur de l'application (par exemple une page HTML)
- par exemple on peut dire au serveur d'utiliser une servlet dès que l'URL se termine par *.html, cette servlet pouvant par exemple se charger de trouver un fichier XML de même nom que la page HTML demandée, pour le transformer en HTML et le renvoyer au client. Le client croit qu'une page HTML statique existe sur le serveur mais en fait la mise en page est générée dynamiquement à partir des fichiers XML de données brutes (c'est ce que fait en autres http://fr.wikipedia.org/wiki/Apache_Cocoon).
Une servlet va écrire le contenu de la réponse à envoyer au client. Cela se fait de manière assez lourde (avec par exemple un println() pour chaque ligne de la réponse). Au début il n'existait que ce moyen pour écrire une réponse HTTP en Java mais rapidement on a trouvé que c'était un peu lourdingue inutilement sauf cas particuliers (en résumé : pour écrire du HTML c'est lourdingue, pour écrire autre chose c'est nickel).

Ensuite sont apparues les JSPs : il s'agit de pages HTML comportant du code Java (exactement le même principe que les pages php). La différence est ici que le code Java de la page JSP peut utiliser d'autres classes Java (qui sont des classes à part entière).
L'écriture de la page réponse consiste juste à renvoyer le code HTML de la page JSP avec le code Java exécuté produisant si besoin des blocs de code HTML supplémentaires. C'est strictement le même principe que les pages php (seule la syntaxe est un peu différente : <%... code Java...%> et <%=String Java%>).
L'écriture de page HTML de réponse est donc bien plus facile et naturelle.
En fait en interne, on a quand même affaire de manière cachée à une servlet qui est installée dans le serveur : si une URL qui finit par JSP/jsp est demandée, et qu'aucune servlet de l'application ne la prend en charge, cette servlet cherche une page JSP à l'endroit indiqué par l'URL, exécute le code Java contenu dedans, récupère le code HTML produit et le renvoie comme réponse.[edit]Ce que je dis n'est pas très clair : il y a un processus côté serveur qui transforme la page JSP utomatiquement en servlet la première fois où elle est appelée et c'est cette servlet qui est exécutée.[/edit]
En passant une notion difficile à comprendre au début :
- le code Java est exécuté côté serveur avant la réponse de celui-ci
- le code Javascript est exécuté au plus tôt lorsque la page HTML réponse a été entièrement chargée côté client
Il y a donc dans la majorité des cas impossibilité de piloter efficacement le Javascript par du Java sans réfléchir un peu à cet ordre de construction de la page (exemple : affichage d'un alert() en cas d'erreur Java).

Aujourd'hui les servlets sont encore utilisées principalement pour toute production de réponse autre que HTML (flux XML, récupération d'images,...), les pages JSP pour produire celles-ci.
----------------------------


On va commencer par créer une page jsp simple dans WebContent, par exemple une page qui n'affiche que "Page d'accueil" : sur le répertoire WebContent, clic-droit -> New -> HTML, on l'appelle index.jsp.

On ajoute ensuite juste le texte "Page d'accueil" entre les balises "body".


Pour tester notre application sur notre serveur, on fait un clic-droit sur le serveur dans l'onglet du même nom, on choisit "Add and Remove projects...", on choisit notre projet.

Notre projet est maintenant automatiquement mis-à-jour sur le serveur par Eclipse (en pratique il peut échouer à remplacer les classes Java déjà utilisées (donc chargées) sur le serveur quand il doit les recompiler, c'est pour cela qu'il est plus sûr de relancer le serveur quand on modifie du code Java).

On lance notre serveur si besoin (clic-droit -> "start" dessus).

On peut vérifier que notre page est désormais accessible en allant à "http://localhost:8080/vg_actus/index.jsp".

Écrit par : atarxerxes 14 Oct 2008, 11:49

Bon, à partir de la prochaine séance on attaque le développement proprement dit. Il ne reste déjà plus personne ou alors aucun des intéressés n'a eu de problème (ou alors vous attendez que ça commence réellement)?

Pour la suite, je mettrai tout le projet en l'état de la fin de la séance correspondante à chaque séance (en plus des indications dans le corps du message).

Écrit par : Heimdal50 14 Oct 2008, 11:54

Je n´ai pas réussi la création de la base et des tables. Je te mettrais les erreurs ce soir car j´ai un RDV maintenant

Écrit par : atarxerxes 15 Oct 2008, 09:15

Alors?

Écrit par : Heimdal50 15 Oct 2008, 10:08

My SQL Query Browser a des problèmes avec la commande commit:
insert into vg_editeur(edit_name) values('Blizzard');
commit;
Il m´indique un erreur code 106, en rentrant les éditeurs de jeu un par un, cela fonctionne

Écrit par : atarxerxes 15 Oct 2008, 10:34

Bizarre, peut-être qu'il est en auto-commit et qu'il accepte pas qu'on le commite à la main

Cela dit erreur 106 c'est une erreur de syntaxe normalement.

Écrit par : CantKillemAll 15 Oct 2008, 12:31

Pas le temps en ce moment, mais toujours intéressé. Je rattraperai plus tard, continuez sans moi, je prendrai le train en marche

Écrit par : Gamoul 15 Oct 2008, 14:46

pareil pour moi

Écrit par : Tecka 16 Oct 2008, 09:20

Merde j'ai loupé un cours je fais ça ce week-end

Écrit par : atarxerxes 19 Oct 2008, 11:28

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse
5. mise en place du log
6. mise en place de l'authentification Tomcat
7. connexion Java-MySQL
8. récupérations d'informations dans la base
9. génération du flux XML des actualités
10. transformation et affichage du flux XML
11. construction du modèle des pages HTML
12. écriture des requêtes de modification/ajout/suppression
13. écriture des pages de modification/ajout/suppression
14. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
15. saisie facile des dates
16. validation des données saisies
17. écriture de la servlet publique
18. génération du flux Atom

Mise en place du log

Le développement n'est pas un travail linéaire, partant d'un point A vers un point B sans problème. Le mode de travail est plutôt :
- je rajoute ça
- ça marche à peu près
- j'analyse les cas qui ne marchent pas
- je modifie mon code
Et cela boucle jusqu'à obtenir un résultat satisfaisant (marchant parfaitement ou le plus souvent, suffisamment correct c'est-à-dire correct dans suffisamment de cas concrets).
Cela décrit le processus de développement, mais on peut aussi découvrir à l'usage qu'on a oublié un cas qui ne marche pas lorsque l'application est réellement utilisée par les clients.

Il faut donc être capable d'analyser les cas qui ne marchent pas, et cela ne peut-être fait sans avoir des informations précises sur ce que l'application faisait au moment du problème.
C'est pour cela qui faut être capable de mettre en place une stratégie efficace de logging dans une application.
Les contraintes sont :
- traces en développement
- possibilité d'avoir aussi des traces en production
- accessibilité facile aux traces
- les traces doivent contenir des informations pertinentes (localisation, importance de l'anomalie, date)

Ce qui vient à l'esprit des développeurs débutants, de par sa grande facilité de mise en place est l'utilisation de l'écriture directe dans la console Java où s'exécute le programme. Cela se fait par l'utilisation de http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#out("Mon super message");
Pourquoi c'est nul à l'usage d'utiliser ça?
- les traces sont affichées "à vie", il faut enlever l'appel à la méthode pour les supprimer, ça serait mieux si on pouvait les afficher que quand on cherche à localiser un problème
- on doit insérer nous-mêmes toutes les informations (en particulier cela va être à nous de préciser où (classe, méthode, importance de la trace) se situe cette trace dans le message même de la trace)
- on ne contrôle pas où atterrissent les messages : pour un programme Java standard cela va dans la sortie du terminal (il faut donc avoir lancé le programme par le terminal), pour une application tournant dans un serveur (tomcat par exemple) cela va dans un fichier de traces temporaire, purgé périodiquement ce qui interdit toute analyse trop ancienne

La bonne méthode est en fait d'utiliser une librairie dédiée à la trace. La plus populaire ces temps-ci en Java est http://logging.apache.org/log4j/1.2/index.html.
Je vais juste vous indiquer les points-clés de son utilisation (se référer à la documentation en ligne pour plus de détails) :
- il faut ajouter un jar à notre application (un jar est un zip qui regroupe des classes Java), ce jar contenant les classes de la librairie

- log4j fonctionne avec des niveaux de traces (du plus important au plus bénin) : ERROR, WARNING, INFO, DEBUG pour ne citer que les plus utilisés. On pourra ne tracer que depuis le niveau le plus important jusqu'au niveau voulu (ce qui permet facilement de n'afficher que les informations essentielles niveau ERROR pour une application en production, mais d'afficher tous les messages de ERROR à DEBUG pendant le développement avec le même code)

- on aura un fichier de configuration unique de la trace pour toute notre application dans lequel on indiquera où on veut envoyer les messages de trace, le niveau de trace, les informations à insérer automatiquement dans les messages

- on aura une classe dont le seul but sera d'initialiser la trace pour toute l'application à son lancement


1 - Installation de la librairie
On télécharge http://logging.apache.org/log4j/1.2/download.html, on ouvre notre archive et on récupère le jar qui se trouve au premier niveau (log4j-1.2.15.jar pour la version actuelle) et on le copie dans le répertoire WebContent/WEB-INF/lib de notre application (c'est l'endroit dans notre application où tomcat ira chercher les librairies externes).

Ensuite on va dire à Eclipse que notre projet va utiliser cette librairie : comme on a collé notre librairie dans le répertoire par défaut des librairies pour les applications Web standard, il suffit de faire un clic-droit->Refresh sur le répertoire lib pour que Eclipse se rende compte qu'il comporte ce jar.
Si on ouvre dans notre projet l'élément Java Resources : src -> Libraries -> Web App Libraries on y découvre notre jar. On peut même le parcourir pour voir les classes compilées qu'il comporte.


2 - Fichier de configuration de la trace
log4j peut être configuré grâce à un fichier plat (.properties) ou structuré (.xml). On va utiliser un fichier plat.
On va créer un répertoire config dans WEB-INF, puis créer un fichier log4j.properties dedans.
Le contenu de ce fichier sera :

Explications :
- les lignes commençant par # sont des commentaires

- la première ligne indique que le niveau standard de déclenchement de la trace pour l'application sera INFO et que les sorties seront au nombre de deux : CONSOLE et LOGFILE (qui sont configurées juste ensuite)

- le premier bloc de code permet de configurer la sortie CONSOLE : elle écrira dans la console (comme System.out.println), elle acceptera les messages à partir du niveau DEBUG (donc tout ce qu'on lui soumet), et on lui indique le format de chaque ligne de trace (avec en particulier la date+heure et le nom de la classe et de la méthode qui a déclenché la trace)

- le second bloc de code permet de configurer la sortie LOGFILE : ce sera une écriture dans un fichier, on précise où se situera ce fichier, elle acceptera les messages à partir du niveau DEBUG (donc tout ce qu'on lui soumet), et on lui indique le format de chaque ligne de trace (avec en particulier la date+heure et le nom de la classe et de la méthode qui a déclenché la trace)

- enfin la dernière ligne permet de préciser que pour les classes du package fr.iclan (et tous ses sous-packages) on souhaiter un déclenchement au niveau DEBUG (on surpasse ainsi pour notre code le niveau global de trace de l'application)

En pratique pour écrire un tel fichier de configuration, on récupère un exemple sur le site d'Apache, puis une fois qu'on l'a adapté à nos besoins on garde plus ou moins le même pour toutes les applications (seul le chemin du fichier log et les différents niveaux de déclenchement peuvent être à adapter).


3 - Paramétrage du fichier de configuration
Pour pouvoir utilsier plusieurs fichiers de configuration dans notre application, on va rendre l'endroit où le chercher paramétrable.
On ouvre le fichier web.xml de notre application et on ajoute les lignes suivantes après la balise </display-name> (car l'ordre des éléments est important dans le fichier web.xml



4 - Prise en compte de notre fichier de configuration
Pour utiliser notre fichier, il faut configurer au lancement de l'application log4j sur celui-ci.
Pour être sûr de réaliser cela au démarrage de l'application, on va mettre ce code dans une servlet qui sera lancée avant les autres servlets de l'application, au déploiement de l'application.

Dans le fichier web.xml on déclare notre servlet :

Le paramètre load-on-startup indique à tomcat que cette servlet doit être chargée au lancement de l'application, et avant les autres.
Notre servlet n'a pas vocation à être appelée un utilisateur, il n'y a donc pas besoin d'indiquer l'URL de son appel.

Au final notre web.xml ressemble maintenant à ça :


Il ne reste plus qu'à écrire réellement la classe indiquée (fr.iclan.util.servlet.InitServlet) :
sur le répertoire Java Resources : src, on fait clic-droit -> New -> Class.
On indique le pacage fr.iclan.util.servlet.
On indique le nom de l'application InitServlet.

Le contenu de notre classe sera :

Explications :
- package indique le package de cette classe

- les imports donnent les liens vers les classes utilisées dans celle-ci

- notre classe étend HttpServlet

- serialVersionUID (généré ici automatiquement par tomcat) permet juste de savoir quand la classe a été modifiée (pour les classes http://www.developpez.net/forums/d404337/java/general-java/apis/io/debutante-linterface-serializable/) puisqu'on est censé le modifier quand on modifie la classe (comme un CRC). Il n'est pas obligatoire et le concept de Serializable n'est pas important ici.

- log vous indique comment on récupère une poignée sur un traceur log4j (par classe)

- la méthode init(...) sera celle qui sera appelée par tomcat pour charger notre servlet, elle effectue le travail suivant :
--- récupération de la valeur du paramètre "log4jProp" qu'on a indiqué dans le fichier web.xml
--- détermination si le fichier existe directement (chemin absolu) ou non
--- s'il n'existe pas, on suppose qu'il est en relatif par rapport à la racine de l'application et on le complète avec cette racine pour avoir un chemin absolu (c'est important puisque le chemin absolu du fichier change par exemple suivant l'endroit où se trouve le serveur et on ne veut pas avoir à adapter à chaque fois le chemin. On garde néanmoins la possibilité d'avoir un chemin absolu car en pratique en production on aime bien regrouper tous les fichiers de configuration ensemble, hors des applications concernées)
--- configuration de log4j par appel à PropertyConfigurator.configure(log4jProp)

- log.debug(message) permet de générer un message de niveau DEBUG



On lance/relance notre serveur.
Dans la console du serveur dans Eclipse la ligne suivante apparaît pendant le chargement du serveur :

De même dans le répertoire /Applications/Eclipse/logs/ on trouve un fichier vg_actus.log qui contient :


On remarque ici les informations qu'on voulait absolument :
- l'heure de la trace (pour bien se repérer temporellement parmi des traces identiques)
- le niveau de la trace
- la classe à l'origine de la trace
- sa méthode
- la ligne dans le fichier de la classe
- le message de la trace


Notre trace est fonctionnelle.

Projet Eclipse à la fin de cette étape : http://idisk.mac.com/joangazel/Public/iclan/TutorialJava/vg_actus-log.zip


Prochaine étape : mettre en place dans notre application l'authentification basique inclue dans tomcat pour protéger les accès à nos pages d'administration.

Écrit par : DBSor 19 Oct 2008, 12:09

Powaa, ça se complique et j'ai pas trop le temps en ce moment, je vais être bon pour la session de septembre.

Écrit par : atarxerxes 19 Oct 2008, 13:49

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse
5. mise en place du log
6. mise en place de l'authentification Tomcat
7. connexion Java-MySQL
8. récupérations d'informations dans la base
9. génération du flux XML des actualités
10. transformation et affichage du flux XML
11. construction du modèle des pages HTML
12. écriture des requêtes de modification/ajout/suppression
13. écriture des pages de modification/ajout/suppression
14. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
15. saisie facile des dates
16. validation des données saisies
17. écriture de la servlet publique
18. génération du flux Atom

Mise en place de l'authentificaiton Tomcat

Une bonne part du travail dans une application est constituée par la mise en place de la gestion des droits.
En effet en général c'est une partie de l'application extrêmement dépendante du type d'application et du contexte d'utilisation de celle-ci.
La gestion des droits peut se traduire suivant les cas par (du plus basique au plus élaboré) :
- la gestion de l'accès à l'application
- la gestion de l'accès à certaines fonctionnalités de l'application
- la gestion de l'accès à certaines fonctionnalités de l'application en fonction des propriétés des objets sur lesquels s'appliquent celles-ci

Pour notre application, notre besoin est basique : on veut seulement une gestion de l'accès aux pages d'administration de notre application. On va donc pouvoir utiliser l'authentification intégrée dans tomcat.

Ce que sait faire tomcat : restreindre l'accès à certaines URLs (ou à une masque, un pattern d'URLs).
Pour cela, on va regrouper nos pages d'administration dans un même répertoire admin.

1 - Création du répertoire des pages d'administration
Dans Eclipse, dans notre répertoire WebContent, on crée un répertoire "admin".
Dans ce répertoire, on crée une page liste.jsp (qui contiendra plus tard notre liste d'actualités). Pour l'instant son contenu se limitera à cela :


Si on va à l'adresse http://localhost:8080/vg_actus/admin/liste.jsp on vérifie bien que notre page existe désormais sur notre serveur et est accessible sans restriction.


2 - Création du droit applicatif
Vous vous souvenez du fichier tomcat-users.xml (situé dans le répertoire conf de tomcat)? C'est dans ce fichier qu'on va ajouter notre droit applicatif propre et configurer notre utilisateur pour y avoir accès.
On modifie donc notre fichier pour qu'il ressemble à ça :

(vous pouvez bien sûr mettre votre propre utilisateur et mot de passe ).
On a donc ajouté un droit "vgactusadmin" et on a donné ce droit à un de nos utilisateurs.


3 - Restriction des pages applicatives
On va maintenant dire à tomcat de vérifier quand un utilisateur essaie d'accéder à nos pages d'administration qu'il a le droit "vgactusadmin".
On ouvre le fichier web.xml dans Eclipse et on rajoute les lignes :

Explications :
- on ajoute une contrainte de sécurité sur toute URL de la forme "/admin/..." dans notre application

- seuls les utilisateurs ayant le droit "vgactusadmin" pourront y accéder

- la méthode de login sera basique (pas de page de formulaire dédiée, mot de passe qui transite en clair)

- notre application utilisera seulement le rôle "vgactusadmin" parmi les rôles définis dans tomcat-users.xml

Notre web.xml ressemble donc désormais à :


Vu que par défaut tomcat utilise le fichier tomcat-users.xml comme source de données des droits et utilisateurs, aucune autre manipulation n'est nécessaire (on aurait pu par exemple utiliser une base de données ou un autre fichier pour fournir les utilisateurs et les droits...).

On redémarre notre serveur pour prendre en compte les modifications du fichier tomcat-users.xml.
Si on revient sur notre page http://localhost:8080/vg_actus/admin/liste.jsp, on voit apparaître :


On vérifie bien qu'il n'y a qu'en tapant le nom et le mot de passe de notre utilisateur qu'on arrive bien à se connecter à notre page.
La session d'authentification dure tant que notre navigateur est lancé, il faut le quitter pour qu'au prochain lancement il redemande le mot de passe pour accéder à la page.


Projet en fin de leçon : http://idisk.mac.com/joangazel/Public/iclan/TutorialJava/vg_actus-auth.zip



Prochaine leçon : mise en place de la connexion Java-MySQL

Écrit par : Heimdal50 29 Apr 2009, 15:36

Oh grand gourou du SQL Nous attendons avec impatience tes sages enseignements

Écrit par : atarxerxes 29 Apr 2009, 16:14

Je suis en vacances

Écrit par : Gamoul 29 Apr 2009, 16:42

Cool, ça veut dire que tu auras tout ton temps pour nous faire ça

Comment ça tu ne voyais pas ça comme ça ???

Écrit par : DBSor 16 Apr 2012, 14:06

et maintenant, on fait quoi ?

Écrit par : Louis92 16 Apr 2012, 15:39

On est pas vendredi !

Sympa ce topic, sachant que je suis en plein apprentissage de ce langage.
Sinon moi j'utilise BlueJ ( obligation de mon prof ) mais existe il une version de Eclipse pour mac en français ?

Écrit par : titimoby 17 Apr 2012, 08:37

ça intéresse toujours du monde ?
si atarxerxes n'a plus le temps, je peux essayer de proposer la suite avec son accord.

edit : sympa BlueJ, je ne connaissais pas.
C'est pas mal de passer par ça Louis, tu apprendras plus facilement les concepts qui te seront utiles pour tout autre langage.
Pour Eclipse Mac, aucune idée de la localisation en français, je ne connais personne qui utilise autre chose que la version anglaise.
C'est un vrai problème pour toi ?
Au pire, vois avec le site http://babel.eclipse.org/babel/

Écrit par : atarxerxes 27 Apr 2012, 07:29

Pas de problème pour que tu prennes la suite

Écrit par : titimoby 28 Apr 2012, 22:14

J'espère avoir à la fois le temps nécessaire et ton talent explicatif
Je suis en train de faire les étapes comme n'importe qui d'autre pour être sûr d'avoir saisi ta démarche.

Je signale au passage que l'installation de MySql Tools devrait maintenant être remplacée par Mysql Workbench :
http://dev.mysql.com/downloads/workbench/

Les Mysql Tools sont en fin de vie mais peuvent encore convenir.

Pour le permier lancement d'Eclipse (pfff Ganymède ) il y a une petite typo:
On peut ne profiter pour rajouter notre serveur Tomcat dans l'onglet Serveur
au lieu de
On peut en profiter pour rajouter notre serveur Tomcat dans l'onglet Serveur

la table VG_SUPPORT a un souci.
La colonne supp_label est créée en INT mais utilisée comme une chaine.
Je l'ai remplacée par un CHAR(11)

Pour le logger, le fichier log4j.properties est erronné.
il faut écrire
log4j.logger.fr.iclan=DEBUG, LOGFILE

pour que le logger LOGFILE créé soit utilisé.

Écrit par : titimoby 1 May 2012, 21:56

Anecdote qui m'enquiquine :

jusqu'à mon changement de mac, j'utilisait un clavier DiNovo dont je réglai les touches de fonctions sur "utilisation standard" ce qui me permettait l'utilisation de F5 ou F6 pour débug.
le même réglage sur mon clavier apple bluetooth continue de m'afficher Mission Control par exemple...

Une idée ?

Écrit par : Louis92 2 May 2012, 08:11

Tu dois appuyer en bas à gauche sur la touche "fn" ce qui te permet d'utiliser réellement les touches F1, F2, F3....

Sinon dans Préférence système, tu as moyen de changer les réglages des touches "fonctions" pour qu'elles soient directement actives et non pas les applications liées.

Écrit par : titimoby 2 May 2012, 10:10

J'ai renoncé, j'ai enlevé mes réglages de raccourcis que j'avais mis et récupéré mes F5 et F6.

Je connais l'utilisation de Fn+touche fonction puisque ça marche avec F8 mais j'ai cru à une feature trop évoluée, on dira que c'est de ma faute, pas de souci.

allez, je continue de faire chaque étape, voire ce qui peut être erronné dans le tuto.
D'ailleurs je suis étonné de ne pas avoir vu qui que ce soit rencontrer les petits soucis que j'ai eu et en parler ici à l'époque.

Le tuto branche encore du monde ?
Parce que c'est intéressant de refaire une webapp un peu à l'ancienne, ça permet de comprendre des mécanismes importants.
Après, tout ça est très souvent masqués dans des frameworks mais ça reste à connaitre.

Écrit par : titimoby 2 May 2012, 10:35

Accessoirement, je n'avais pas mis en place de sécurité de ce type depuis des lustres... et je n'y parvient plus
J'ai l'authentification qui est active, le user/pass est demandé mais visiblement pas ceux que j'ai définis puisque ça tourne en boucle

Écrit par : Tsukama 5 May 2012, 09:58

Si tout se passe bien pour mes concours, l'année prochaine je me mettrai un peu à la programmation. Donc si le java est bien pour un débutant, je prendrai le tuto du iClan

Écrit par : RooKMooT Junior 6 May 2012, 14:09

J'ai commencé le java depuis peu et en essayant d'écrire un "if": if (resulta = 1 * 2); resulta, 1, et 2 sont des variable int. Netbeans 7.0 me dis:
incompatible type
required : boolean
found : int
Et après avoir relus le passage de "Le livre de java premier langage" sur "if" 3 fois je ne trouve aucun endroit au il est fait mentions de boolean. Que faire??

Écrit par : Leoric 6 May 2012, 14:15

Il faut mettre "==" pour référer à une condition.
Un seule "=" signifie une affectation à une variable.

Écrit par : RooKMooT Junior 6 May 2012, 19:58

Merci, et en plus je viens de regarder et ça par contre c'était écrit en gros dans le livre

Écrit par : DBSor 6 May 2012, 22:13

Comme ça tu ne l'oublieras pas et c'est tant mieux car c'est pareil dans beaucoup de langages.