Je construis une application à l'aide de web2py framework ... Je ne veux pas avoir à utiliser l'objet de la requête pour obtenir tous les paramètres QueryString, mais j'aimerais créer mon contrôleur avec des paramètres nommés et avoir le routeur Désactivez le dictionnaire de QueryString (ou de formulaire) dans les paramètres nommés et appelez mon contrôleur.
donc au lieu d'une méthode de contrôleur de où j'utiliserais la demande globale () Objetez et regardez via la liste des vars ... Je préférerais plutôt avoir comme je vois dans d'autres plates-formes MVC. est-ce possible dans web2py déjà? Ou y a-t-il un plugin pour cela? ou dois-je ajouter cela moi-même?
3 Réponses :
Non. Comme indiqué dans le book , une URL du formulaire
x, y, z = tuple(request.args) p = request.vars['p'] # p=1 q = request.vars['q'] # q=2
Merci ... Je l'ai compris dans le procès et l'erreur. serait bien s'il y avait une certaine option pour changer de comportement en fonction de la façon dont vous le souhaitez.
Ce qui précède n'est pas vrai dans le cas des fonctions décorées @service. Une fonction de contrôleur avec les paramètres peut être valide lorsqu'elle est enveloppée dans ce décorateur. Ce n'est pas le scénario op exact mais peut fournir une solution alternative à son problème; Voir ma réponse ci-dessous.
Oui Book est http://127.0.0.1:8000/a/c/f.html/x/y/z?p=1&q=2 , mais je reçois les paramètres dist ( demande.vaires) ¿C'est une mauvaise pratique?
Je fais
def create_user():
try:
first_name, last_name, email = request.args[:3]
except:
redirect('some_error_page')
Hey c'est cool! Je suis un débutant python ... Donc, ne réalisait pas que l'initialisation un peu était possible. Merci!
Il y a une circonstance dans laquelle les contrôleurs Web2py peuvent utiliser des paramètres. Lorsqu'une fonction de contrôleur a le décorateur @service, les paramètres peuvent être utilisés, en fonction du type de service, par exemple: Cette approche est pour quand une fonction de contrôleur est vraiment une API, pas un façon de générer une vue Web. Il existe de bonnes choses que vous pouvez faire en termes de définition de fonctions Web-View et de style API en parallèle et que les vues Web appellent les fonctions API, afin de vous assurer de bien séparer des vues et des contrôleurs. En fonction de la manière dont vous choisissez de diviser les responsabilités entre le client Web / JavaScript, la vue Web2py et le contrôleur Web2PY, il peut être logique d'avoir des fonctions de contrôleur vraiment API (avec des paramètres facultatifs) plutôt que de construire la logique de déballage des paramètres. Dans un contrôleur de style de vue Web.