Discussion :

[bourboule]

Bonjour et bravo pour ce framework simple et puissant.

J'ai une problématique concernant la gestion d'une relation n:n.

Pour illuster le problème, prenons par exemple la relation Article -- Stock -- Magasin.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
-- -----------------------------------------------------
-- Table `ilmagbl1`.`Article`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `ilmagbl1`.`Article` ;
 
CREATE TABLE IF NOT EXISTS `ilmagbl1`.`Article` (
  `idArticle` INT NOT NULL AUTO_INCREMENT,
  `Nom` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`idArticle`))
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `ilmagbl1`.`Magasin`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `ilmagbl1`.`Magasin` ;
 
CREATE TABLE IF NOT EXISTS `ilmagbl1`.`Magasin` (
  `idMagasin` INT NOT NULL AUTO_INCREMENT,
  `Nom` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`idMagasin`))
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `ilmagbl1`.`Stock`
-- -----------------------------------------------------
DROP TABLE IF EXISTS `ilmagbl1`.`Stock` ;
 
CREATE TABLE IF NOT EXISTS `ilmagbl1`.`Stock` (
  `idStock` INT NOT NULL AUTO_INCREMENT,
  `idStockArticle` INT NOT NULL,
  `idStockMagasin` INT NOT NULL,
  `StockValeur` INT NOT NULL,
  PRIMARY KEY (`idStock`),
  INDEX `fk_article_idx` (`idStockArticle` ASC),
  INDEX `fk_magasin_idx` (`idStockMagasin` ASC),
  CONSTRAINT `fk_article`
    FOREIGN KEY (`idStockArticle`)
    REFERENCES `ilmagbl1`.`Article` (`idArticle`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_magasin`
    FOREIGN KEY (`idStockMagasin`)
    REFERENCES `ilmagbl1`.`Magasin` (`idMagasin`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

Je cherche à savoir comment structurer l'application.

1. Faut-il choisir un module CRUD pour Magasin et un pour Article, puis un module CRUD intégrable pour stock?
2. Faut-il créer un module GestionStock qui prendra en compte l'ensemble de la gestion des 3 tables?

Cette problématique de relation n:n mériterait je pense un petit tuto ou exemple pour bien comprendre la structure à appliquer.

Merci.

[imikado]

Pour information vous n'etes pas obligé de creer un CRUD pour chaque table, l'idée de la génération de module, dont le CRUD est pour faciliter le demarrage d'une application
C'est la meme chose pour les classes model, elles ne sont pas obligés de se cantonner à une table

Dans votre cas, vous pouvez partir sur une généation d'un module CRUD puis
- soit creer ensuite un module CRUD integrable et , justement l'integré dans la page d'affichage
- soit modifier le module CRUD pour ajouter

J'ai un tutoriel qui correspond un peu à cette problematique
http://mkframework.com/bigtutoriel_s...etwork_VI.html

Mais je vais voir pour faire un tuto / slides

[imikado]

Je viens d'écrire un petit tutoriel avec 2 tables, 2 modules CRUD un normal, l'autre intégrable

ça devrait vous aider à comprendre
http://mkframework.com/tutoriaux.htm...ndcrudembedded

[bourboule]

Merci beaucoup pour votre réactivité et la clareté du nouveau tuto qui m'est très utile.
Ce que vous faites est pro, créatif et pragmatique, bravo

[imikado]

Merci beaucoup pour votre message, j'essaie de donner envie d'utiliser ce framework peu connu

Bon courage pour la suite