J'ai un modèle de domaine comportant plusieurs «éléments», des pièces de texte pouvant être rendues pour montrer un contenu riche. Il existe des morceaux de texte HTML, de texte textile, d'objets flash et ainsi de suite. Les caractéristiques de base de ces éléments sont encapsulées dans Lors de la modification du modèle, je souhaite que l'utilisateur puisse ajouter de manière dynamique des éléments et les sauvegarder quand le L'utilisateur soumet le formulaire. Donc, ce que j'ai est une forme qui est dynamiquement extensible avec certains JavaScript, ce qui donne le formulaire suivant: p> ceci va mal lors de la soumission du formulaire. C'est assez évident pourquoi - lorsque soumis, Spring tente d'instancier les éléments requis dans la liste. Étant donné que la liste des éléments contient des objets de type Comment irai-je le printemps instancier le type d'élément approprié? Pourrait ajouter des informations de type dans le formulaire et avoir un peu de modèle à partir? Comment cela fonctionnerait-il? Y a-t-il quelque chose que je peux faire dans le modèle qui le fera automatiquement? P> p> abstractelement code>, qui a des implémentations htmlelement code>, flashelement code> et ainsi de suite. Le modèle dispose donc d'une liste abstractelement code> qui est abstrait, le ressort ne peut pas instancier de nouveaux éléments. P>
3 Réponses :
On dirait que vous devez créer un (ou plusieurs) éditeurs de propriétés client qui peuvent prendre les paramètres de la demande et les convertir dans les instances de classe appropriées à ajouter à la collection. P>
Spring utilise des instances de propriétéAditor enregistrées avec le classeur de données pour lier les paramètres de la requête. Dans les cas où l'ensemble des propriétés par défaut ne peut pas déterminer le type correct, vous pouvez enregistrer vos propres éditeurs pour gérer la logique. P>
Le processus est décrit dans les documents de printemps à ce lien: P>
Spécifiquement, voir la section 5.4.2.1 sur la manière d'enregistrer les éditeurs de biens clients. P>
Vous pouvez enregistrer vos éditeurs de propriétés à l'aide de la méthode RegisterCustomEitor () de la classe WebDataBinder dans la méthode initbinder () de votre contrôleur (identifié avec l'annotation @InitBinder). P>
Un propriétaire n'est-il pas conçu pour traiter une seule valeur de texte (comme un format de date) à un objet Java? Comment puis-je ajouter des paramètres de demande supplémentaires?
De votre question, il semblait que l'utilisateur final renouvelait divers textase sur une forme HTML et la soumettant. Sur soumission, je pensais que vous vouliez en quelque sorte déterminer le type d'objet correct pour instancier en fonction du contenu de chaque textarea. Vous pouvez utiliser un propriétaire pour convertir entre une chaîne et tout type d'objet, donc je pensais que cela fonctionnerait pour vous. Si je ne comprends pas le formulaire correctement, veuillez fournir plus de détails et je vais essayer d'aider.
Comme vous pouvez le constater dans le formulaire d'exemple, il n'est pas certain que l'élément aura un attribut «contenu». Cela pourrait avoir un attribut «fichier» à la place. Un propriétaire n'a pas pu écouter cela. En outre, différents types de contenus basés sur des textes ne peuvent pas être différenciés de manière spécifique en fonction du contenu de la chaîne.
Vous pouvez essayer d'instantimer le formoVeject vous-même en créant une méthode modèleAttribute qui retournerait un objet concret. E.G.
@ModelAttribute("bindingObj")
public AbstractObject initElementList() {
AbstractObject obj = new ConcreteObject();
obj.setElements(new ArrayList<ConcreteElement>);
return obj;
}
@RequestMapping(...)
public ModelAndView requestHandler(@ModelAttribute("bindingObj") AbstractObject) {
....
}
Bien que je ne l'ai pas mentionné dans la question, il serait bénéfique que la solution soit facilement réutilisable entre les contrôleurs - il existe plus de modèles qui ont une liste d'éléments. Il me semble que cela est très spécifique pour un contrôleur?
Personnalisé PropertyEditor est une option, mais je ne sais pas comment vous pourrez résoudre le type concret de l'élément de liste dans l'éditeur. Étant donné que chaque contrôleur sait quel élément de liste doit être lié à, peut-être le contrôleur est le meilleur endroit pour cela.
J'ai fini par résoudre celui-ci en implémentant un modèle de modèle qui construit la liste des éléments en analysant les données de formulaire brutes. L'analyse des données de forme brutes peut être utilisée à l'aide de l'objet Ce n'est pas la solution idéale, mais ça marche. P> httpservletQuest code>, en boucle via la carte du paramètre et en créant simplement les objets requis "à la main". Il est réutilisable si vous le mettez dans une fonction d'assistance, même si j'ai besoin d'un mannequin dans chaque contrôleur, je l'utilise. P>