Reprise du message précédent :
Je viens de trouver une API qui pourrait faire ce que je veux : http://joe.truemesh.com/squiggle/ (au moins pour les requêtes SELECT)
Si le lien peut permettre de mieux expliquer ce que je cherche et si vous en connaissez d'autres dans le même style, je suis preneur

bah JPA (avec Hibernate en tout cas) fait ça.
 
Tu fais le mapping d'une class, tu lui dis de créé les tables au démarrage du context hibernate.
Pour les remplir, tu prend tes objets java, tu fais des save dessus.
Pour les interroger, tu as des getter sur identifiant ou tu fais tes requêtes en HQL. ou via Criteria.

ORM, genre Hibernate ou iBATIS

Bon bah je crois qu'en fait je n'en savais pas assez sur Hibernate. Je vais aller fouiller ça et vos autres propals, merci à tous

edit : Comme de par hasard, il faut que hibernate.org soit en maintenance

y'en a une dans hibernate, j'ai plus son nom.

L'API Criteria, a priori.
 
J'étais complètement à côté de la plaque sur Hibernate, j'avais trop la vision EJB. Et les requêtes dynamiques telles que je les veux n'existent pas en EJB (... enfin, si je ne m'abuse ). Du coup je me suis lancé dans Hibernate
 
Par contre, d'après ce que j'ai pu constater, une telle requête dans Hibernate débute forcément par un:

Donc ça ne marche visiblement que sur ce qui est mappé (à moins de passer par du mappage dynamique mais je n'en suis pas encore là). Pas tout à fait ce que je désirais mais dans un premier temps ça me suffira amplement et ça me permettra de me familiariser avec Hibernate. Et puis entre ça et un Squiggle-like, je devrais pouvoir trouver mon bonheur

Sun est finalement rachetée par Oracle !!! (au lieu de IBM)
 
http://www.lesechos.fr/info/highte [...] ollars.htm
 
Est-ce mieux? Moins bien? On verra dans les mois qui viennent (la pérénité de glassfish, netbeans, mysql est un peu plus assurée selon moi).

Je vois pas pourquoi MysqlAB serait un peut plus rassuré puisqu'il y a OracleExpress qui pourrait y mettre un coup de balais.

Oracle XE c'est pas mal limité... c'est plutôt une version d'éval d'Oracle.

Un peut comme SQlServer Express.

'tain je quitte la France 2 semaines et c'est le bordel quand je reviens

C'est un débat qui a dû déjà avoir lieu ici, même si j'ai pas trouvé grand chose : match Swing vs SWT/jFace.
 
La cible est un client lourd sur plateforme WinXP (et ça sera toujours du WinXP, du moins pendant encore un bon moment). Pas de grosses contraintes (notamment au niveau de Java, on peut directement taper sur du 1.6), on part de rien, on est une petite équipe donc si c'est intéressant, on peut se former au fur et à mesure. Si ça vaut le coup, c'est là que je prend vos avis.

Alors je parierais sur SWT, non pas parce que ses layout managers sont meilleur que ceux de Swing (ca c'est plus une guerre de religion), mais plutot parce que tu auras les widgets natifs, et que, perturber le moins possible l'utilisateur en changeant une n-ieme fois de GUI, ca n'a pas de prix.

gizmo> +1 pour les perturbations puisqu'un simple courant d'air peut en perturber certains mais par contre, à part les "Open", "Save" et "Print"... de notre côté, on ne sort pas trop de leurs habitudes (avec le bon laf évidemment)
 
mais c'est dépendant du business à résoudre...
 
LeRiton> Si vous partez de zéro, je suppose que vous aurez tous le même IDE (que ce soit pour Swing ou SWT) ? car les fichiers design UI des IDE ne sont pas partageables entre IDE évidemment.
 
Vous comptez partir d'un RCP (Eclipse RCP, NetBeans RCP,...) ou vous faites votre propre container global ? car cela va résoudre certains choix technos à faire (mais cela va en apporter d'autres si vous n'arrivez pas à suivre les mises à jour du container choisi)

Ne pas oublier aussi que Swing est natif à la JVM, contrairement à SWT qui rajoute une dépendance non négligeable (qques Mo de JAR mais surtout une lib native en fonction de l'OS ciblé ; dans le cas de WinXP, une DLL de qques centaines de Ko je crois).

Perso j'aimais bien SWT quand j'en faisais (devs persos) et comme dit gizmo, tu restes avec le L&F de ton OS, ce qui permet une bonne intégration. Enfin c'est mon point de vue.

 
L'intégration par la gueule des widgets c'est un peu une illusion. Les programmes java codés par des windowsiens, quand t'es sous OSX ou nux, tu sens bien qu'ils sont pas chez eux, t'as des menu là ou il faudrait pas, des machins étrangement pas resizables, des combobox qui réagissent pas comme il faut, etc...

C'est deux problèmes différents Je veux dire, c'est pas parce que ton soft a ou n'a pas le même L&F que ton OS que le soft sera ergonomique ; je dis juste que c'est plus attractif et visuellement plus confortable. Je préfère par exemple avoir un widget de sélection de fichiers qui utilise le composant Windows plutôt que celui de Java/Swing ; je m'y repère mieux, etc...
C'est un plus, mais certainement pas une solution à tous les problèmes d'ergo qu'on peut rencontrer dans beaucoup de softs

 
Je parlais pas spécifiquement d'ergo en fait. Mais par exemple, si un soft "portable" met le menu de son appli directement dans la fenêtre, même s'il utilise les widgets d'OSX pour ça, il aura pas l'air natif. Le menu doit aller dans la barre en haut sous OSX. Ça corresponds à de l'ergo pour le coté respect de la cohérence, mais sous ce même principe de cohérence, tu va pas créer une petite fenêtre avec ton menu à part sous windows. L'ergo dicte de faire 2 choses différentes selon l'os, pas de faire une chose précise.
 
Si tu veut faire une bonne ergo bien intégrée, il faut faire une interface par OS, mais ça coûte du temps et donc des sous Tu peut minimiser en mettant en commun des modèles, voir en faisant des méga-widgets réutilisables qui représentent un paneau entier de l'appi (dans ce dernier cas, il te faut un tk caméléon). SWT peut aider à faire du portable, mais pas simplement en faisant tournée la même interface avec 3 skins différentes.

Je vote pour Swing aussi !

0x90 > Je suis d'accord avec ton argumentation sur le plan general, mais vu l'enonce de la question (XP only), je ne suis pas sur que cela soit aussi tellement pertinent.

moi je vote swing parce que je déteste SWT, eclipse, IBM et à peut près 99% du reste de la terre entière.

 
Effectivement, toute l'équipe a le même IDE (Eclipse en l'occurrence). Et on fait notre propre container.
 

 
Ça va jouer aussi, effectivement, vu que c'est du webstart.
 

 
T'as des raisons que tu peux détailler là dessus, ou c'est juste épidermique ?
 
Merci à tous pour vos retours. le petite dérive sur l'ergonomie en fonction de l'OS n'est pas inintéressante non plus.
 

l'amour et la haine ça ne se justifie pas, ça déplace des montagne ou ça tue des milliers de gens sans la moindre once de rationalité, c'est comme une démarche artistique.
 

J'aime ni le cirque, ni la télé, je pourrais jamais choisir entre Swing et AWT  
 

bof je pense qu'un des avantages de swing c'est que c'est du java donc on peut mater presque tout le code source, quand on capte rien à ce qui se passe ou qu'on veut pomper une idée.
 
je mets 'presque' parce que le code source de certains laf c'est relou à aller voir.

LeRiton> Si vous faites votre propre container et que c'est du webstart, personnellement j'irais au plus simple question déploiement, dépendances, ... -> Swing
Avec des outils comme NetBeans (Matisse) ou IntelliJ, ça devient plus facile de faire des trucs un peu plus couillus.
Par contre, au niveau JWS, NetBeans a fait un pas en avant mais il en reste encore une dizaine à faire pour que les déploiements soient vraiment faciles (certificats, drivers DB, ...)

Mais pour être honnête, il faudrait comparer avec ce qu'Eclipse est devenu au niveau génération GUI et au déploiement JWS de SWT (qui était à la manno quand j'ai testé).

Et du côté de IntelliJ Idea, je n'ai pas testé les déploiements JWS mais au niveau génération de Swing c'était pas mal du tout.

 
Anéfé, j'ai un peu dérivé sur ce que disait Taiche

Genre c'est ma faute

ben oui

la déresponsabilisation, c'est ça le moteur de la crise

Sinon, si c'est pour faire du JWS, y a aussi Griffon qui propose le deploiement JWS en une etape, et qui dispose des builders pour SWT et Swing

perso j'ai jamais vu une ui swt qui semble native/naturelle
(bon apres à part eclipse et vuze, j'ai pas grand chose a tester)
 
(et responsive )

Je vote SWT également, pour avoir fait plus quasiment autant l'un que l'autre (c'est à dire ... pas beaucoup) j'ai préféré SWT. Mais bon après j'ai pas trop trop d'arguments pertinents, on aime ou on aime pas

Et il y a des trucs comme le glisser déposer ou simplement le copier-coller inter applications qu'on aimerait bien voir fonctionner sur tous les environnements, et c'est rarement le cas.

ouais

Pour infos, on est parti sur Swing, surtout parce que je n'ai pas trouvé de réel gain a passer à SWT (et qu'SWT me rajoute des dépendances).
 
Edit : je fais quand même le détail de ce que j'ai ressorti du débat. Ce n'est applicable que dans mon contexte, à savoir OS fixe Win XP, environnement de dev Eclipse, déploiement en webstart.
 
Swing :
+ on connait (mais ce n'est pas déterminant, une période d'apprentissage était possible en cas de switch)
+ natif JRE
+ pas de dépendances supplémentaires
(je ne note pas les points d'indépendances à l'OS, ça ne nous concerne pas)
- look ?
 
SWT:
+ look ?
+ certains composants JFace qui semblent intéressants (mais là encore, on ajoute une dépendance à JFace en plus du reste)
+ intégration plus poussée à Eclipse
- poids des dépendances
- apprentissage nécessaire

Means OSEF ou epic win