Je travaille avec un framework basé sur JSP (créé par des employés de l'entreprise, basé sur/extends Struts2) qui utilise des beans pour les données de formulaire. Des trucs assez standard.Capture d'un nombre variable de champs dans le bean JSP/Struts
Par exemple, étant donné ce balisage:
<input name="foo" type="text" />
À un certain moment, le cadre va obtenir une instance à un JavaBean que je lui donne, et à la page de chargement, il essaiera d'appeler bean.getFoo() et attendre pour renvoyer un String, qu'il définira ensuite comme la valeur du champ de saisie.
Puis, lorsque la page enregistre, quelque part dans le cadre, il va ramasser la valeur soumise à l'élément <form> et il appellera bean.setFoo(String val) et passera la valeur en tant que paramètre.
La structure prend également en charge la génération dynamique d'un nombre variable de champs en fonction d'un modèle. Une fois que vous avez passé tout le code JSP, il génère du HTML comme:
<input name="foo_1" type="text" />
<input name="foo_2" type="text" />
<input name="foo_3" type="text" />
Naturellement, il essaie alors d'appeler bean.setFoo_1(String val), bean.setFoo_2(String val), bean.setFoo_3(String val), etc. pour autant de cas du modèle comme il y a sur la page.
Le nombre d'occurrences possibles est effectivement illimité (et certainement assez grand pour créer manuellement toutes les instances possibles est ennuyeux). Je cherche donc une sorte de classe de bean dynamique qui permettra au framework d'appeler ces getters et setters et de constater que, en réalité, ils existent en tant que méthodes publiques getter/setter sur l'instance d'objet que le framework gère. On suppose qu'il utilise la réflexion pour déterminer si les méthodes existent.
Y at-il un moyen de mettre en œuvre ceci (ou d'utiliser une bibliothèque existante) au lieu d'écrire quelque chose comme le suivant? :
public class MyBean {
private String foo_1;
private String foo_2;
private String foo_3;
private String foo_4;
private String foo_5;
// 30 years later ...
private String foo_2147483647;
// Eclipse -> Generate getters and setters... for all 2167483647 of the above and watch it crash OOM because I have so many fields
}
Personnellement, je pense que si vos haricots ont ce beaucoup de champs alors l'application est misdesigned. Quel utilisateur veut réellement voir autant de champs sur son écran de saisie? Mais non, je n'ai pas de cadre existant pour vous. Je devrais peut-être faire le vôtre, mais d'abord je remettrais moi-même en question la conception de ces classes. – markspace
L'utilisateur ne verrait pas autant de champs sur son écran à moins que * ils * choisissent d'en ajouter autant. L'exemple canonique de ceci est une "table" éditable où vous pouvez ajouter de nouvelles lignes, et saisir des valeurs dans des champs de texte dans chaque colonne. Le problème est que je ne peux pas anticiper un nombre maximum que l'utilisateur pourrait raisonnablement attendre comme un maximum. En pratique, il se pourrait qu'il soit environ 100, mais encore une fois, ils ne sont affichés que si l'utilisateur en a créé autant pour commencer. Il commence réellement comme une table vide. Et créer foo_100 dans mon haricot est encore assez moche. – allquixotic
Mais alors vous n'avez pas de haricot. Si le nombre de champs est variable, vous utilisez quelque chose qui est variable comme une ArrayList. N'essayez pas d'implémenter une classe avec un champ pour chaque entrée de champ possible. C'est dingue. – markspace