Bonjour les gens la on va parler un peu de Java de l'avenir pas 1.5 mais aussi les JAVA SERVER FACE comme millstone...
 
Des applications bureau qui restent legère pour le client (pas comme un applet). grace a XML et plein de chose.
 
Millstone est hyper skinable grace a nos amis de chez CSS et HTML et ca donne des sortes de Servelts mais qui donne des appli belles...
 
http://www.millstone.org ...
 
  Syruis

t'es vendeur pour millstone ?

et toi??? millstone Open source et free.
 
de plus vazi parlons de JSF dans ca grande largueur!!!
 
Syruis

ouais allons y... moi je suis pour :
 
1/ le cote composant reutilisable.
2/ le fait de pouvoir utiliser un composant dans une portlet ou une appli web independament
 
j'ai pas encore de contre, vu que j ai pas essaye, excepte que les implementations RI et myfaces implementent pas la partie portlet
ce qui craint du boudin.

jsf s'éloigne de java il part vers une couche de prog supérieur par apport a jsp. Pour moi le problème c que les IDE tardent a sortir... et que notre ami sosoft(lol) et notre ami Mozilla vont sortir deux format l'un n'étant pas compatible avec l'autre.
 
Il vou faudra 2 browser en permanance...
 
Ce sont des évolutions encore plus haut que Millstone (lui deja bien en place)  
 
Par contre jai oublié le nom des 2 normes... dsl

XUL / XML ... JSF fonction en XML aussi ??
 
je viens d'aller voir le site .. je suis allé voir le code source .. pour le developpeur c'est génial .. le code est objet et assez abstrait pour avoir le code générique .. mais pour la visu je suis resté sur ma faim .. XUL est génial de ce coté là .. là, ca apporte une portabilité peut être mais c'est pas révolutionnaire

XUL/XAML
 
J'ai vaguement regardé JSF il y a quelques mois, ça m'avait laissé un peu froid.

XML n'est pas un nouveau format et n'est pas propriétaire.
 
XSLT par contre va connaitre une nouvelle extenssion de malade  XUL également vous verez...
 
La révolution ce sera des applications type applet, application bureau( mais web), qui sont lourdes pour les clients va devenir aussi graphique et pour autant une application serveur lourde!!

youpie, un nouveau prophête

JSF est independant de la technologie de rendu par le biais de kits de rendu.

la revolution on la connait deja ;-)
 
XAML/XUL/(SUN??) interface ihm wrappé à du XML afin de rendre les applications le plus "portable" possible.. execution de programme distant ou local de la meme facon .. les explorateurs pourront facilement devenir des clients lourds .. voilà ..
 
applet .. c'est mort trop lourd et trop compliqué .. .. p'etre que tu t'exprimes mal

 
lesquels? je suis interressé

oué, du futurologue à casser.
 
une application qui se fout sur le bureau ça serait pas un client lourd par hasard ?
 
Et si un client lourd qui est une simple interface de BDD en swing était plus léger et pratique qu'un navigateur web qui bouffe 50Mo de mémoire, croyez-vous que les crétins du web avoueraient leur erreur ?
 
Et si finalement, la bonne manière de faire des choses dans une sessions c'était d'ouvrir une socket TCP et pas de faire du HTTP, des cookies, des ID de session, et autres conneries aussi inadaptées que bouffeuses de ressource et casse-gueule ?
 
Et si le futur était rationnel et reprenait non pas le sbesoins sur la pile de bordel, mais depuis la base ?
 
Et si la nouvelle puissance que nous offre la technologie était utilisée pour fournir plus au client ?

Honnêtement, c'est mal parti

la revolution .. se fait .. du coté de la création de l'interface IHM (via XML) ruuhm d'en un premier temps.. et dans un second temps sur le fait que les "services" pourront etre disponible à distance (webservice généralisé).
Je vois ca comme ca.  

ruhhm .. .. .. quel intéret de refaire une appli de A à Z quand on peut se servir de l'existant? Une db que plusieurs poste dans le monde attaque? dans une DSI hesitante à l'installation de nouvelles applications sur les postes clients?

réinventer la roue ce n'est pas mieux! refaire un service socket TCP avec du code source non éprouvé .... c'est bien plus dangereux.

bordel ou ca?

humm ... c'est clair que là faut retourner à coder en VB 5. . . . . .

 
tu peux plugger ce que tu veux

+1  
 

du xul ? ;-)
 
quelle est la reponse de sun à XUL/XAML ?

bravo, 0/5, pas une seule réponse dans l'axe.
 
1) créer une intarface à partir de XML ne présente exactement *aucun* intérêt en soi. C'est sandard en java depuis 1998, et ce n'était absolument pas une révolution à l'époque.
 
2) je vois pas le rapport avec le fait de "refaire" un truc de a à z, le lien avec une base de données ouverte, et l'installation / déploiement d'un application lourde, n'est pas obligé de se faire par un truc style installshield, webstart, les applets et d'autres trucs sont bien plus adaptés.
 
3) chèvre.
 
4) dans ton cul, naturellement.
 
5) je vois pas le rapport avec VB 5. Si pour toi utiliser sans les gâcher des ressources, c'est utiliser des outils du passé, alors tu n'a rien compris à l'innovation en tant que tel.

swing/javabeans, le dernier ajustage date de 98.

heu, je sens que ça va venir alors je prends les devants : si je parle de java, swing, tout ça, c'est parce que je suis dedans en ce moment. Moi les clochers je les emmerde, et je vais me lancer à fond dans .net dès que ce sera matériellement possible.

pkoi .net ?

parce que ça attire ma curiosité, c'est un de trucs qui semble avoir des objectifs sérieux. Bref pas de vraie réponse : j'ai envie.
 
Il faudrait que je retourne taquiner la logique aussi, mais j'ose plus.

comment expliques tu que dans la prochaine version de Windows XAML sera le standard pour le developpement des IHM .. je serais toi j'irais dire à Microsoft qu'ils se trompent

explique moi pkoi alors tout le monde fuit les applets?? et ça depuis sa création.. Sun serait content de t'entendre

mouton .

??

L'informatique et là uniquement pour faciliter le travail. C'est le principe meme du mot.. .. si tout le monde comme les banques ou encore les assurances sont gourmandes d'informatique c'est pas pour le fun ni pour se complexifier la vie .. au contraire.. .. .. .. ..
toutes les nouvelles technologies emergeantes ne sont pas là pour se masturber le cerveau en quête de nouveau passe temps au frais du client .. .. c'est bien justement au final pour apporter une nouvelle technologie plus simple et plus transparante pour l'utilisateur final.. désolé si pour le développeur ca demande plus de neurones

 
.Net .. ça a deja 2 ans
swing ... bouhh ca fait deja bien 6 ans bien tassé ... .. .. swing est déjà en train d'être remplacé faut suivre
maintenant c'est beau d'emmerder les clochers, mais bon, à ce rithme là .. j'preferais programmer en C en mode Dos .. c'etait plus mieux.

ces techno n'apportent exactement *rien* à ce niveau là. Elles ne décomplexifient rien, au contraire elles empilent, en empilant elle empilent les points d'erreur que l'utilisateur verra vont bouffer des ressources inutilement ; et enfin, SI la vie du dev doit s'améliorer, c'est un utilisateur d'informatique comme un autre.
 
Quel est le rapport entre un comptable qui fait son rapprochement banquaire et la commande DEL du serveur HTTP ? ça n'a rien à voir, rien à foutre là. Qu'est-ce que le comptable en a à foutre de XAML ? par contre, qu'on l'emmerde avec des boutons "back" qui marchent pas dans le navigateur pour des histoires de "post", qu'on le gonfle avec de menus style "bookmark" dans son browser, que ça rame comme pas permis, qu'il soit obligé d'acheter une bécane/connexion énorme parce "c'est XML" ça ben ça l'emmerde.

c'est pas la date de sortie qui fait l'innovation. Je connais des truc dont je suis à peu près sûr que tu n'entendras pas parler avant 5-6 ans, les fondements de ces trucs sont de 1980.
 
Le dernier processeur de chez Intel boote en 12 bits, comme en 1980.

alors tu n'as tout simplement pas compris ce qu'était XUL / XAML .. .. ..
 
puisque ton dernier ecrit va dans le sens de ces 2 dernieres technologies

euh, millstone, pour les belles interfaces "grace a nos amis de chez CSS et HTML", on repassera:

non, parce qu'on revient au téléchargement d'applet avec ces trucs, et c'est nul, on sait déjà télécharger et démarrer une applet sans une seule goute de XML (qui bouffe une tonne de reoussource de maières intrinsèque, je le rappelle) et surtout qu'avec une vraie applet java ou .net, on a le choix du canal de communication et la possibilité de ne pas mettre des sourcouche de crétin des alpages tels qu'un serveur web (qui fonctionnellement, sert à combler le fossé technologique entre HTTP et TCP et les limitatoins des clients webs) à l'autre bout.

téléchargement d'applet avec ces trucs. tss rien compris donc.

 
c'est laid mais c'est valide

la puissance du xml dans ce cas là .. c'est la normalisation future du langage (décrivant les ihm) qui en écoulera.
 
Le but est de décrire de façon le plus simplement et le plus modulairement possible l'ihm et les comportements/evenements de l'application.
 
Enfin, d'apporter une vision plus 'objet' à la conception d'applications orientées Internet.
 
Mais bon, à ce que j'en vois, JSF apporte une 'inovation' du coté de la conception. XUL/XAML du coté de l'ihm.
 
Je vois ça comme ça pour ma part.
 
un bon article qui va dans ce sens : http://www.01net.com/article/231067.html

ça n'apporte rien, swing était déjà modulaire, je subodore que Winforms aussi. Là où il y a un coup à jouer, c'est sur une copie de du DisplayView de Designer, mais on en est pas là :  
1) xul, c'est encore des widgets.
2) un DisplayView n'a strictement aucun intérêt à être téléchargé en tant que tel chez le client, on doit ne télécharger que l'interface qui correspond.
3) c'est un outil qui concerne uniquement les développeurs et les utilisateurs n'en ont rien à foutre.
 
Il y a *évidement* un lien entre applet et xul, on télécharge des trucs de plus en plus complexes chez le client, on valide même des dates en javascript, bref, on charge le client comme un rat mort, la connection et le serveur. Personne n'y gagne.
 
Qu'éventuellement Xul soit transformé en un .class au cours du process de développement, pour être téléchargé en client lourd, soit, mais ça n'apporte pas plus non plus.
 
 
Sachant que cette norme est vouée à l'inflation, on avant le HTML, on y a mis des formulaire, on a rajouté du java script, on a remis du CSS, on a rajouté les touches rapides, on y remet des interfaces xul. Bref, on fait comme java et .net mais en moins bien, parce que là-dessous, on télécharge des XML de plus en plus gros, on interprète tout à la volée, on a un travail serveur énorme et on est dépendant du canal d'accès.

ouarf...  
1/ XUL est plus que des widgets.
2/ on doit ne télécharger QUE l'interface qui correspond: c'est exactement ce qui est souhaité faire avec ces technologies.
3/ c'est un outil pour faciliter le travail du développeur ET apporter quelque chose qui n'existe pas encore à l'utilisateur.
 
Il n'y a *evidement* aucun rapport entre ce qu'on appelle courrament un applet (java?) et xul, on NE telecharge que l'affichage et le comportement de celui-ci justement pour décharger le serveur de ce genre d'action. On valide MEME des dates en javascript pour ne pas avoir à le faire sur le serveur et gagner du temps (incompréhensible ton raisonnement..), bref, on charge le client comme un rat mort car il a de la puissance et que le serveur lui, n'est pas QUE pour gérer la logique métier et n'utiliser inutilement de la bande passante (conneXion). tout le monde y gagne.
 
Qu'éventuellement XUL soit transformé en un .clas au cours du process de développement, pour être téléchargé en client lourd, soit, il perdrait tout l'intérêt de ne pas faire parti du package métier et donc pouvoir être modifié trés rapidement (principe des MVC).
 
Sachant que cette norme est vouée à être normalisée.., on avait avant le HTML, on y a mis des formulaires puisque ce langage avait un rôle structurel., on a rajouté du java script afin de pouvoir interpreter le comportement de l'utilisateur, on a remis du CSS afin de rentre tout portable, et des touche rapide pour que le tout soit 'usuability', on y remet donc logiquement des interfaces XUL. Bref, on croit faire comme java et .net, alors que ça n'a rien à voir, parce que là-dessous, on télécharge des XML de plus en plus gros, on interprète à la volée, on a un serveur énorme et on est dépendant du canal d'accès. (j'ai cherché une logique dans la derniere phrase mais sans succès, désolé)

Millstone != Applet pk??  
Applet application lourde pour le client et le serveur...
et Millstone c lèger!!!
 
Jsf permet de s'eloigner des complexités Jsp...  
 
.net c pas java et java pas .net pas pareil du tout ... pk C# ca fait tout même le micro ondes mais ca fait pas un truc sécuritaire et multiplateforme... Vive java
 
apres une réunion de travail ...:
#3 ingénieurs sortent des toilette pour ce laver les mains:
#Le premier de chez Microsoft: "Chez sosoft on nettoie a fond" dit-il en prenant pleins de papier pour s'essuiyer
#Le deuxième de chez hp: "dit chez HP on optimise tout au maximum" il prend juste une feuille et ce nettoie parfaitement
#Le troisième de chez sun: " Chez sun on ce pisse pas sur les mains"  
 
Syruis

super topic

J'espère que tout le monde va ce retrouver dans le topic... aussi je crois que XML c'est l'avenir alors pourquoi Sun livre til un Castor Bugué???
 
...

en quoi il livre un Castor bugué?

ils livrent un Castor 'castor est une api de parsage de XML' bugué