Bonjour à tous,
 
Venant du monde Java et utilisant SWING, je cherche un équivalent au Tablemodel/Jtable pour une Datagrid ou composant grille équivalent.
 
Je trouve le data binding des datagrids peu objet contrairement aux TableModel éxistant en SWING ou l'on crée soit même le mapping.
 
Auriez vous des conseils à me donner ? Peut être n'aie-je pas compris la manière de fonctionner mais pour ma part je trouve laid le fait de mapper directement une vue base de données sur un objet GUI via un Dataset ou autre.
 
Je cherche donc une sous couche (KLOUG) permettant de s'interfacer avec la couche GUI.
 
Je vous remercie d'avance.

Dans un DataGrid, tu lui balance un truc qui implémente l'interface IList ou IListSource, et ça lui plaira Et sinon le contrôle est entièrement conigurable comme c'est pas possible, voit dans la MSDN

 
Merci.
J'y avais pensé effectivement en regardant la msdn, cependant le peu d'information sur l'implémentation de ces interfaces m'ont découragé.
 
N'aurais tu pas un exemple s'il te plait ?
 
Merci encore,
 
++

C'est quoi que tu veux faire exactement ? Quel gueule aura le truc intermédiaire ?

 
En gros,
j'aimerais gèrer une collection d'objets métiers dans cette couche qui aurait des methodes similaires aux TableModel java, par exemple :
- Type getColumnType()
- int getColumnCount()
- String getColumnName(int column)
- Object getValueAt(int rowIndex, int columnIndex)
 
Merci de ton aide.

Ah oui, j'me rappelle vaguement de tout ça... Comme dit, on peut faire moutlt chose avec le DataGrid. Genre mettre une ListBox dans une case, choisir un nom de colonne, etc...

 
Ton message est justement la chose que j'aimerais éviter :
 - Le GUI ne doit s'occuper que d'afficher génériquement des objets
 - Le fait d'avoir une listbox dans une case n'est juste qu'un problème de rendu et n'a pas grand chose à voir avec ma demande.
 
Ce n'est pas un problème de rendu mais juste de séparation des couches. J'aimerais un objet (implémentant certainement IList) possèdant le genre de méthodes citées plus haut dans le but de bien séparer les couches et que mon GUI (une datagrid par exemple) ne soit pas en lien direct avec ma base de données mais plutôt avec cette couche contenant une collection d'objets métiers.
 
Voilà.

Mouais Personnellement, j'utiliserais un DataView... Faut pas vouloir trop séparer Sinon tu risques de te faire bien chier pour répercuter les mises à jour vers la BD

 
Le fait de vouloir séparer ton GUI de ta base de données est quand même beaucoup plus propre.
C'est beaucoup plus évident de travailler avec de vrais objets métiers plutôt que de laisser gèrer ton GUI derrière.

Ca dépend. Le DataView est par exemple prévu justement pour être entre ta BD et ta GUI.

 
C'est très moche en tout cas, d'autant plus que tu ne maîtrises rien et que pour des schémas un peu complexe comme j'ai le cas actuellement (imbrication d'objets métiers les uns dans les autres par exemple), tout tombe à l'eau. Lorsque je sélectionne un élément dans la datagrid, je veux pouvoir travailler sur un objet métier (type Client par exemple). Avec une dataview tu es obligé de refaire le binding objet, n'est ce pas M
 
Je veux juste savoir si quelqu'un a déjà essayé d'implémenter cette couche IList ou IListSource et s'il est possible de me donner un exemple.
 
Merci d'avance.

Aurait-tu un peu plus de détails sur la tronche de ta BD ?

Là n'est pas le problème, je te remercie de t'intéresser à la problématique
 
Ayant l'habitude de travailler avec des TableModel en Java et trouvant qu'il est beaucoup plus confortable de jouer avec des objets, je veux juste savoir s'il éxiste l'équivalent (à priori oui) et comment l'implémenter.
 
Merci.

En fait le problème c'est que j'avais utilisé des TableModel en Java, mais y'a 3 ans, alors j'me rappelle plus

Si qqun d'autre peut m'aider

Donc en gros, si j'me rappelle bien, TableModel permet de renseigner sur le type de colonne, son nom, le nombre de colonnes dans l'objet, et de récupérer la valeur d'une case ?

 
C'est vite résumé mais cela fait partie effectivement de ses fonctions. Il permet de mieux gèrer et manipuler les collections d'objets. Quand on parle de Type, c'est le Type de la données et non le Type de sa représentation graphique (qui en Java est effectué par un Renderer).
 

Ok je vois. Ben je soutient encore l'utilisation de Dataset/table/view, vu qu'ils sont prévus pour ça (et ne sont pas directement liés à la BD physique)

Une piste ici
http://noiseehc.freeweb.hu/IListSource.html
 
Je connais très bien le Dataset mais je veux un objet plus générique pour un schéma complexe que le Dataset ne peut résoudre.

C'est tellement complexe ? Y'a des imbrications ?

Oui pas mal d'imbrication nécessitant un traitement spécifique.

Voici grosso modo l'architecture que tu dois utiliser.
Le DataGrid s'occupe du rendu (remplacement de clé étrangère par les libellés, affichage de date "jolies", etc ...)
Tu lui donnes à manger un DataView, qui s'occupe de certaines fonctionnalité (trie, filtre, etc ...)
Tu donnes à manger au DataView un DataSource qui lui correspond au mapping de ta(tes) table(s) en base.
 
Si tu veux plus de précisions, n'hésite pas

Ca je pense qu'il le sait déjà

Autant pour moi alors !

Faut juste arriver à lui faire piger que les DataSet sont parfaits commme business object