11
votes

Springmvc - Modifier la vue lors de l'accès au mobile

Je me demandais si quelqu'un a déjà résolu ceci. J'ai une application SpringMVC et nous ajoutons un soutien à webkit de type mobiles (iPhone and Android), donc je me demandais que quelqu'un a trouvé un moyen élégant de définir des vues spécifiques en fonction de le client qui a envoyé la demande.

Je sais qu'un simple si dans une implémentation du contrôleur peut faire l'affaire, mais je cherche quelque chose de plus flexible / élégant (une implémentation spécifique de la vueSolver, ou un intercepteur peut-être).

L'aide sera grandement appréciée ... comme toujours =)


C'est une très vieille question. Ce que vous devez faire est d'utiliser Spring-Mobile pour y parvenir de manière élégante standard


1 commentaires

Je pense que c'est une bonne idée. J'ai créé Un problème de jira pour cela.


4 Réponses :


9
votes

Mise à jour: regardez Spring-Mobile

Réponse originale:

Il serait assez simple de créer une vue personnalisée Viewresolver qui résout la vue basée sur l'en-tête utilisateur utilisateur .

  • ici est une liste des agents utilisateur mobiles (page supprimée de Wikipedia) . Vérifiez l'en-tête contre lui et résolvez une vue mobile.
  • Si l'agent utilisateur n'est pas un mobile, retournez null , laissant ainsi d'autres résolveurs résoudre une vue.
  • Assurez-vous que vos résolveurs sont définis (dans le ressort XML) dans la commande appropriée, de sorte que le résolveur mobile soit consulté en premier.

5 commentaires

Ok, juste une préoccupation à ce sujet ... Dois-je toujours avoir accès à la demande HTTP sur la vueResolver, si oui, comment l'accéder sans le transmettre spécifiquement sur chaque contrôleur?


Vous pouvez obtenir la demande à partir de demandeurs (jeter les attributs à servleRequestatTtributes )


Oui, mais cela ne peut être fait qu'au niveau du contrôleur, la vueResolver ne reçoit plus le HTTPServletQuest à moins que vous ne le transmettez dans le modèle, qui est quelque chose qui peut ne pas être souhaitable.


@CHEPEPCH Alors vous dites qu'il n'y a rien dans RequestAttributeholder dans la vue Viewresolver? C'est surprenant.


Ce n'est pas :) Le déminentTributeholder est une classe parfaitement valide



1
votes

OK, j'ai trouvé une réponse plus spécifique. Il y a un problème avec la solution proposée à Bozho. Le fait que les vitessolversolvers n'ont plus accès au httpservletQuest . Il y a un moyen d'accéder à la demande mais son genre de sale imho .

Ainsi, c'est une très élégante et facile à mettre en œuvre Solution . De manière fondamentale, cela implique une vue personnaliséeResolver (comme Bozho proposé), mais elle ajoute un intercepteur de manutention qui ajoute l'agent utilisateur au modèle afin que vous n'ayez plus besoin de l'ajouter manuellement.


0 commentaires

2
votes

J'aime @bohzo et vous avez déjà dit que Spring-Mobile est la voie à suivre.

à partir de la version 1.1, vous pouvez utiliser LITHEDIEDELÉGATISVIEWRESOLVER Pour configurer le type de comportement que vous décrivez.

DISPOSITIF CADRE VIEW GESTION

HTTP : //static.springsource.org/spring-mobile/docs/current/reeference/html/device.html#device-aware-view-management

Spring Mobile inclut AbstractDetieDélégadifierViewresolver, une wrapper abstraiteResolverResolver qui déléguette à une autre vue de la mise en œuvre du résolveur, permettant la résolution des noms de vue spécifiques de périphérique sans qu'il soit nécessaire de définir un mappage dédié pour chaque vue. Une implémentation légère est fournie, qui prend en charge l'ajustement des noms de vue selon que le périphérique d'appel est normal, mobile ou tablette.

Dans votre application, vous pouvez ensuite créer des vues alternatives pour des périphériques normaux, mobiles ou de tablettes, puis de la configuration appropriée, Spring Mobile ajustera le nom de la vue pour résoudre le bon. Cela se produit en interne, sans qu'il soit nécessaire d'ajouter une logique conditionnelle à travers vos contrôleurs.


0 commentaires

0
votes

Pour accéder à la demande actuelle à l'intérieur de la vueSolvers. xxx


0 commentaires