¿Controladores web2py con parámetros?
Pregunta
Estoy construyendo una aplicación usando el marco Web2py ... No quiero tener que usar el objeto de solicitud para obtener todos los parámetros de consulta, sino que me gustaría construir mi controlador con parámetros con nombre y hacer que el enrutador desempaquete la Queristring (o datos de formulario) Diccionario en los parámetros con nombre y llame a mi controlador.
Entonces, en lugar de un método de controlador de
create_user():
Donde usaría el objeto Global Request () y miraría a través de la lista VARS ... Preferiría tener en su lugar tener
create_user(first_name, last_name, email):
Como veo en otras plataformas MVC.
¿Es esto posible en Web2py ya? ¿O hay un complemento para ello? ¿O necesito agregar eso yo mismo?
Solución
No. Como se indica en el libro, una URL de la forma
http://127.0.0.1:8000/a/c/f.html/x/y/z?p=1&q=2
mapas a la aplicación (carpeta) a
, controlador (archivo) c.py
, función f
, y los argumentos adicionales deben desempaquetarse del objeto de solicitud como
x, y, z = tuple(request.args)
p = request.vars['p'] # p=1
q = request.vars['q'] # q=2
Además, Web2py detecta específicamente las funciones de controlador válidas como aquellas funciones que no tienen argumentos. AFAICR, esto es opuesto a Django que detecta funciones de controlador válidas como aquellas que tienen al menos un argumento.
Otros consejos
hago
def create_user():
try:
first_name, last_name, email = request.args[:3]
except:
redirect('some_error_page')
Pero importa que First_Name, Last_Name y el correo electrónico puedan contener caracteres que no están permitidos en Path_info (Web2py en Picky al validar eso solo [ W -.] están permitidos).
Hay una circunstancia en la que los controladores Web2PY pueden usar parámetros. Cuando una función de controlador tiene el decorador @Service, se pueden usar parámetros, dependiendo del tipo de servicio, por ejemplo:
@service.jsonrpc
def somefunction(a=None, b='default'):
## whatever
Este enfoque es para cuando una función de controlador es realmente una API, no una forma de generar una vista web. Hay cosas bonitas que puede hacer en términos de definir las funciones de visión web y estilo API en paralelo, y hacer que las vistas web llamen a las funciones API, para asegurarse de tener una buena separación de vistas y controladores.
Dependiendo de cómo elija dividir las responsabilidades entre el cliente web / JavaScript, la vista Web2py y el controlador Web2PY, puede tener sentido tener funciones de controlador que sean verdaderamente API (con parámetros opcionales) en lugar de construir la lógica de parámetros y unión en Un controlador de estilo de vista web.