7
votes

Paramètres sans mutateurs et accesseurs (setters / getters) avec l'intercepteur des paramètres dans Struts 2

Dans la classe d'action suivante, j'utilise l'intercepteur des paramètres.

<s:form namespace="/admin_side" action="Test" validate="true" id="dataForm" name="dataForm">
    <s:if test="hasActionMessages()">
        <s:actionmessage theme="jquery"/>
    </s:if>

    <s:if test="hasActionErrors()">
        <s:actionerror theme="jquery"/>
    </s:if>

    <s:hidden name="param1"/>
    <s:hidden name="param2"/>
    <s:hidden name="extraParam"/>
    <s:submit value="Submit" action="TestMessage"/>
</s:form>


5 commentaires

Pourquoi pensez-vous que les paramètres sont hérités?


" Les paramètres sont hérités? " Je ne comprends pas!


Si vous avez une certaine configuration et que vous avez des paramètres à l'action ou à l'intercepteur, et que vous les étendez à partir du package parent et que vous ne deviendrez pas la même chose que si vous spécifiez une annotation sur la classe ou sur la méthode.


@Romanc: Vous pouvez répondre à la question. Je ne comprends pas la chose que vous mentionnez.


S'il vous plaît ajouter une réponse, si quelqu'un a.


3 Réponses :


1
votes

Permet de jeter un coup d'œil au paramelspreparamsstack : xxx

Il y a 2 paramètres intercepteurs. Lorsque vous définissez exclutparams paramètre dans votre classe d'action, ceci est probablement défini pour le premier paramètres Intercepteur - paramètre pour le second intercepteur reste par défaut. Maintenant, lorsque le second paramètres Intercepteur (avec défaut exclutparams ) est appelé, puis une exception donnée est lancée.

Vous pouvez essayer de faire dupliquer le réglage de la exclutparams paramètre pour définir également le second intercepteur: xxx


4 commentaires

L'extrait de code dans la question n'est qu'un exemple. En réalité, il n'y a pas de paramètres définis tels que extraparam comme des utilisateurs finaux peut fournir un nombre quelconque de paramètres malveillants (en fonction de la longueur de l'URL qui s'intéresse)) pouvant causer une telle exception comme mentionné dans la question. Params.AcceptParamNames ne doit accepter que ces paramètres répertoriés. Le reste doit être interdit sans causer de tels messages que dans la question d'apparaître .


Comme je l'ai mentionné, il y a 2 paramètres intercepteurs dans paramelspreparamsstack . Lorsque vous définissez param.acceptparamnames Ceci est défini uniquement pour le premier intercepteur. Vous NEDD pour définir ce paramètre également pour le deuxième intercepteur.


Spécification de param.acceptparamnames ou parames.exclouveparams deux fois sur l'intercepteur des paramètres ne fait pas de différence. Cela n'empêche pas l'exception comme mentionné dans la question. Par conséquent, je n'envisage pas actuellement à accepter la réponse afin qu'elle soit répertoriée dans le Liste des questions sans réponse . Si vous rencontrez une solution délibérément ou accidentellement ultérieurement, n'oubliez pas de mettre à jour la réponse, quel que soit le temps qu'il prend, peut être des années. C'est le seul endroit pour moi où je peux apprendre. Merci.


J'ai accidentellement attribué la prime à une mauvaise réponse, première fois. Je me sens coupable et honte de ça. L'action une fois terminée ne peut jamais être annulée. S'il vous plaît, pardonnez-moi. Je m'excuse vraiment de mon erreur.




2
votes

J'ai déjà dit dans le commentaire que les paramètres d'intercepteur ne sont pas hérités par les configurations d'intercepteur des packages parent si vous définissez votre propre ensemble de paramètres qui remplacent les paramètres par défaut. Voir Intercepteur Paramètre Remplacement de l'héritage .

Il existe également des techniques utilisées pour obtenir deux cartes différentes de paramètres d'intercepteurs, voir Obtenir des paramètres d'intercepteur dans Struts2 .

Le plugin de la convention crée des configurations de package XWork qui héritées d'un package parent. Voir ma réponse pour Struts 2 Plugin de la Convention Définir plusieurs forfaits parents .

Donc, tout ce que vous avez à faire est de remplacer le paramètre par défaut défini par la configuration parent si vous souhaitez ajouter vos propres paramètres à l'ensemble. Intercepteur Tag ou Intercepteur-pile Tag et vous devez le faire pour chaque Interceptor-ref étiquette.

Le plugin de la convention utilise @interceprrref annotation dans le même but, mais avec une mise en garde qui s'applique sur la classe, elle s'applique à chaque action de cette classe. Alors, soyez prudent lorsque vous utilisez cette annotation au niveau de la classe. Vous remplacez les paramètres d'interceptage de la pile, vous devez donc utiliser un préfixe suivi de DOT du nom d'intercepteur référencé dans la pile pour chaque nom de paramètre, mais cela ne fonctionne que si vous avez des noms uniques du Interceptor-ref S dans la pile.

Si vous avez deux références de l'intercepteur intercepteur dans le paramelspreparamsstack alors vous ne pouvez pas remplacer le second parames intercepteur- Réf sauf si vous créez votre propre pile d'intercepteur et spécifiez les substitutions de paramètres sur chaque référence de l'intercepteur.


1 commentaires

Merci. Je vais essayer de le mettre en pratique plus tard.