[sf 1.2.x] nestedSet sur lui-même ? [Résolu]

[optiloose]

Bonjour a tous,

Je dois mettre en place un NestedSet dans symfony, pour une arborescence. J'ai donc trouvé des tutos très bien faits, mais ou se pose une question...

En clair, je voudrais pouvoir lier les éléments (type de documents officiels) de ma table entre eux...
Le nestedSet me permet il de faire cela, ou suis je absolument obligé de le lier a des entités externes ?

Exemple : justificatif de domicile aurait pour enfant 1-facture EDF , 2 -facture GDF , 3 - facture france telecom etc.

Ma question dans mon exemple, mon justificatif de domicile peut il etre parent de mes types de document , ou alors doit il se trouver dans une table extérieure par exemple "categories" ?

J'espere que vous aurez compris ma question

[Herode]

Le comportement NestedSet permet de déclarer une table comme étant une arborescence, donc oui : il lie entre eux les éléments de la table (avec une relation 1-n : 1 parent a n enfants).

Mais...

Ma question dans mon exemple, mon justificatif de domicile peut il etre parent de mes types de document , ou alors doit il se trouver dans une table extérieure par exemple "categories" ?

... demande à être éclairci. D'après ce que je comprends de ton message : si "Justificatif de domicile" est un document à part entière, il doit figurer dans la table document indépendamment du fait qu'il ait ou non des enfants, et NestedSet permet de hiérarchiser la table. Si "Justificatif de domicile" est un qualifiant, alors
- si c'est le seul qualifiant, un champ booleen ajouté à la table fait l'affaire
- s'il y a plusieurs qualifiants, une table externe & une clé étrangère sont requis.

[optiloose]

Merci de ta réponse

Je vais schematiser tout ce que j'attends de mon nestedSet

Possibilité 1

Code :

1
2
3
4
5
 
//dans ce cas ce sont des documents
- facture EDF
- carte d identité
- passeport

Possibilité 2

Code :

1
2
3
4
5
6
7
8
9
 
//avec categories
-justificatif de domicile // categorie 1
-- facture EDF
-- facture France Telecom
- pieces d identité
-- Carte d identité
-- Permis de conduire
-- Passeport

Possibilité 3

Code :

1
2
3
4
5
6
7
8
9
10
 
- Acte de Naissance // c'est un document
- Acte de Décès
- justificatif de domicile //c'est une catégorie
-- facture EDF // c'est un document
-- facture France Telecom
- pieces d identité //c'est une catégorie
-- Carte d identité
-- Permis de conduire
-- Passeport

Je pense que l'explication de ma problématique est plus claire maintenant

[Michel Rotta]

Et où mets-tu le nestedSet ?

Dans une table des documents possible, dans la table de stockage des documents, dans les deux ?

[optiloose]

En fait, mes documents servent simplement a qualifier des fichiers que l'utilisateur doit uploader. Ce sont des types de document, non pas des documents en tant que tel.

Fichier 1 est de type carte d'identité.
fichier 2 une de type facture edf

C'est plus clair comme ca ?

[Michel Rotta]

C'est pire.

Tu as un fichier par type de document !!!

Ceci ne va pas faciliter ton traitement.

As-tu une petite idée du schéma que tu aimerais mettre en place ?

[optiloose]

J'explique le processus :

Un utilisateur effectue ce qu'on appelle une teleprocédure : par exemple , inscription scolaire.

Pour pouvoir s'inscrire a l'ecole , l'utilisateur peut uploader des fichiers ( word , pdf , image etc.)

Lors de l'envoi des documents, il peut les qualifier , par exemple
fichier 1 = certificat de scolarité ,
fichier 2 : piece d'identité

Je veux en clair , pouvoir organiser mes "types de documents" comme je le veux (cf explication d'un post précédent)

[Michel Rotta]

Je vais tenter de reformuler.

Tu veux gérer des demandes administratives. Pour ces demandes, les personnes qui les font doivent fournir certains justificatifs. Pour un justificatif donné, il y a de 1 à n documents qui peuvent et/ou doivent être fourni.

A mon avis, il te faut quatre tables :

• type de demande
• catégorie de documents
• liste des documents par catégorie
• Liaison n-n entre type de demande et catégorie de documents

Je ne vois pas, ici, l'intérêt d'un arbre dans les documents.

[optiloose]

je dois mal m'exprimer

Les types de documents doivent etre administrables en backend.

Dans le backend, ces types de documents peuvent etre triés en catégories distinctes. D'ou le nestedSet

On doit pouvoir créer une catégorie , ou un document , et pouvoir rattacher un document a une catégorie.

Par exemple, on doit pouvoir obtenir ca

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
-documents officiels           //categorie 
--identité                         // sous categorie
---carte d identite             // document
---passeport
--filiation
---acte de naissance
---livret de famille
-documents médicaux        //categorie
-- ordonnance                  //document
-- carnet de santé
 
etc...

[Michel Rotta]

Le problème est que tu veux gérer deux choses différentes dans une même table. Dans ton exemple tu as des documents et des catégories de documents.

Tu peux éventuellement adapter ma proposition précédente en changeant la table catégorie en y insérant la notion d'arbre.

Cependant, gérer un arbre pour ce type de table et d'exploitation me semble inutilement compliqué deux catégories imbriquées (catégorie principale, catégorie secondaire) devraient permettre de résoudre la majorité des cas non ?

[optiloose]

Et donc je devrais me limiter a deux niveaux a ce moment la ?
Or dans mon cahier des charges, je dois pouvoir organiser mes types de documents sur x arborescences...

Je sens que j'ai pas fini d'en ...

En tous cas merci de ton aide

[Michel Rotta]

C'est une solution de facilité.

Si tu as à en gérer n niveaux, il faut en passer par une table catégorie avec un multi arbre.

Ceci va juste être plus lourd à gérer et à afficher. Mais avec Doctrine, la gestion des arbres est largement simplifiée. Par contre, je garderais les documents en dehors de la gestion des catégories, les tables n'ayant pas les mêmes champs. Et j'essayerais de gérer tous les types de documents dans une seule table.

[optiloose]

Ok, merci Michel pour tes conseils