Bonjour;
 
j'utilise le modèle Struts MVC2 ds mon application qui n'utilise pas de SGBD pour la persistance des data.
J'upload des répertoires de fichiers d'un client via un browser vers un serveur Unix. Le stockage se fait directement sur le disque du serveur (système de fichiers standard).
IL y'a un autre application en C++ qui a besoin de certaines infos concernant les repertoires uploadés.
 
Questions :
 
Q1 :  Comment modéliser (au sens uml : classe, package) la partie Vue qui est pour moi un ensemble de pages JSP ?
 
Q2 : Quel est le moyen le plus perfermant de stocker des infos concernant chaque upload (car qd un client upload un répertoire de fichiers, la réponse à sa requete :  OK ds ce cas il faut que je lui affiche toutes les caractéristiques du répertoires uploadé par exemple : la taille, le nbre de fichiers, leur noms, etc... Sinon KO un msg d'erreur avec la cause de l'échec).
J'ai pensé à faire ceci : dans mon bean répertoire, j'ai un attribut "caractéristiques" de type File => c'est un fichier texte qui contient toutes les infos à afficher utiliser par le JSP de la partie Vue.
Autre solution c'est de mettre toutes les caractéristiques comme attributs du bean, le sérialiser ds un fichier qui sera utiliser par un JSP d'affichage de la réponse.
 
Q3: Ds la modèle struts : est il intéressant d'utiliser la class forme ?
 
En vous remerciant

struts-user-subscribe@jakarta.apache.org
 
pour s'abonner à la ML de Struts. La question 3 trouvera probablement une réponse rapide.
 
La 1 je ne sais pas trop.  
 
Pour la 2 par contre, linker un Bean avec une référence avec un File (si j'ai bien compris) est selon moi une mauvaise idée (surtout si tu dois sérialiser l'objet). Un bean doit représenter les données et doit contenir l'état de tes données. Pq pas une factory qui load ce fichier et qui initalize le bean proprement? Faut voir parce que ta description n'est pas assez précise et c'est dur de se plonger dans un projet avec une description de 10 lignes sur un problème particulier.

Bonjour;
 
Merci pour ta réponse.
 
Qu'est ce que tu veux dire par : "Pq pas une factory qui load ce fichier et qui initalize le bean"
 
Moi j'ai juste besoin d'un container pour stocker des data particulières qui concernent les fichiers que j'upload (ces data je les extraits à partir du contenu de certains fichiers, par exemple : Numéro de version, nbre de modules et de segments, etc..)
Sachant que le client nous interdit d'utiliser un SGBD.
 
A+;
 
Djamel;

Bin ca dépend du fichier évidemment mais j'imagine mal un bean qui a une référence vers un fichier local. Question portabilité c'est zéro.
 
Mais bon je ne connais ni ton projet, ni tes contraintes donc c'est difficile de juger

Bon je veux être plus générale :
 
Comment stocker ou garder des objets Java (créer à partir d'un JavaBean) sans utiliser un SGBD.
J'avais proposer la sérialisation de ces objets (les stockés ds un fichier sous un format binaire).
 
Ma question : Avez-vous d'autres solutions à me proposer.
 
Djamel;

Bin y a bien un EJB en mode CMP mais y a toujours un sgbd derrière de toutes façons ...
 
Si tu veux avoir une persistence de données sans base de données bin tu as d'autre solution. On peut penser à JMS par exemple mais bon tout dépend du type d'information que tu dois sauver.
 
Et puis faut se poser les bonnes questions aussi. Est ce que le projet est réalisable sans SGBD ?

C'est quoi JMS ?
 
Appication télécom => aucun SGBD (il faut faire avec c'est une contrainte explicitée clairement par le client).
Qd aux data des objets, c'est des attributs de classes Java de tout type : string, int, etc...).
 
A+;
 
Djamel;

une appli sans BDD ???    
bha dit donc !!!
 
t'as bcp de données persitentes ?
 
JMS =  Java Message Service : spécification d'échange de message entre application. utilisé notament dans la nouvelle norme EJB2.0 (Message Drivern Bean)

Java Messaging Service. Un bus permettant de stocker des messages.
 
Ecoute franchement je suis incapable de te répondre. C'est trop flou
 
Et comment le client le justifie ... Ca par contre ca m'intéresse

 
haa ??? je voyais pas ca comme ca ...

tu serializes tout en XML ...

le bourin est dans la place !