J'essaie de passer la valeur (du formulaire rempli) d'une vue à la vue suivante en utilisant la méthode get. Ma vue ressemble à ceci.
from django.urls import path
from . import views
urlpatterns = [
path('', views.search, name='search'),
path('search-results/<country>/<city>/', views.search_results, name='search_results'),
et simple forms.py^
http://127.0.0.1:8000/search-results/?country=USA&city=new-york&
J'ai essayé d'utiliser args (pour passer la ville et le pays à l'affichage search_results ) HttpResponseRedirect (reverse ('app: search_results', args = [country, city])) mais mes prochaines vues d'URL ressemblent à ceci:
http://127.0.0.1:8000/search-results/USA/new-york/
mais j'attends quelque chose comme ça (après avoir redirigé vers la vue suivante):
class SearchForm
country = models.ChoiceField(choices=COUNTRY)
city= models.ChoiceField(choices=CITY)
Comment puis-je faire cela? Par exemple, après avoir choisi l'emplacement et le type de travail sur cette page , nous voyons une URL similaire à l'exemple 2. pas 1 (comme sur la plupart des sites Web).
urls.py
def search(request):
if request.method == 'GET' and 'search' in request.GET:
form = SearchForm(request.GET)
if form.is_valid():
return HttpResponseRedirect(reverse('app:search_results'))
else:
form = SearchForm()
context = {'form': form}
return render(request, 'search.html', context)
3 Réponses :
Pas vraiment difficile si j'ai bien compris, vous pouvez appeler une redirection pour aller sur un autre autre modèle, et inverser pour avoir le lien provenant de votre "urls.py" et appeler simplement la valeur que vous voulez.
renvoyer la redirection (reverse ('urllink') + "? id =" + object.idObject)
Veuillez ne pas encoder manuellement le querydictionary. Si votre valeur contient des caractères tels que + , & , etc., ils doivent être échappés.
Oui c'est vrai, je voulais juste donner un problème de résolution rapide;),
Vous pouvez définir un QueryDict [Django-doc] . Vous pouvez ainsi générer un tel QueryDict pour construire les paramètres de la requête, comme:
path('search-results/', views.search_results, name='search_results'), Si vous urlencode () le querydict, vous obtenez :
>>> qd = QueryDict(mutable=True) >>> qd.update(country='USA', city='new york') >>> qd.urlencode() 'country=USA&city=new+york'
Vous devrez éliminer les paramètres de votre urls.py:
from django.http import QueryDict
qd = QueryDict(mutable=True)
qd.update(country='USA', city='new york')
return HttpResponseRedirect(
'{}?{}'.format(reverse('app:search_results'), qd.urlencode())
)car sinon, ces paramètres sont manquants.
"Bureaucrate Conrad, vous avez techniquement raison - le meilleur type de correct. Je vous promeut par la présente à la 37e année." (IOW; puis-je gentiment suggérer que le vrai problème ici n'est pas "comment faire cela", mais "pourquoi quelqu'un ferait-il cela alors que c'est totalement inutile") ;-)
@brunodesthuilliers: c'est un schéma fréquent si vous avez plusieurs boutons, chacun avec un nom et ( valeur ). Vous pouvez par exemple définir un bouton et . Habituellement, dans la conception de logiciels, les choses orthogonales sont exécutées par des choses différentes (enfin, je suis d'accord que la programmation impérative a plus de problèmes avec cela). Mais dans ce cas, je suggérerais d'utiliser une redirection. Notez que nous "pop" fonctionnellement ici le paramètre search = ... de la chaîne de requête :)
J'ai rarement eu un cas de deux boutons de soumission différents sous la même forme (en presque 20 ans ...) et chaque fois que cela se produisait, les fonctionnalités derrière à peine qualifiées d '"orthogonales". IOW, si vous avez deux boutons qui font des choses différentes, vous voulez certainement deux formulaires différents, chacun pointant vers sa propre URL. Mes 2 cents ...
NB: je ne dis pas que jamais peut être une raison valable d'avoir une redirection entre la soumission du formulaire et l'url du résultat, mais que 1 / c'est quelque chose d'assez rare dans mon expérience et 2 / c'est quand même pas nécessaire ici (à moins bien sûr que vous ne sachiez quelque chose sur ce projet qui n'est pas mentionné dans la question)
@brunodesthuilliers: eh bien le fait qu'il y ait probablement des données introduites est que le paramètre search get vient de quelque part :), et il ne peut pas faire partie du formulaire (étant donné que ce formulaire ne contient pas de champs supplémentaires) :). Cela peut ne pas être nécessaire en utilisant l'attribut formaction = , etc. Mais d'une manière ou d'une autre, c'est impopulaire. Les formulaires imbriqués ne sont malheureusement pas possibles en HTML (enfin, cela a du sens, car cela introduirait beaucoup de problèmes de sémantique).
J'ai bien peur de ne pas comprendre ce que vous voulez dire dans votre dernier commentaire.
Bien que la réponse de Willem Van Onsem soit techniquement correcte, elle ne passerait probablement pas une révision de code ici.
La solution canonique simple, évidente ici pour utiliser une seule vue pour valider le formulaire et afficher les résultats, et pour pointer le formulaire vers l'url de cette vue (c'est à cela que sert l'attribut "action" du formulaire HTML). p>
Si vous voulez que le formulaire soit affiché sur toutes les pages (ou au moins plus d'une) - comme c'est souvent le cas avec les formulaires de recherche -, alors tout ce dont vous avez besoin est un simple gabarit personnalisé qui crée un formulaire vide (qui pointe à votre URL de "recherche").
Pouvez-vous s'il vous plaît partager votre
urls.py?