j'ai corrigé merci :ccool:
Maintenant je peux commencer a mettre mes tables dans ma base
pour information j'utilise mysql!!!
Version imprimable
j'ai corrigé merci :ccool:
Maintenant je peux commencer a mettre mes tables dans ma base
pour information j'utilise mysql!!!
Bon, quand tu auras avancé sur la structuration,
je te recommande de t'exercer à faire un écran (JFrame) pour saisir la liste des fabricants.
Cet écran doit être de type CRUD :
Create .... ajout
Retrieve .. recherche
Update ... modification
Delete ... suppression
Composer l'écran n'est pas compliqué.
Il faut aussi transmettre les données à MySQL en utilisant JDBC (qui reste le moyen le plus simple).
As-tu quelques notions du langage SQL ?
oui c'est bon pour sql!!!
donc je peux le faire avec JEE??j'ai quelques notions la dessus!!
oubien j'utilise swing??
Swing est plus simple. Combien d'utilisateurs prévus ?
J2EE inclue J2SE (donc Swing) !
Il n'est pas rare de voir un FrontOffice (partie client) en client léger (web) et un BackOffice (partie administration) en client lourd.
Si tu développes une application lourde en Swing prend bien connaissance d'un concept : Event Dispatch Thread. Swing n'est pas fait pour le multithreading (quoi ? Horreur !). Rassures-toi un peu de bonne pratique est là pour corriger le problème.
Swing gère les "événements" dans une queue (file en bon français) et offre :
- SwingUtilities.invokeLater(Runnable)
- SwingUtilities.invokeAndWait(Runnable).
- SwingUtilities.isEventDispatchThread()
- SwingWorker
La première méthode permet d'ajouter un "événement" dans la file et de l'exécuter quand Swing aura le temps (asynchrone).
La seconde permet d'ajouter un "événement" dans la file et d'attendre que Swing l'exécute (synchrone).
La troisième permet de savoir si t'es dans l'EDT ce qui permet d'invoquer conditionnellement ton code.
Enfin la classe SwingWorker permet d'alléger un peu la gestion de l'EDT, des barres de progression et des traitements longs. Je te laisse consulter la javadoc pour plus de détails et reviens si tu as des questions. Attention, tu dois créer une nouvelle instance à chaque fois que tu utilises cette classe.
Voilà pour l'API maintenant les bonnes pratiques :
- Modifie les composants et les modèles uniquement dans l'EDT
- Effectue tout traitement un peu long en dehors de l'EDT
Le premier point permet d'éviter des accès / modifications concurrentes. Par exemple, ton modèle dit à Swing que ces informations ont changées, Swing demande donc les informations à jour du modèle et commence à travailler sur cette base, si tu modifies le modèle entre temps tu risques d'avoir des OutOfBoundException ou autre NullPointerException ...
Le second point permet d'éviter le blocage de l'IHM, tant que l'EDT est occupé à faire ton traitement il ne gère plus les événements IHM. En vrai l'IHM n'est pas nécessairement bloqué car dans certains cas Swing va gérer un pool de thread pour traiter la queue. Mais tu en auras nécessairement une partie de bloquer.
Je te conseille fortement d'avoir une série de classe utilitaire pour gérer cette problématique. Sur certains projets, j'utilise des "tâches" qui sont typés IHM et non IHM ainsi qu'un attribut "synchrone". Je colle mes tâches dans une macro tâche (liste de "tâche") attaché à un pool de thread "applicatif". La macro tâche se charge alors de faire les appels synchrones ou non de chaque tâche soit dans l'EDT (pour les tâches IHM), soit dans le pool de thread "applicatif" pour les autres.
Enfin petit snippet à coller dans une classe utilitaire :
Je te laisse gérer les exceptions comme tu l'entends ;-)Code:
2
3
4
5
6
7
8
9
PS : Il existe deux articles sur les problèmes Swing mais j'ai la flemme de les chercher :) Ils datent de fin 2010 début 2011.
Est-il necessaire d'utiliser des thread?c'est un peu compliqué!!!
Tu seras obligé d'utiliser des thread si tu travailles avec Swing sous peine de lourdeur, de latence, d'IHM buggé, etc. Enfin tout les problèmes évoqués.
En soit il n'y a pas grand chose de bien compliqué si tu centralises tes appels et que tu fais pas de truc funky :)
invokeAndWait?Citation:
Envoyé par Nemek
Vraiment?
Tu ne voulais pas plutôt utiliser invokeLater?
Quant aux tutos dont il était question les voici:
Gestion de l'interaction EDT/Threads: http://gfx.developpez.com/tutoriel/j...ing-threading/
Une classe permettant de se simplifier la vie, le SwingWorker: http://rom.developpez.com/java-swingworker/
Le principe de ce snippet c'est d'exécuter les appels en synchrone donc si tu fais invokeLater t'es mort :x
Si tu fais des actions asynchrones autant utiliser constamment invokeLater.
EDIT : Merci pour les liens ! J'ai parcouru un autre article sur AWT/Swing. Je vais essayer de chercher le lien :)
Dans un premier temps, il n'est pas du tout nécessaire d'utiliser des threads.Citation:
Envoyé par grfall
D'après les spécifications de ton projet, on peut parfaitement le construire avec des écrans JFrame (swing)
qui iront chercher les données dans MySQL sans recourir aux threads (je le fais depuis des années).
Pour que ton projet réussisse, il faut viser la simplicité.
En revanche, pour bien choisir la façon de développer, il faut nous dire :
- le nombre d'utilisateurs concernés
- si les utilisateurs seront sur un réseau local ou des sites différents (application internet dans ce cas)
Tu es utilisateur de ton application pour en être sûr ? :pastaper:
Franchement je partirai dans un premier temps sur du full SwingWorker. Car si la base de données "plante" tu pars en timeout et pendant ce temps l'IHM est bloquée, si ta base de données n'est pas sur la même machine (fort probable) si tu as une latence réseau ou une charge du serveur l'IHM est bloquée, si les connexions sont "poolés" (les SGBD le gère souvent eux même) tu peux te retrouver en attente, tu peux avoir des locks avec wait sur des éléments de ta base de données, etc.
Et on ne parle que de l'utilisation de la base de données !
Je parle bien de dizaines d’applications différentes installées sur des chaînes de production (24h/24h)
ainsi que des applications de gestion et de statistiques chez des PME entre 30 et 300 personnes
Les bases de données sont aussi bien du SQL Server que du MySQL
... et ça fonctionne depuis des années comme ça.
@Nemek je ne dis pas que ce que tu exposes est faux ou sans intérêt.
Je dis que si on veut que grfall y arrive, il faut éviter de le noyer dès le départ.
Il n'a que 2 mois et il est débutant on doit donc lui montrer le plus court chemin pour qu'il y arrive.
Au vu de son application, on peut faire des choses simples quitte à optimiser après.
Je maintiens une application codée avec les pieds par des stagiaires à qui on a pas pris le temps 5min de leur expliquer le Java (Je crois que j'en ai parlé dans un message précédent du même sujet).Citation:
Envoyé par Népomucène
Ca marche plutôt bien depuis des années, on arrive même à faire évoluer l'application sans trop de "pertes" ... Seulement quand on l'utilise sérieusement on se rend compte qu'il y a plein de trucs qui marchent à moitié. Et qu'on compte chaque jour environ 1-2Mo de "NPE stacktrace" dans les logs de production ...
Et on ne traite aucun point support relatif à un bug et chaque évolution est "iso-buggée".
Qu'il fasse avec ou sans SwingWorker ca changera qu'une chose dans un cas il aura moins d'emmerde à débugger des stacktrace de ce genre :
PS : j'ai trouvé le lien que je cherchais "Pièges communs en Swing"Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Les utilisateurs sont plus de 40,et on travail localement pour le moment car l'entreprise prevoi de deployer l'application sur d'autres sites mais plutard...Citation:
Envoyé par Népomucène
OK pas de problème.
Il faudra soigner le choix des index dans MySql pour avoir un temps de réponse correct.
Les 40 utilisateurs pour cette application vont tous faire de la saisie d'équipements et d'interventions de maintenance ?
Ce sont peut-être les techniciens qui enregistrent leurs interventions ?
Par contre, je change mon point de vue sur Java Web Start.
Si tu as 30 - 50 postes à équiper, on ne pourra pas en faire l'économie.
C'est un aspect du développement qu'il faudra ajouter au projet dès qu'il sera suffisamment avancé.
Ok on verra donc a la suite!!!!
j'ai commencé la structuration,si je termine tot je pourrai faire l'ecran pour les fabricants(CRUD).
En ce qui concerne la structuration,
on est bien d'accord qu'il manque beaucoup de champs (dans les interventions notamment).
On les ajoutera par la suite lorsque tu seras au point sur le système des écrans CRUD.
Il faut avant tout être à l'aise dans les types de données les plus répandues en informatique de gestion.
Je fais ici une liste des cas que tu auras forcément à traiter :
- Texte (nom, adresse, code postal, téléphone ...) j'ai eu un étudiant qui m'avait mis le téléphone en numérique :aie:
- Pourcentage (TVA, commissions, ...)
- Monétaire
- Quantités (nombre entier ou décimaux)
- Date
Chacun de ces cas a ses pièges spécifiques.
Dans ta table des fabricants, essaye de mettre au moins un cas de chaque, même si c'est un peu artificiel.
Une fois que tu maîtrise cette liste alors tu seras le maître du monde :mrgreen:
dans la table fabricant j'ai ajouté
email de type varchar
tel de type varchar
et aussi
adresse de type varchar...
Il faut aussi y mettre [Contact] varchar(50) pour adresser un courrier ...
Bon, on verra pour les autres types de données.
Quel EDI utilises-tu pour programmer en java ?
Si tu n'as pas encore fait ton choix, je te recommande NetBeans
qui fait gagner un temps fou pour composer des écrans
ok je vais ajouter contact.
heum j'utilisai eclipse,mais bon je vais prendre net beans donc c'est bon!!!