$HTTP_POST_VARS

Stephane Thomas wrote:

Bonjour,

Je dois réaliser une interface en php pour la consultation d'un manuel
qualité hébergé sur un serveur de fichiers Netware. J'utilise une base
MySQL pour stocker les propriétés des fichiers (service concerné, date
d'application, chemin sur le serveur de fichier, etc...)
[snip..]

Pour être plus clair, mettons que mon administrateur (client windows) du
manual qualité ai acces à ce manuel sous Q: je souhaiterais que
l'utilisateur puisse parcourir Q: afin de trouver le fichier qui
l'interesse et que le nom de ce fichier (et son chemin) puissent être
récupérés pour être utilisé comme valeur dans le champ
"chemin_du_fichier_sur_le_serveur" de ma table MySQL.

Bonjour,
Vu sous l'angle purement web, pour des raisons de sécurité, il n'est pas
possible de récupérer le chemin absolu du fichier directement depuis le
navigateur (à moins de passer par une applet coté client).
* Sous l'angle qualité maintenant :
par rapport à la maîtrise des documents, c'est une mauvaise idée d'avoir
d'une part un référentiel sous la forme d'un serveur de fichier, et de
stocker dans une base extérieure les chemins absolus vers les documents en
laissant l'utilisateur 'choisir' ce chemin. (vous ne pouvez pas être sur
qu'il ne puisse pas de toute manière le modifier à la main).
C'est complètement en boucle ouverte (et il peut se passer n'importe quoi
sur l'une ou l'autre partie)
Du point de vue d'un auditeur externe, rien ne prouve que les métadonnée
(dans la base) et le document qu'elles sont censées décrire sur le serveur
de fichier soient en phase.
* il serait préférable que le lieu de stockage du document ne soit pas sous
la maitrise du rédacteur ou mainteneur, mais du ressort de l'application
d'archivage (elle-meme en php/mysql).
Le responsable du document uploade celui-ci depuis son navigateur lorsqu'il
s'agit d'archiver une version validée.
Vous pouvez toujours utiliser votre serveur de fichier pour les versions
draft des documents pour lesquels il n'est pas nécessaire d'avoir un suivi
des versions.
Que le document final, validé soit ensuite stocké directement dans un blob
de la base, ou sous forme de fichier devient secondaire.
Cela revient à construire un mini-système de gestion documentaire,auquel on
peut même ajouter une gestion simpliste du cycle de vie dans un champ de la
bdd, avec rapatriement du document en version N, livraison du N+1 à l'état
draft, validation par l'autorité qui va bien, toutes choses pour lesquelles
une bdd peut rendre de grands services.
D'un point de vue A.Q il est plus aisé d'en démontrer la maitrise.
Par ailleurs, d'un point de vue technique c'est plus intéressant à
développer (mais ce n'est peut être pas la considération principale de
votre donneur d'ordre ;-)
Cordialement
Pascal

Bonjour,

Merci de votre réponse extrêmement intéressante. Je me permet de
continuer cette discussion qui je n'en doute pas sera très enrichissante
pour moi.

Vu sous l'angle purement web, pour des raisons de sécurité, il n'est pas
possible de récupérer le chemin absolu du fichier directement depuis le
navigateur (à moins de passer par une applet coté client).

Ca j'ai saisi

* Sous l'angle qualité maintenant :
par rapport à la maîtrise des documents, c'est une mauvaise idée d'avoir
d'une part un référentiel sous la forme d'un serveur de fichier, et de
stocker dans une base extérieure les chemins absolus vers les documents en
laissant l'utilisateur 'choisir' ce chemin. (vous ne pouvez pas être sur
qu'il ne puisse pas de toute manière le modifier à la main).
C'est complètement en boucle ouverte (et il peut se passer n'importe quoi
sur l'une ou l'autre partie)
Du point de vue d'un auditeur externe, rien ne prouve que les métadonnée
(dans la base) et le document qu'elles sont censées décrire sur le serveur
de fichier soient en phase.

Tout à fait

* il serait préférable que le lieu de stockage du document ne soit pas sous
la maitrise du rédacteur ou mainteneur, mais du ressort de l'application
d'archivage (elle-meme en php/mysql).
Le responsable du document uploade celui-ci depuis son navigateur lorsqu'il
s'agit d'archiver une version validée.

Le mainteneneur travaillera directement sur le volume NetWare contenant
le manuel qualité, je n'ai pas l'impression que ce soit une bonne
solution cependant cela m'est imposé. Je n'ai jamais travaillé avec
Netware cependant en "mountant" un lecteur Netware sur un point de
montage de mon serveur web je pense qu'on peut faire comme si on
travaillait avec des fichiers locaux (résidant sur le serveur web).

Vous pouvez toujours utiliser votre serveur de fichier pour les versions
draft des documents pour lesquels il n'est pas nécessaire d'avoir un suivi
des versions.

Pas de suivi de version nécessaire, les utilisateurs n'auront accès qu'à
la derniere version disponible.

Que le document final, validé soit ensuite stocké directement dans un blob
de la base, ou sous forme de fichier devient secondaire.

Pas non plus de validation des documents ou de gestion du cycle de vie
(pas de workflow). En fait un document est considéré comme validé dès
l'instant où il se trouve sur le serveur de fichiers.

D'un point de vue A.Q il est plus aisé d'en démontrer la maitrise.
Par ailleurs, d'un point de vue technique c'est plus intéressant à
développer (mais ce n'est peut être pas la considération principale de
votre donneur d'ordre ;-)

Le problème de mon donneur d'ordre est le suivant :

- Pas de fichiers en local, tous les documents de l'entreprise (donc
le manuel qualité) sont stockés sur un serveur Netware 5.1.
- Les utilisateurs (salariés ayant un ordinateur connecté au réseau
local de l'entreprise) doivent pouvoir rechercher un document du manuel
qualité grâce à des mots-clés, des tris de colonnes, des critères
prédéfinis (services concernés, type de document, etc...).
- L'application doit proposer un lien hypertext pour chaque document,
permettant d'ouvrir ou de télécharger ce document.
- Le mainteneur du système d'assurance qualité peut ajouter/supprimer
des documents ainsi que modifier les méta-données (services concernés,
type de document, etc...) des documents.

Les solutions envisagées :

- Un fichier excel (simple, rapide, mon donneur d'ordre peut le faire
lui-même).
- Une application PHP/MySQL (impose un référentiel commun, accès
depuis n'importe quel navigateur web)
- Une application client/serveur développée avec WinDEV (là c'est pas
moi qui m'y collerai...)

Je me demande de plus en plus fortement si l'intégration d'une solution
existante (libre) de gestion documentaire ne serait pas une meilleur
solution.

Une autre idée me vient : Ne pourrait-on pas s'affranchir de
l'emplacement des fichiers en déterminant une nomenclature pour les noms
de fichiers qui permettrait que ces noms soient uniques. On pourrait
ainsi obtenir l'adresse cible du lien hypertext grâce à une construction
genre <?php exec ("find /manuel_qualité -name "XFRSD45.*",$out); ?>
Que pensez-vous de cette solution ?


Stéphane

Bonjour,

Re: $HTTP_POST_VARS

Pourquoi ce sujet au fait ? Je pense que « Gestion électronique de documents
(GED) en PHP » aurait été un peu plus explicite :).

JM

Bonjour,

Je dois réaliser une interface en php pour la consultation d'un manuel
qualité hébergé sur un serveur de fichiers Netware.

Quel serait le format du manuel ? HTML ?

Le lien entre les fichiers sur le serveur et la base MySQL se fait donc
par un champ "chemin_du_fichier_sur_le_serveur"

Il faut mieux oublier la notion du chemin et opter pour une logique
d'identifiant. Chaque document est identifié par un identifiant unique (clé
primaire de la table des documents) et à chaque identifiant est associé un
fichier nommé à partir de cet identifiant. Le document n°103 au format
OpenOffice.org (OO) par exemple se nommerait 103.sxw par exemple (.sxw est
l'extension d'un document OOo), de même le document n°7 au format PDF se
nommerait 7.pdf.

Je pensai pouvoir utiliser quelquechose comme <input type="file"
name="le_chemin_du_fichier"> mais le probleme est que dans

$HTTP_POST_FILES je n'ai que le nom du fichier et pas son chemin...

Aucune importante le document sera de toutes façons stockés sur le serveur
de documents. Peu importe le chemin d'origine.

je souhaiterais que
l'utilisateur puisse parcourir Q: afin de trouver le fichier qui

l'interesse et que le nom de ce fichier (et son chemin) puissent être
récupérés pour être utilisé comme valeur dans le champ
"chemin_du_fichier_sur_le_serveur" de ma table MySQL.

Il faut justement cacher la hiérarchie des documents. S'il s'agit de
proposer la consultation des documents, vous pouvez parfaitement opter pour
une présentation à la Exploreur. Le script PHP charger d'afficher la liste
des documents liste le contenu du dossier où sont stockés les documents, il
affiche une liste de liens dont les noms sont ceux des documents et dont les
URL sont ceux des noms des fichiers assocités à chaque document, en HTML :
<a href="103.sxw">Un document OpenOffice.org</a>...

En esperant être clair.

Avant de mettre en place un tel système il vaut mieux établir un cahier des
charges : fonctionnalités, types des documents... Après ca sera vraiment
plus clair pour tout le monde :).

JM

Jean-Marc Molina wrote:

Bonjour,

Je dois réaliser une interface en php pour la consultation d'un manuel

qualité hébergé sur un serveur de fichiers Netware.

Quel serait le format du manuel ? HTML ?

Formats .doc .pps, voir même du MS-Visio il me semble

Il faut mieux oublier la notion du chemin et opter pour une logique
d'identifiant. Chaque document est identifié par un identifiant unique (clé
primaire de la table des documents) et à chaque identifiant est associé un
fichier nommé à partir de cet identifiant. Le document n°103 au format
OpenOffice.org (OO) par exemple se nommerait 103.sxw par exemple (.sxw est
l'extension d'un document OOo), de même le document n°7 au format PDF se
nommerait 7.pdf.

J'ai pensé à cela aussi, ça me parait une bonne idée.

Cela voudrait donc dire 2 volumes Netware : un de travail et un autre
(monté sur le serveur web) ou sont stocké les fichiers nommés à partir
des identifiants. Seul le serveur web aurait accès à ce dernier volume.

Il faut justement cacher la hiérarchie des documents. S'il s'agit de
proposer la consultation des documents, vous pouvez parfaitement opter pour
une présentation à la Exploreur. Le script PHP charger d'afficher la liste
des documents liste le contenu du dossier où sont stockés les documents, il
affiche une liste de liens dont les noms sont ceux des documents et dont les
URL sont ceux des noms des fichiers assocités à chaque document, en HTML :
<a href="103.sxw">Un document OpenOffice.org</a>...

Pour celui qui consulte le manuel qualité les documents ne sont pas
hiérachisés. L'utilisateur utilise des filtres (mot-clés, type de
document, lieux d'application, etc...) et les résultats sont présentés
sous forme d'un tableau.

Avant de mettre en place un tel système il vaut mieux établir un cahier des
charges : fonctionnalités, types des documents... Après ca sera vraiment
plus clair pour tout le monde :).

La rédaction du cahier des charges est en cours, j'y participe, d'où mes
questions sur ce newsgroupe. Je posterai probablement ce cahier des
charges une fois fini afin que vous me donniez votre avis.

Stéphane

* Sous l'angle qualité maintenant :
par rapport à la maîtrise des documents, c'est une mauvaise idée d'avoir
d'une part un référentiel sous la forme d'un serveur de fichier, et de
stocker dans une base extérieure les chemins absolus vers les documents en
laissant l'utilisateur 'choisir' ce chemin. (vous ne pouvez pas être sur
qu'il ne puisse pas de toute manière le modifier à la main).
C'est complètement en boucle ouverte (et il peut se passer n'importe quoi
sur l'une ou l'autre partie)
Du point de vue d'un auditeur externe, rien ne prouve que les métadonnée
(dans la base) et le document qu'elles sont censées décrire sur le serveur
de fichier soient en phase.
* il serait préférable que le lieu de stockage du document ne soit pas sous
la maitrise du rédacteur ou mainteneur, mais du ressort de l'application
d'archivage (elle-meme en php/mysql).
Le responsable du document uploade celui-ci depuis son navigateur lorsqu'il
s'agit d'archiver une version validée.

Je ne comprend pas bien en quoi cela rêgle le problème de boucle
ouverte, l'utilisateur peut se tromper de fichier lors de l'upload
auquel cas il y aura une incohérence entre les fichiers et la base.

Amicalement,

Stéphane

Stephane Thomas wrote:

* Sous l'angle qualité maintenant :
[snip]

Je ne comprend pas bien en quoi cela rêgle le problème de boucle
ouverte, l'utilisateur peut se tromper de fichier lors de l'upload
auquel cas il y aura une incohérence entre les fichiers et la base.

Amicalement,

Stéphane

Quand je parle de boucle ouverte, c'est que le problème n'est pas tant que
l'utilsateur se trompe de fichier en le livrant, mais qu'il puisse aller
poser un fichier sur le serveur _sans_ avoir besoin de mettre à jour les
méta-données de la base.
Alors qu'en obligeant à passer par un upload, vous pouvez insérer tous les
traitements voulus dans la procédure de mise à jour de la base, avant que
votre script pose le fichier sur le serveur.
Attention : je ne veux pas dire qu'il ne faut pas faire confiance aux gens,
n'est ce pas ;-)
Amicalement
Pascal

Stephane Thomas wrote:

[snip]

Le mainteneneur travaillera directement sur le volume NetWare contenant
le manuel qualité, je n'ai pas l'impression que ce soit une bonne
solution cependant cela m'est imposé. Je n'ai jamais travaillé avec
Netware cependant en "mountant" un lecteur Netware sur un point de
montage de mon serveur web je pense qu'on peut faire comme si on
travaillait avec des fichiers locaux (résidant sur le serveur web).

Pas de suivi de version nécessaire, les utilisateurs n'auront accès qu'à
la derniere version disponible.

Pas non plus de validation des documents ou de gestion du cycle de vie
(pas de workflow). En fait un document est considéré comme validé dès
l'instant où il se trouve sur le serveur de fichiers.
[snip]

Bonjour,
je comprends un peu mieux la problématique maintenant.
Le besoin décrit n'est pas de maitriser les documents (on considère que la
maitrise, au sens A.Q du terme, est de la responsabilité du mainteneur du
document) mais d'indexer des documents qui sont de toutes manières
considérés comme valides à partir du moment ou ils sont sur votre serveur
netware, livrés par le mainteneur.

* tout repose donc sur le lien entre votre enregistrement dans la base et
l'attribution d'un nom au fichier par le mainteneur

* Donc c'est le mainteneur du document qui joue le rôle de générateur de clé
primaire pour l'identifier dans le S.I;-)
<digression>
Après, il est possible de rajouter des fonctionnalités de controle à
posteriori
* Ainsi que le disais Jean-Marc plus haut, cacher la hiérarchie des fichiers
aux utlisateurs est une bonne idée, et c'est là que votre 'explorateur web'
peut jouer 2 roles :
1 - délivrance d'une copie de consultation du documents (le lien cliquable
pour obtenir le doc passe par un script php qui gère l'accès au serveur de
fichiers)
2 - controle de cohérence : en stockant dans la base un checksum du document
et en le comparant avec celle que le script éxécute sur le document à
délivrer depuis le FS on peut "faire du controle" (cela empêche également
toute modification 'sauvage' du fichier, y compris par le mainteneur, sans
avoir au préalable demandé la création/modification de l'enregistrement
dans la base.
</digression>
Mais, je le répète,à partir du moment ou l'attibution de l'identifiant du
document est effectuée par un humain,la cohérence du système toute entière
repose simplement sur le respect d'une règle de nommage des documents par
celui-ci, et surtout sur le fait que l'utilisateur soit forcé de mettre à
jour la base lorsqu'il livre un nouveau fichier.
Cordialement
Pascal

Bonjour Stéphane,

Cela voudrait donc dire 2 volumes Netware : un de travail et un autre
(monté sur le serveur web) ou sont stocké les fichiers nommés à partir

des identifiants. Seul le serveur web aurait accès à ce dernier volume.

Désolé je ne connais pas Netware mais selon moi peu importe la norme
choisie, simplement choisir l'identifiant du document ma paraît la meilleure
solution : identifiant/nom unique, nom universel (fichier « 103 » ca passe
aussi bien sur Unix, MacOS que sur Windows, utiliser le nom du document
comme nom de fichier est le pire choix qu'on puisse faire « Le nom de mon
document PDF.pdf » par exemple :p).

Sinon en 2 mots, qu'est-ce que Netware ?

Merci,
JM

Jean-Marc Molina wrote:

Pour la nomenclature des fichiers ce sera je pense un truc genre [code
site d'origine][numéro][code type]

Sinon en 2 mots, qu'est-ce que Netware ?

NetWare est un méta-OS orienté réseau :) (il est tard ;)

La version que je dois utiliser : 5.1, la dernière en date est la 6.0
qui contrairement aux versions d'avant qui tournaient sous DR-DOS tourne
sous linux.

La société qui édite Netware est nommée Novell.

Merci,
JM

De rien