Separe la presentación de la lógica con WTForms

Question

Me estoy familiarizando con Flask, WTForms (y flask-WTF).Siento que me falta algo.

De acuerdo con la Documentos de WTForms "El HTML del campo de su formulario se puede generar para usted, pero le permitimos personalizarlo en sus plantillas.Esto le permite mantener la separación del código y la presentación, y mantener esos parámetros desordenados fuera de su código Python".

El método sugerido para modelar entradas de radio HTML es:

class ExmapleForm(Form):
    language = RadioField(u'Programming Language', choices=[('py', 'Python'), ('js', 'JavaScript')])

....y la forma sugerida de crear plantillas de entradas de radio HTML es:

{% for subfield in form.radio %}
    <tr>
        <td>{{ subfield }}</td>
        <td>{{ subfield.label }}</td>
    </tr>
{% endfor %}

Con este enfoque, ¿la propiedad de opciones "que es una secuencia de pares (valor, etiqueta)" no mezcla la presentación con los modelos?

¿Existe una forma de mover la etiqueta a la plantilla y hacerla coincidir con el valor?

Answer 1

Interesante pregunta.Si pensamos en términos del patrón MVC, creo que la lista de opciones que van en un menú desplegable pertenecen al Modelo, no a la Vista.Por lo tanto, el diseñador no definiría estas opciones en la plantilla.Creo que estamos de acuerdo en esto, ¿verdad?

Tener la lista de opciones codificada en el formulario como en su ejemplo es mejor, pero tampoco es ideal.Presumiblemente tienes un Language modelo o entidad similar, ¿correcto?Ese modelo es la autoridad en las opciones válidas de lenguajes de programación, por lo que debería ser el que proporcione la lista de opciones válidas a cualquier persona, ya sea un formulario u otro subsistema.

Como menciona en su pregunta, cada opción tiene un nombre interno y un nombre para mostrar.Y ya que estamos hablando de cadenas de visualización, no olvidemos que el u'Programming Language' El título de su campo se encuentra en la misma categoría de cadenas de visualización.¿Estas cadenas deberían ser responsabilidad del diseñador de la plantilla?No lo sé, esta es un área gris entre el modelo y la presentación, creo que el diseñador debería tener autoridad sobre cómo se ven las cosas, pero no sobre el contenido.

Si desea tener más control sobre el aspecto de estas cadenas de visualización, puede utilizar un kit de herramientas de traducción como gettext (a través de Flask-Babel, por ejemplo).Si su aplicación representa texto a través de gettext, puede asignar cualquier cadena del código o la plantilla a otras cadenas.Esto se usa para traducir a otros idiomas, pero también puede usarlo para tener un control independiente sobre cómo se muestran las cadenas en el idioma nativo de la aplicación.El mapeo se realiza en un archivo de datos externo, por lo que creo que con esto se logra la independencia que buscas.

Answer 2

del punto de vista puramente teórico que no parece ser una buena idea.Si tuvo que conectar la etiqueta con el valor real en la plantilla, esto significaría tener una lógica de negocios en la plantilla.

Además, ¿cómo voy a imaginar el código exacto haciendo eso?Requeriría un contexto de subcampo dentro de la declaración que asigna la etiqueta.No puedo imaginar que ese código se vea bien en la plantilla.¿Y sería parte de la lógica de presentación como debería?

Answer 3

Aquí está la solución con la que se me ocurrió (para mantener la separación).Puede ser demasiado exagerado, pero lo voy a probar y ver cómo se escala.

en formularios.py:

import sys
sys.path.append("templates")
import constants

class ExmapleForm(Form):
    language = RadioField('language', choices=constants.languages['choices'], validators=constants.languages['validators'])

Luego creé un archivo en la carpeta de plantillas llamada constants.py:

from wtforms.validators import InputRequired

languages = {
    'choices': [
        ('py', 'Python'),
        ('js', 'JavaScript')
    ],
    'validators': [
        InputRequired(message = 'Please Select')
    ]
}

Espero que ayude (y trabaja)