ACTUALIZACIÓN: Se sugirió en los comentarios que creo una wiki para esto. He terminado, puedes encontrarlo aquí (si deseas mantenerlo al tanto y/o contribuir).Necesita consejo para crear un nuevo "estándar"/"idioma"
Nunca había trabajado en algo como esto antes, así que estoy volando por completo.
nunca he trabajado en algo como esto antes, así que por favor
me quiero trabajar en una o "lengua" abierta "estándar", o ... bueno, yo no' Realmente sé cómo llamarlo ... para facilitar la validación de formularios. Lo llamo VRS (hojas de reglas de validación) pero en esta etapa, todo es negociable.
La idea es crear una hoja de reglas, similar a CSS que define cómo se deben validar los formularios. Esto requerirá
- una sintaxis/Especificación
- Un analizador de VRS para convertir el VRS en algo utilizable
- procesador A VRS para comparar los datos del formulario en contra de las reglas y devolver una respuesta.
- Un formato de respuesta.
Los beneficios de un sistema como este serían
- Una plataforma/idioma manera agnóstica para definir validaciones de la forma.
- Una forma multiplataforma, altamente portátil para definir validaciones de formulario.
- Fácil de leer, fácil de instalar, fácil de modificar.
- Integración de cliente y back-end.
Lo primero es lo primero. ¿Cómo debería ser la sintaxis/especificación?
La forma en que veo esto trabajando en línea es que un archivo VRS podría especificarse como un campo oculto y la aplicación enruta los datos de formulario proporcionados a través del procesador VRS antes de procesarlo.
A modo de ejemplo, se puede validar el tipo de contenido del campo "Nombre" se vería así
name {
content-type: alpha;
}
tipo de contenido podría ser uno de tres valores: alfa, numérico o alfanumérico .
Espero que tenga sentido. Nunca he hecho algo como esto antes, así que estoy ansioso por obtener la opinión de otras personas. Aquí es por lo que yo he recibido
------------------------------------------------------------
content-type: (string) alphanumeric | alpha | numeric
Restricts content to either numeric, text or alphanumeric.
------------------------------------------------------------
is-fatal: BOOL
If the rule fails, is it fatal? This could be really useful
for AJAX responses.
------------------------------------------------------------
allow-null: BOOL
wether a field can be empty or not. Good for required fields
and checkboxes
------------------------------------------------------------
pattern-match: (string) email | url | regex
match the field against a pattern.
------------------------------------------------------------
field-match: (string) field_name
compares a field to another field. eg: password confirmation
------------------------------------------------------------
greater-than: INT | FLOAT
less-than: INT | FLOAT
within-range: INT | FLOAT, INT | FLOAT
Pretty self explanatory. With regard to strings however,
the string length is compared against the params.
------------------------------------------------------------
is-unique: (func) connection(host,user,pass), (func) map(table, field)
Check the value against a field in the database to see if
it's unique.
------------------------------------------------------------
date & time validations
This i'm a bit worried about in terms of terminology. I also
want to include dynamic vars in VRS such as
@now
@today
@thisMonth
@thisYear
------------------------------------------------------------
before: STRING | VAR
after: STRING | VAR
Again, self explanatory. Although I'm unsure what the date/time
format should be. UTC?
------------------------------------------------------------
Elapsed Time:
I'm completely stuck on how to handle conditions like
"years elapsed since date is more than 16"
I don't relish the idea of rules as prolix as
years-elapsed-since-now-are-more-than:18;
years-elapsed-since-now-are-less-than:18;
Por último, estoy debatiendo desarrolladores wether debe ser capaz de especificar los errores/advertencias en el VRS, o deben hacerlo que en la tramitación de la respuesta?
Entonces, eso es mucho que asimilar y espero que esté claro.Mi pregunta (s) supongo que son
- ¿Buena/mala idea?
- ¿Es este el tipo correcto de sintaxis?
- ¿Hay formas más elegantes de nombrar las reglas?
- Lo que falta.
gracias
ACTUALIZACIÓN: Algunas personas han dicho que este sistema propuesto es una mala idea. Si lo cree, proporcione un escenario en el que no funcione. Pensar que es una mala idea es una cosa, probar que es una mala idea es otra, y me gustaría ver pruebas de que es una mala idea más temprano que tarde. Si realmente crees que la validación de formularios no puede ser más fácil o menos tediosa, explica por qué.
Además, soy consciente de que la validación de formulario no es un problema nuevo. Sin embargo, actualmente no existe una solución portátil, multiplataforma y de lenguaje cruzado para abordar la validación de formularios, que es a lo que se dirige específicamente esta propuesta.
esto es genial, pero algunas cosas que va a querer agregar/observar son la validación de tipos específicos de elementos. Por ejemplo, direcciones de correo electrónico, números de teléfono, números de seguridad social, fechas, horas, URLs, URI, 2 campos separados deben coincidir, rangos para números, moneda, etc. ... Luego tome todo eso y multiplíquelo por internacionalización :) – Justin808
donde ¿Esto va a ser usado? ¿Esto es algo que vincularías a HTML? ¿se sienta encima de javascript? ¿Se relacionaría con otras áreas, formularios PDF, archivos XML, etc.? ¿Ves algo así como un lenguaje de descripción de formulario genérico del que formaría parte? – Justin808
No solo coloque el VRS en un campo de formulario oculto en el lado del cliente. Si lo hace, podría abrir fácilmente Firebug y modificar el VRS, haciendo que la validación de su formulario pase cuando no debería. Tenga el mismo VRS tanto en el lado del cliente como en el del servidor, para que pueda hacer la validación en el lado del servidor también si se manipula. ¡Aparte de eso, gran idea y buena suerte con eso! –