| Voir le sujet précédent :: Voir le sujet suivant |
| Auteur |
Message |
exlaurent
Bérinaute
Inscrit le: 08 Oct 2008
Messages: 177
|
 Posté le: Sun Jul 26, 2009 12:22 am Sujet du message: |
 |
|
Coucou a tous !
En fait ces histoires me font doucement rigoler. J'ai l'impression que c'est comme l'AOP...
a l'origine l'AOP disait cela: on a du code fonctionnel et du code non fonctionnel dans un programme. Par exemple un programme qui fait des transactions bancaires et qui chiffre ces transactions. Le but premier du programme est de faire des transactions, pas de chiffrer. On a donc:
- propriétés fonctionnelles: transactions
- propriétés non fonctionnelles (cross cutting concern in the english language): le chiffrement.
Well, alors Kiczales est arrive avec l'AOP en 1997 je crois. Il a dit: moi, je sépare les préoccupations fonctionnelles que vous codez en Java des préoccupations non fonctionnelles que vous coderez a coté. On a donc deux codes: le code fonctionnel et le code non fonctionnel. Well... le problème c'est qu'au final on a qu'un seul programme  Il faut donc mélanger le code fonctionnel et le code non fonctionnel. On a donc besoin d'un tisseur (weaver in english). On a donc rajouté un 3eme langage pour faire fonctionner le weaver. Tout ça, ça a donne AspectJ qui est devenu un mix avec AspectWerkz dans sa version 5.
Le bleme c'est que définir les plans de coupe (les endroits ou le code non fonctionnel doit être inséré dans le code fonctionnel) est tellement pas naturel et sujet a erreur qu'ils ont dit: bon ok, on va directement écrire dans le programme fonctionnel les endroits ou on veut que ça coupe grâce... aux annotations
Ils ont donc remplacé les appels de fonction par des annotations en passant par une courte étape XML dans le temps.
Ben c'est pareil pour J2EE... leurs histoires en XML pour configurer les beans était tellement imbitable qu'ils sont revenu dans les EJB3 aux annotations. Sérieux, définir des relations n-m en XML, définir des tables SQL en XML... Qui trouve ça naturel ??? Et je parle pas de l'ejb-ql la...
Bon on a observé cette mouvance un peu partout dans le monde informatique avec toujours le but de séparer les préoccupations. Donc mon avis est que tout ça, le retour aux annotations dans le code source, c'est un retour aux sources après s'être aperçu que sortir les préoccupations non fonctionnelles pour les mettre a cote en XML puis les ré-intégrer par une solution tierce partie par exemple était certes plus propre, mais beaucoup plus difficile a utiliser et donc générateur d'erreur.
En gros les annotations sont un sain retour a des solutions intégrées dans le code source (donc faciles a visualiser) mais dans une syntaxe plus riche que le code source pour des pré-occupations non fonctionnelle.
Laurent
Dernière édition par exlaurent le Sun Jul 26, 2009 12:49 am; édité 1 fois |
|
| Revenir en haut de page |
|
 |
exlaurent
Bérinaute
Inscrit le: 08 Oct 2008
Messages: 177
|
| Posté le: Sun Jul 26, 2009 12:37 am Sujet du message: |
|
|
Oups en fait je m'aperçois que j'ai pas répondu a la question qui est "les annotations vont elles dégager XML ?"
Je me suis plus concentré sur le pourquoi du XML dans les langages objets et pourquoi le retour du code intégré aux sources par le biais des annotations.
Well donc les annotations vont elles remplacer XML ? Ben pour ce qui est de la séparations des préoccupations fonctionnelles et non fonctionnelles telles qu'en AOP ou J2EE on dirait que c'est le cas.
Ensuite XML reste utile pour tout ce qui est configuration ou échange de configuration dans les Web Services, etc etc...
En fait il y a eu une mode XML mais les gens en reviennent. Par exemple une grande mode était de programmer des interfaces graphiques en XML ou des architectures applicatives en XML (modes a composants). la le but n'était plus de séparer des pré-occupations mais de simplifier la vie du programmeur.
En effet qui a déjà code une interface en Swing sait que c'est chiant... Qui a déjà fait une architecture applicative en Fractal sait comment c'est chiant... Donc le XML permet de décrire les interfaces graphiques ou l'application.
Hormis que le problème c'est que c'est statique... Si dans mon fichier XML je mets un bouton et que je m'en tiens au XML, je ne pourrais pas faire varier le nombre de bouton dans la fenêtre... Il y a donc toujours besoin de l'API.
Donc un compromis intéressant a été trouvé: configuration initiale en XML puis modification de l'architecture par les API.
Un autre problème de XML est l'impossibilité de spécifier une "grammaire". Il faut pour cela utiliser une DTD. Ainsi si je code une interface graphique je pourrais lui mettre 1 bouton grâce au XML. Je pourrais en rajouter 3 grâce aux API. Mais rien ne m'empêchera d'enlever tous les boutons grâce a l'API même si c'est un non-sens. Il faut donc introduire une DTD pour empêcher ce genre de manipulations, en gros pour borner en min et en max le nombre de boutons.
Bref, on cherche, on cherche... On généralise tout ça grâce a des modèles et méta modèle et on essaye de faire varier tout ca durant l'exécution. On appelle ça model @ runtime...
Donc pour répondre a la question XML et annotations servent a des choses distinctes et hormis dans des cas particuliers l'un ne remplacera pas l'autre. Par contre ils ont tous les deux des défauts... et des avantages
Laurent |
|
| Revenir en haut de page |
|
|
unistern
Inscrit le: 26 May 2008
Messages: 593
|
| Posté le: Sun Jul 26, 2009 8:05 pm Sujet du message: |
|
|
interessante intervention Laurent. c'est tjr un savour d'apprendre autant dans tes Post.
en effet voici en gros ton constat qui légitime bien a ma question
| Citation: |
Well donc les annotations vont elles remplacer XML ? Ben pour ce qui est de la séparations des préoccupations fonctionnelles et non fonctionnelles telles qu'en AOP ou J2EE on dirait que c'est le cas. |
"on dirait que c'est le cas " ou bien alors c'est effectivement le cas  a travers ton premier message tu as selon moi donné de tres bon arguments en faveur des annotations :
| Citation: | Donc mon avis est que tout ça, le retour aux annotations dans le code source, c'est un retour aux sources après s'être aperçu que sortir les préoccupations non fonctionnelles pour les mettre a cote en XML puis les ré-intégrer par une solution tierce partie par exemple était certes plus propre, mais beaucoup plus difficile a utiliser et donc générateur d'erreur.
En gros les annotations sont un sain retour a des solutions intégrées dans le code source (donc faciles a visualiser) mais dans une syntaxe plus riche que le code source pour des pré-occupations non fonctionnelle.
|
en plus de cela j'ajouterai comme je l'ai déja dit : plus besoin d'aller apprende xml pr le le codeur habituel en java .
dans le second post il ya qud mm kk points de ton message où j'aimerai intervenir .
| Citation: |
Donc pour répondre a la question XML et annotations servent a des choses distinctes et hormis dans des cas particuliers l'un ne remplacera pas l'autre |
je dirais plutot que les annotations effectuent le meme travail que xml dans les Beans (surtout au niveau du deploiment dans les EJB) . en dehors des beans ils pourraient avoir des usages differents.
| Citation: | | Un autre problème de XML est l'impossibilité de spécifier une "grammaire" . Il faut pour cela utiliser une DTD. |
n'est ce pas là je dirais plutot un gros avantage de xml? eviter d'avoir une 'grammaire' propre ou déja prédéfinie . xml evite au programmeur d'etre limité . celui ci peut declarer et definir ses "Tags" comme bon lui semble.
en plus meme , ils ont comblés les limites du DTD par les XS Schema.
| Citation: |
En effet qui a déjà code une interface en Swing sait que c'est chiant... Qui a déjà fait une architecture applicative en Fractal sait comment c'est chiant... Donc le XML permet de décrire les interfaces graphiques ou l'application.
Hormis que le problème c'est que c'est statique... Si dans mon fichier XML je mets un bouton et que je m'en tiens au XML, je ne pourrais pas faire varier le nombre de bouton dans la fenêtre... Il y a donc toujours besoin de l'API.
|
j'ai pas trop bien compris ce que tu voulais dire là.. Xml est fait a priori juste pr decrire . en quoi est ce que decrire rendrait-elle l'elaboration des codes back-end moins chiant.? lol peut etre j'ai mal compris où tu voulais en venir.
du moins je pense qu'on a tjr besoin d'une autre technologie quand on utilise xml et en j2ee c'est les api java avec les applet , les javabeans , mySQL etc ... xml lui seul ne peut pratiquement rien.
ma question au niveau des perfommance n'est pas encore totalement satisfaisante 
hmm mais faut avouer que ces gens là ne dorment pas hein? apres xml , annotations ce sera quoi? |
|
| Revenir en haut de page |
|
|
exlaurent
Bérinaute
Inscrit le: 08 Oct 2008
Messages: 177
|
| Posté le: Sun Jul 26, 2009 8:29 pm Sujet du message: |
|
|
| unistern a écrit: | interessante intervention Laurent. c'est tjr un savour d'apprendre autant dans tes Post.
|
Merci
| unistern a écrit: |
en plus de cela j'ajouterai comme je l'ai déja dit : plus besoin d'aller apprende xml pr le le codeur habituel en java .
|
Certes mais besoin d'apprendre la syntaxe et la sémantique des annotations... Donc retour au point de départ. L'avantage de XML était aussi de pouvoir s'appliquer de la même manière a tous les langages.
| unistern a écrit: |
je dirais plutot que les annotations effectuent le meme travail que xml dans les Beans (surtout au niveau du deploiment dans les EJB) . en dehors des beans ils pourraient avoir des usages differents.
|
Yes, il me semble qu'on dit bien la même chose
| unistern a écrit: | n'est ce pas là je dirais plutot un gros avantage de xml? eviter d'avoir une 'grammaire' propre ou déja prédéfinie . xml evite au programmeur d'etre limité . celui ci peut declarer et definir ses "Tags" comme bon lui semble.
en plus meme , ils ont comblés les limites du DTD par les XS Schema.
|
Il peut toujours définir ses tags comme bon lui semble même avec les DTD. Sans grammaire ça devient vite le bordel: ton parser XML ne peut faire aucune hypothèse sur la présence d'attributs ou non...
Prends un exemple: un fichier de configuration d'un serveur. Bon si tu n'as pas le port sur lequel te binder, tu fais quoi ? Tu vas me répondre j'en ai un par défaut. Yes, mais tu dois donc prévoir tous les cas ou l'utilisateur fait n'importe quoi. Avec une grammaire tu n'as pas ce problème.
| unistern a écrit: | j'ai pas trop bien compris ce que tu voulais dire là.. Xml est fait a priori juste pr decrire . en quoi est ce que decrire rendrait-elle l'elaboration des codes back-end moins chiant.? lol peut etre j'ai mal compris où tu voulais en venir.
|
Je veux juste dire que XML s'arrete a de la description statique. Tu dois avoir un API derriere pour gerer les aspects dynamiques.
Imagines une interface graphique de ce genre la en XML:
window titre ="ma fenetre"
field titre="user"
button titre="ok" state=disabled
/window
(j'ai enlevé les supérieurs et inférieurs car le forum ne les prends pas...)
Tu crées donc une fenêtre avec un champs user et bouton qui est "disable". Tu "enables" ce bouton quand l'utilisateur rentre un user dans le champs.
Well tu dois avoir une API pour faire ça... XML ne peut plus rien pour toi... Donc le problème est que l'utilisateur doit connaitre l'API (comme avant) mais il doit en plus connaitre le XML associe... Donc avec XML il doit apprendre un truc en plus. Pareil pour les annotations.
| unistern a écrit: |
ma question au niveau des perfommance n'est pas encore totalement satisfaisante
hmm mais faut avouer que ces gens là ne dorment pas hein? apres xml , annotations ce sera quoi? |
Perf a quel niveau ?
Laurent |
|
| Revenir en haut de page |
|
|
unistern
Inscrit le: 26 May 2008
Messages: 593
|
| Posté le: Tue Jul 28, 2009 10:32 pm Sujet du message: |
|
|
| Citation: | Il peut toujours définir ses tags comme bon lui semble même avec les DTD. Sans grammaire ça devient vite le bordel: ton parser XML ne peut faire aucune hypothèse sur la présence d'attributs ou non...
Prends un exemple: un fichier de configuration d'un serveur. Bon si tu n'as pas le port sur lequel te binder, tu fais quoi ? Tu vas me répondre j'en ai un par défaut. Yes, mais tu dois donc prévoir tous les cas ou l'utilisateur fait n'importe quoi. Avec une grammaire tu n'as pas ce problème.
|
salut Laurent. je sais pas exactement ce que tu entends par grammaire ici. j'ai pensé que tu parles de la semantique generale de xml. cad les regles generales pr les tags ( elements attributs etc...)
| Citation: |
e veux juste dire que XML s'arrete a de la description statique. Tu dois avoir un API derriere pour gerer les aspects dynamiques. |
ah ok je vois. c'est clair .
| Citation: |
Imagines une interface graphique de ce genre la en XML:
window titre ="ma fenetre"
field titre="user"
button titre="ok" state=disabled
/window
(j'ai enlevé les supérieurs et inférieurs car le forum ne les prends pas...)
Tu crées donc une fenêtre avec un champs user et bouton qui est "disable". Tu "enables" ce bouton quand l'utilisateur rentre un user dans le champs.
Well tu dois avoir une API pour faire ça... XML ne peut plus rien pour toi... |
effectivement
| Citation: |
Donc le problème est que l'utilisateur doit connaitre l'API (comme avant) mais il doit en plus connaitre le XML associe... Donc avec XML il doit apprendre un truc en plus. Pareil pour les annotations. |
pkoi l'utilisateur devrait til encore apprendre le xml associé ? prend par exple les application jsf. le client n'a aucune connaissance des fichiers xml . tout ce qu'il voit c'est les UI(user interface) . il passe ses commandes (parametres) a travers les browser et le reste de deroule sur le serveur.
| Citation: | | Perf a quel niveau ? |
eh ben perf au niveau de la rapidité d'execution , de la charge du serveur comme celui du client, enfin au niveau de la komplexité quoi? |
|
| Revenir en haut de page |
|
|
TheNeo
Shabbaeur du lac
Inscrit le: 12 May 2008
Messages: 4281
Localisation: Bangos Zomoville
|
|
| Revenir en haut de page |
|
|
unistern
Inscrit le: 26 May 2008
Messages: 593
|
| Posté le: Tue Aug 04, 2009 5:49 pm Sujet du message: |
|
|
Laurent voici un exemple que j'ai pris pour illustrer ce que je disais.
l'utilisateur entre les parametres sans se soucier de la technologie qui se cache derriere lorsqu'il click le bouton "Abschicken".
 |
|
| Revenir en haut de page |
|
|
sean
Inscrit le: 15 May 2008
Messages: 103
Localisation: road to zion
|
| Posté le: Wed Nov 04, 2009 1:46 pm Sujet du message: |
|
|
j'ai pas eu le temps de tout lire , est qu'il y'a un concourt en cours ?? si oui je veut bien y participer .
j'ai un ptit projet en cours , je doit monter un serveur via les threads , je galère un peu , si quelqu'un sy connait bien , j'ai deux ou 3 questions a poser.
Ps : unist jolie ce que t'as fait , j'ai fait un truc pareil (sudoku) , mais via C++/QT4
_________________
the heartBeat.. |
|
| Revenir en haut de page |
|
|
unistern
Inscrit le: 26 May 2008
Messages: 593
|
| Posté le: Wed Nov 04, 2009 6:08 pm Sujet du message: |
|
|
| sean a écrit: | | j'ai pas eu le temps de tout lire , est qu'il y'a un concourt en cours ?? si oui je veut bien y participer . |
salut sean.
ya un petit concour sur la kryptographie que j'avais proposé mais personne ne la relevé. si ca t'interesse tu peux tjr te lancer. sinon on peut tjr proposer un nouveau truc. qu'esse t'en dis?
| sean a écrit: |
j'ai un ptit projet en cours , je doit monter un serveur via les threads , je galère un peu , si quelqu'un sy connait bien , j'ai deux ou 3 questions a poser.
|
pose tes questions man.
| sean a écrit: |
Ps : unist jolie ce que t'as fait , j'ai fait un truc pareil (sudoku) , mais via C++/QT4 |
oh mais interessant. fais nous dc voir les pictures si possibles.
ps: comment t'as réalisé la parti KI c'est surtout là que le tt deviens interessant  |
|
| Revenir en haut de page |
|
|
sean
Inscrit le: 15 May 2008
Messages: 103
Localisation: road to zion
|
| Posté le: Wed Nov 04, 2009 9:42 pm Sujet du message: |
|
|
je suis partant pour le concourt , je vais me pencher desus
des que je trouve le code de mon projet sudoki , je le poste
concernant mon pb sur les threads , j'ai fait ca , mais ca fonctionne pas !
| Code: |
/* usage : serveurTCPMTh port .... */
#include "creerSocket.h"
#include <pthread>
#define TRUE 1
typedef void *(*fonction)(void *);
void *service(int); // fonction externe pour le service
pthread_t threadid; // pour l'identité d'une nouvelle thread
pthread_attr_t attr; // pour les attributs d'une nouvelle thread
int main(int argc, char *argv[]) {
static struct sockaddr_in adr;
int lg_adr = sizeof(struct sockaddr_in);
int port = atoi(argv[1]);
int ecoute, connexion;
if(argc < 2) {
fprintf(stderr, "Nombre de paramètres incorrect\n"); exit(2); }
/* détachement du terminal */
if(fork() != 0) exit(0);
setsid(); printf("serveur de pid %d lancé\n", getpid());
/* création et attachement de la socket d'écoute */
ecoute = creerSocket(SOCK_STREAM, port, &adr);
if(ecoute == -1) {
fprintf(stderr, "Création de la socket d'écoute impossible\n");
exit(2); }
/* déclaration d'ouverture du service */
if(listen(ecoute, 10) == -1) {perror("listen"); exit(2); }
/* boucle d'attente de connexion */
while(TRUE) {
connexion = accept(ecoute, (struct sockaddr *)&adr, &lg_adr);
if(connexion == -1) {perror("accept"); exit(2); }
/* préparation des attributs de la thread dédié */
pthread_attr_init(&attr);
/* la thread est créée dans l'état détaché */
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
/* la thread est une thread système */
pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM);
if(pthread_create(&threadid, &attr, (fonction)service, (void *)connexion) == 0)
continue;
else {
/* problème à la création de la nouvelle thread */
/* ici on a choisi de fermer le connexion avec le client */
close(connexion); }
}
} |
_________________
the heartBeat.. |
|
| Revenir en haut de page |
|
|
unistern
Inscrit le: 26 May 2008
Messages: 593
|
| Posté le: Wed Nov 04, 2009 10:43 pm Sujet du message: |
|
|
Sean il ya un tas de parametre qui manque pr analyser le code.
tu executes sous linux ou windows? (APPAREMENT windows ne reconnait pas les bibliotheque importé pr les traitements de thread. par contre sous linux
ya kk librairies que je te propose d'inclure
#include pthread.h>
#include stdio.h>
#include sys/timeb.h>
#include sys/select.h>
#include sys/socket.h>
#include sys/types.h>
#include sys/wait.h>
#include netinet/in.h>
#include string.h>
#include fcntl.h>
#include signal.h>
#include errno.h>
le compilateur jette quoi comme message ? |
|
| Revenir en haut de page |
|
|
sean
Inscrit le: 15 May 2008
Messages: 103
Localisation: road to zion
|
| Posté le: Thu Nov 05, 2009 5:33 am Sujet du message: |
|
|
Oups, j'avais oublier de préciser , je developpe sous linux
pour ces bibliothèque , je les avaient incluses ds #include "creerSocket.h"
| Code: |
#include <stdio>
#include <stdlib>
#include <unistd>
#include <netdb>
#include <sys>
#include <sys>
#include <netinet>
#define TRUE 1
int creerSocket(int, int, struct sockaddr_in *); |
resultat de la compil :
| Code: |
sean@sean:~/Bureau/unix$ make
gcc -D_REENTRANT -DLinux -c serveur.c
gcc -lpthread -o run_app serveur.o
serveur.o: In function `main':
serveur.c:(.text+0xa7): undefined reference to `creerSocket'
serveur.c:(.text+0x194): undefined reference to `service'
collect2: ld returned 1 exit status
make: *** [run_app] Erreur 1
|
_________________
the heartBeat.. |
|
| Revenir en haut de page |
|
|
sean
Inscrit le: 15 May 2008
Messages: 103
Localisation: road to zion
|
| Posté le: Thu Nov 05, 2009 5:54 am Sujet du message: |
|
|
j'ai resolu mon problème , en fait c'etais juste un problème de compilation , j'avais pas inclus tous les fichiers sources ds le makefile 
_________________
the heartBeat.. |
|
| Revenir en haut de page |
|
|
unistern
Inscrit le: 26 May 2008
Messages: 593
|
| Posté le: Thu Nov 05, 2009 2:07 pm Sujet du message: |
|
|
| sean a écrit: | | j'ai resolu mon problème , en fait c'etais juste un problème de compilation , j'avais pas inclus tous les fichiers sources ds le makefile |
le compilateur diasais meme déja tt . ben super alors coe t'a résolu le pb!
je wait les pic soduku avec cute. |
|
| Revenir en haut de page |
|
|
Queen B
Inscrit le: 12 May 2008
Messages: 15741
Localisation: In the ligth; Under the sun; In his lovely arms.
|
| Posté le: Thu Nov 05, 2009 3:46 pm Sujet du message: |
|
|
Hello les bros.
J'ai une ptite question: PC et Macintosh st des programmes?
_________________
Go girl!! Keep smiling to life.Un jr j'irais vivre en Théorie; car en Théorie tt se passe bien. |
|
| Revenir en haut de page |
|
|
sean
Inscrit le: 15 May 2008
Messages: 103
Localisation: road to zion
|
| Posté le: Fri Nov 06, 2009 9:13 am Sujet du message: |
|
|
| Queen B a écrit: | Hello les bros.
J'ai une ptite question: PC et Macintosh st des programmes? |
non se sont des "architecture" (windows et unix ou mac) qui utilise des systemes d'exploitation différénts
_________________
the heartBeat.. |
|
| Revenir en haut de page |
|
|
Queen B
Inscrit le: 12 May 2008
Messages: 15741
Localisation: In the ligth; Under the sun; In his lovely arms.
|
| Posté le: Fri Nov 06, 2009 11:52 am Sujet du message: |
|
|
Euuuuuh.......... ok. Merci bro
_________________
Go girl!! Keep smiling to life.Un jr j'irais vivre en Théorie; car en Théorie tt se passe bien. |
|
| Revenir en haut de page |
|
|
meke
Bérinaute Vétéran
Inscrit le: 16 May 2008
Messages: 5079
Localisation: france
|
| Posté le: Fri Nov 06, 2009 5:25 pm Sujet du message: |
|
|
| Queen B a écrit: | | Euuuuuh.......... ok. Merci bro |
_________________
 |
|
| Revenir en haut de page |
|
|
unistern
Inscrit le: 26 May 2008
Messages: 593
|
| Posté le: Fri Nov 06, 2009 5:55 pm Sujet du message: |
|
|
salut a tous
Meke et Queen B bienvenu dans le topic du monde digitale. il ya un manque criard de gente feminine par ici ce n'est dc qu'avec un enorme plaisir qu'on vous souhaite la bienvenu en esperant que vs ne vs en irez pas de si tôt.
pr vous acceuilir j'ai préparé un petit concours. suite a la demande de Sean
pr ce cas précis il s'agit de mesurer ou bein de performer ses connaissances a la fois en DBMS (database management System) en O/R Mapping et en Frontend Frameworks et plus particulierement Spring ( pr répondre a lucatoni qui en sait un peu plus qu'il n'en dévoile ici )
bon pr l'explication du petit exercice je bigin par un résumé qui decrit ce que represente l'image ci dessous:
il s'agit du GUI representant les fonctions d'un mini AdressBook que j'ai il ya deux jours implementé en Swing
le button load book du Gui est capable de lire les donnés dans un fichier et afficher a la fenetre , pr le reste des bouttons leur fontion se déduisent de facon intuitive.
concernant le défi il est dc question de changer kk fonctionalité du GUI
de facon a lire les données ou bien les sauvegardé non plus dans un fichier cette fois ci mais dans un DB (au choix) . il n'est plus question de serializé les instances pr "flush-en" dans une file mais de "mappen" les objects a l'aide d'un O/R mappeur comme Hibernate par exple. le tt doit se jouer dans le framework Spring ( clin d'oeil a Lucatoni).
que ceux qui se sentent chaud pr le défi se prononce.
j'ecrirais kk petit tutoriaux en Hibernate au souhait pr ceux qui ne sentent pas encore bien assis en O/R mapping.
 |
|
| Revenir en haut de page |
|
|
lucaToni
Shabbaeur du lac
Inscrit le: 18 Jun 2008
Messages: 4021
|
| Posté le: Fri Nov 06, 2009 7:23 pm Sujet du message: |
|
|
Son prenom c'est Carlos Carlos Blanka
Pour ton defi hum .. ça a l'ai interessant sulement que contrairement a ce que tu crois Spring c'est pas trop mon truc meme comme j'ai un peu joué avec quand je bossait je suis partant la partie hibernate c'est cool je vais lire 2 tutoriaux de spring que j'ai pour voir ce que je peux faire . Mais je t'avertit java swing c'est pas nom plus trop mon truc je suis plutot flash Pour Implementer des GuI si tu veux je te fais tout ça en
flash + action script + hibernate + mysql
ça me prendrai qu'un heure environ mais si tu insiste avec Spring je le fait mais pas ce week mais le week end prochain |
|
| Revenir en haut de page |
|
|
|
FAQ
Rechercher
Liste des Membres
Groupes d'utilisateurs
S'enregistrer
Profil
Se connecter pour vérifier ses messages privés
Connexion
