Clase HtmlForm para PHP

[roman]

Hola dec,

Mira, mi opinión no puede ser muy objetiva porque no me convence eso de generar código html con php. Quizá para ciertos contextos específicos pueda servir, pero como algo de caracter general me parece que sería muy limitado. Claro que con CSS puedes controlar algo de la apariencia final del formulario pero aún así me parece que la estructura sería muy rígida. Desde luego, puedo estar equivocado.

Ahora bien, limitándonos al script en sí; de lo poco qe he visto y de lo que describes, creo que lo que sí es fundamental es que añadas soporte para los rótulos de los campos (igual y ya lo tienes, pero no lo he podido ver). También cambiaría el default del método, pues si el método por defecto en HTML es GET, creo que habría que respetarlo.

De todas maneras, pienso que la manipulación de los datos del formulario mediante propiedades de un objeto puede ser muy útil. La parte que no me cuadra es la de la definición en sí del formulario mediante código PHP.

// Saludos

[dec]

Hola,

Gracias por tus comentarios Román. En principio la clase está "pensada", precisamente, para obviar el HTML, pero, no por gusto, sino por una razón importante, sobre todo, cuando se trabaja con "plugins" que deben poder modificar el HTML. Se hace complicado, en fin, imprimir código HTML "por partes", puesto que unas partes no tienen conocimiento de lo que otras escriben, por ejemplo.

De ahí que sea útil poder definir el formulario sólo utilizando PHP. De este modo, por ejemplo, una parte (la aplicación principal) puede definir un formulario y pasar la definición a otras partes, quienes modrán modificar la definición del formulario, todo esto sin que el HTML aparezca para nada. Por supuesto, uno de los posibles inconvenientes (no todo pueden ser ventajas) es la posible rigidez de los formularios.

De momento sí que es posible añadir "labels" a los elementos del formulario. Luego, con CSS, podría controlarse su estilo, por no decir que cada elemento puede tener su atributo "style". Pero pueden tener atributos "id" y "class" si se precisa. Ya digo, el objetivo, completado hasta cierto punto o no, es poder trabajar con la "definición" de un formulario, toda ella en PHP, antes de que al cabo se imprima el código HTML del mismo.

De todas formas se trata de una primera aproximación al problema. Mejor dicho, llevé a cabo algún que otro intento anterior pero no funcionaron como este último. Cabría todavía añadir a la clase "HtmlForm" algunos métodos útiles, por ejemplo, para dar la posiblidad de "resituar" los elementos en la definición y alguna que otra cosilla más. Espero que se entienda el objetivo, puesto que se tiene que entender el problema de trabajar con HTML "por partes".

[dec]

Hola,

Me gustaría añadir algo más. Concretamente, los problemas que he mencionado para trabajar con HTML "por partes" los he podido "ver" en Gesbit. La clase "HtmlForm" no está basada en, pero, hasta cierto punto me la inspiró cierta clase similar que existe en el proyecto Habari. En efecto, este proyecto utiliza una clase "UIForm" (creo recordar) con la que se construyen los formularios del panel de administración de la aplicación.

Pues bien, el objeto "form" va pasando de plugin en plugin, de manera que cada uno puede trabajar con el mismo. Es cierto que los formularios del panel de administración de Habari se ven un poco,... como tú has dicho..."rígidos". Sin embargo, como he dicho arriba, no todo pueden ser ventajas, pero en Habari han pensado que estas son mayores que los inconvenientes. Desde luego yo en Gesbit sí he podido ver el problema de trabajar con HTML "por partes", pero, no sé si he conseguido dejar claro este "concepto".

P.D. En pocas palabras, de hecho los formularios de Habari se construyen con ayuda del objeto "form", los plugins, la propia base de datos... es una gozada, porque, todo es algo abstracto, pero,... funciona.

[dec]

Hola,

Acabo de hacer una actualización sencilla a la par que potente y me gustaría comentarla aquí. Para acceder al valor de un elemento de un formulario luego de que este sea enviado, ya no basta con escribir algo como: "$form->login". Ahora, para acceder al valor del elemento "login" ha de escribirse esto: "$form->login->Value()".

Por el momento sólo existen los métodos "IsEmpty()" y "Value()", pero, es claro que podrán añadirse más en el futuro, por ejemplo, "IsInteger()", "IsString()", etc., etc, de ahí que antes hablase de que se trata de una solución sencilla y potente al mismo tiempo. Bueno, sobre todo que cambia la forma de hacer las cosas tal como las expliqué ayer, por eso he querido comentar esta actualización.

[[movorack]]

hasta ahora no lo he leido mucho... mañana le echo ojo... pero dime algo... ¿la clase permitiria implementar javascript para el formulario en si y/o para los elementos del formulario?... si se puede implementar javascript, ¿da soporte a frameworks?... si se implementara el javascript (independiente del framework) ¿permite AJAX?... los pocesamientos se deben hacer al recargar la pagina (desventaja php) o ¿se pueden hacer asincronos?...

perdona que solo me halla enfocado en esto pero como sabes ahora para los formularios el javascript es full necesario a la hora de validar y evitar perdidas de tiempo en recargas completas de la pagina.

de todos modos... mañana miro a ver...

[dec]

Hola,

Tanto HTML como CSS y Javascript pueden y aun deben ir separados. Por supuesto que podría hacerse uso de Javascript, bien a partir de los tipos, clases e identificadores de los elementos del formulario, bien escribiendo Javascript en los atributos "on*" correspondientes, aunque es preferible de la primera forma.

En definitiva la clase "HtmlForm" únicamente muestra HTML, de modo que el CSS y Javascript necesarios no corren por su cuenta, pero, tampoco los impide en modo alguno. Gracias por tus comentarios movorack.

[dec]

Hola,

Otra actualización curiosa aunque "Interna" únicamente. En efecto, me he puesto a escribir métodos "IsNull()", "IsArray()", etc., como loco, sin tener en cuenta que podía arreglarse (mejor) con un sólo método un "switch" la mar de chulo. Total, estos y otros pequeños cambios "internos" en esta última actualización, por si le interesa a alguien.