Me pregunto si hay alguna solución para almacenar formularios web en código. Para que pueda duplicarlos fácilmente en otros sitios y agruparlos con sus propios módulos. Estoy buscando algo similar a la API de vistas.

Si no está disponible, ¿cuántas personas están interesadas en dicha funcionalidad? Podría desarrollar un módulo que pueda manejar el almacenamiento de formularios web en Code. ¿Y tiene alguna inquietud al crear dicho módulo?

Gracias Jaap

webforms

— Jaap Jansma
fuente

¿Te refieres a los formularios creados con el módulo Webform?

— Mołot

Sí, me refiero a los formularios creados con el módulo de formulario web

— Jaap Jansma

En realidad es muy fácil, solo eche un vistazo a cómo lo hace Webform share . ( webform_share_export()y webform_share_node_insert()son las funciones de dinero). No puedo decir que apruebo el uso de eval(), pero podría convertirlo fácilmente para usar un objeto JSON / cadena serializada en su lugar. La única dificultad (pequeña) que debe superar es cómo / cuándo se aplica su formulario web a un nuevo nodo, por supuesto, se requiere un nodo para adjuntar el formulario web.

— Clive

En realidad no, y no hay necesidad de ello.

Si necesita un formulario disponible desde el código, los formularios de API de formulario no son tan difíciles de escribir desde cero. Al contrario de lo que ocurre con las Vistas, solo puede crear temas de formularios web en su ID de nodo, y eso cambiaría de un sitio a otro, por lo que los formularios de formularios web incluidos en el módulo no serán convenientes.
Si desea agrupar formularios con sus módulos y, por cualquier motivo, no puede utilizar la API de formularios, la integración de características de UUID y el uso compartido de formularios web proporcionan formas de hacerlo. No será un código en sentido puro, pero debería funcionar.
Es relativamente fácil de usar hook_form_alterpara obtener la representación API de formulario de un formulario web en particular. Por supuesto, no podrá cambiarlo fácilmente en el futuro, pero nuevamente, al contrario de lo que se ve, es bueno. El módulo no está dañado si no se muestran algunos datos. Los datos no proporcionados, o proporcionados de una manera que el módulo no espera, pueden romper las cosas. Entonces, si el módulo necesita un formulario, no debería ser fácil de editar . Las ediciones en el formulario requerirían modificaciones en el código del módulo de todos modos, por lo que el código API de Formulario hace las cosas más fáciles, no más difíciles a largo plazo, en tales situaciones.

— Mołot
fuente

Si bien esta es una buena respuesta para la alternativa, creo que querer mantener los formularios web en el código es una solicitud bastante razonable (no estoy de acuerdo en que no sea necesario o que no sea realmente posible). Por ejemplo, si desea proporcionar un formulario de contacto base con un módulo que los usuarios puedan extender a través de la interfaz de usuario, un formulario web sería ideal. Construir esa interfaz de usuario usted mismo sería un verdadero dolor. Dado que el webformobjeto (¿o la matriz?) Se asienta en el objeto del nodo de todos modos, se puede serializar y volver a aplicar muy fácilmente

— Clive

@Clive Pero para un contacto básico, ¿por qué alguien necesitaría un código real? ¿Por qué el nodo exportado (con la integración de características de UUID puede exportar el nodo al módulo) sería suficiente?

— Mołot

¿Ese módulo también sincroniza el objeto Webform?

— Clive

@Clive Por lo que recuerdo, lo hizo, con algunos problemas, pero sí. Ah, y si el código personalizado necesita datos de un formulario, ¿no sería peligroso convertirlo en un formulario web? No conozco ninguna forma de hacer que los campos sean resistentes a la eliminación en Webform (pero admito que no he buscado tanto).

— Mołot

De hecho, incluso hay un parche para el formulario web para que la integración funcione. Lo retiro :)

— Clive

Almacene los formularios web Drupal 7 en código

En realidad no, y no hay necesidad de ello.