Forum: Rails-ES form_remote_tag

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
5312077471dcb23fb2942bd2d94741df?d=identicon&s=25 David Davidrv (davidrv)
on 2008-10-27 17:16
Buenas!

Tengo un pequeño problemilla con el form_remote_tag:

No consigo que me guarde el formulario (en realidad no me pasa ni los
parametros al controlador creo)

Tengo lo siguiente:


<% form_remote_tag :update => "demanat", :url => {:controller =>
'works', :action => 'create'}, :html => {:action => {:controller =>
'works', :action => 'create'}} do %>

<%= text_field_tag :nombre %>   (He probado también <%= text_field
"work", "nombre" %>

<%= submit_tag "ok" %>

Total, que me ejecuta el :update del <div> correctamente pero me guarda
un registro con el campo "nombre" vacío.

En el controlador tengo el codigo por defecto de un "create":

@work = Work.new(params[:work])
@work.save

Aunque también he probado en coger los parametros con el nombre del
text_field [:nombre] y nada de nada. Creo que no me los pasa porque en
la consola sólo me dice que pasa estos parametros:

Parameters: {"action"=>"create", "controller"=>"works"}

¿Alguna idea? Un saludo,

david.
Fbef10e8904c80c015dce56f3fa09bea?d=identicon&s=25 Sergio Cambra .:: entreCables - Symbol Servicios (Guest)
on 2008-10-28 09:21
(Received via mailing list)
El Monday 27 October 2008 17:16:37 David Davidrv escribió:
> <% form_remote_tag :update => "demanat", :url => {:controller =>
>
>
> ¿Alguna idea? Un saludo,
>
> david.

¿Has comprobado el codigo html que te genera? ¿Es correcto?

--
Sergio Cambra .:: entreCables - Symbol Servicios Informáticos S.L. ::.
Nicolás Guillén 6, locales 2 y 3. 50.018 Zaragoza
T) 902 021 404 F) 976 52 98 07 E) sergio@entrecables.com
5312077471dcb23fb2942bd2d94741df?d=identicon&s=25 David Davidrv (davidrv)
on 2008-10-28 10:18
>
> ¿Has comprobado el codigo html que te genera? ¿Es correcto?
>
Pues me genera esto:

<form action="/works" method="post" onsubmit="new
Ajax.Updater('demanat', '/works', {asynchronous:true, evalScripts:true,
parameters:Form.serialize(this)}); return false;">
<td>Nombre</td><td><input id="nombre" name="nombre" type="text" /></td>
<input name="commit" type="submit" value="ok" />
</form>

Aunque con el <%= text_field "work", "nombre" %> me generaba:

<input id="work_nombre" name="work[nombre]" type="text" />

y tampoco funcionaba... parece que no pase los parámetros del text_field
al controlador y por eso me genera un registro vacío...

Un saludo,

David
Fbef10e8904c80c015dce56f3fa09bea?d=identicon&s=25 Sergio Cambra .:: entreCables - Symbol Servicios (Guest)
on 2008-10-28 10:30
(Received via mailing list)
El Tuesday 28 October 2008 10:18:56 David Davidrv escribió:
>
> Aunque con el <%= text_field "work", "nombre" %> me generaba:
>
> <input id="work_nombre" name="work[nombre]" type="text" />
>
> y tampoco funcionaba... parece que no pase los parámetros del text_field
> al controlador y por eso me genera un registro vacío...
>
> Un saludo,
>
> David

Ahora mira con firebug la peticion que manda al servidor. Te deberia
salir que
esta mandando por post el campo nombre o work[nombre]

--
Sergio Cambra .:: entreCables - Symbol Servicios Informáticos S.L. ::.
Nicolás Guillén 6, locales 2 y 3. 50.018 Zaragoza
T) 902 021 404 F) 976 52 98 07 E) sergio@entrecables.com
45742831d67c80d12cd7b24907b8d760?d=identicon&s=25 Sergio Gil Pérez de la Manga (Guest)
on 2008-10-28 10:36
(Received via mailing list)
2008/10/27 David Davidrv <ruby-forum-incoming@andreas-s.net>:
> <% form_remote_tag :update => "demanat", :url => {:controller =>
>
>
> ¿Alguna idea? Un saludo,
>
> david.
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ror-es mailing list
> Ror-es@lists.simplelogica.net
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>

Hola David,

Los métodos acabados en _tag son métodos de más bajo nivel que a veces
son necesarios pero que en general puedes obviar. Siendo un formulario
bastante estándar, yo intentaría reescribirlo usando remote_form_for
(http://apidock.com/rails/ActionView/Helpers/Protot...)
y text_field
(http://apidock.com/rails/ActionView/Helpers/FormHe...).

<% form_remote_for(@work) do |f| %>
<%= f.text_field :name %>
<% end %>

Es más, yo lo haría con form_for, y sólo cuando lo tuviera funcionando
correctamente le añadiría el _remote =;-)

--
Sergio Gil Pérez de la Manga
e-mail > sgilperez@gmail.com
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras
5312077471dcb23fb2942bd2d94741df?d=identicon&s=25 David Davidrv (davidrv)
on 2008-10-28 10:53
Ok, gracias chicos,

haré las dos cosas... Aunque con form_for funciona sin problemas.
Probaré form_remote_for y os cuento que tal ha ido!

Un saludo,

david.
1f2eadfb41362800ebc2cf211b91d0f7?d=identicon&s=25 javier ramirez (Guest)
on 2008-10-28 10:54
(Received via mailing list)
Hola,

> <form>
> <td>Nombre</td><td><input id="nombre" name="nombre" type="text" /></td>
> </form>
>

A veces me he encontrado con cosas que funcionan en unos browsers sí y
en otros no. En muchos casos el culpable era por anidamiento mal hecho
de tablas, y en el caso de Ajax, por intentar actualizar partes de una
tabla que no se pueden.

No estoy seguro si es legal poner un form como lo tienes tú, alegremente
con sólo dos TDs dentro, de hecho juraría que no. Entre un <tr> y un
<td> creo que no puedes tener nada.

Prueba a dejar tu form fuera de la tabla, a ver si es por eso.

saludos,

j

--
javier ramírez

..i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
..you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez
5312077471dcb23fb2942bd2d94741df?d=identicon&s=25 David Davidrv (davidrv)
on 2008-10-28 11:46
> haré las dos cosas... Aunque con form_for funciona sin problemas.
> Probaré form_remote_for y os cuento que tal ha ido!

No lo entiendo...

con:

<% form_for(@work) do |f| %>
    <tr>
    <td>Nom</td><td><%= f.text_field :nom %></td>
    </tr>
    <tr>
    <td colspan="3" align="center" class="submit"><%= f.submit "ok"
%></td>
    </tr>
<% end %>

funciona perfecto...

No debería funcionar también con <% remote_form_for(@work) do |f| %>

Igual és porqué tengo el formulario en un controllador que no es "works"
dónde está el "create"?

Lo extraño es que parece que no manda work[nombre] en ningun sitio
(aunque no he sabido mirarlo con el firebug)

Voy a quitarlo de los <td> aunque no me ha pasado nunca nada y siempre
hago formularios con <td> para quadrar-los...

Voy a ver..

Gracias cracks!
5312077471dcb23fb2942bd2d94741df?d=identicon&s=25 David Davidrv (davidrv)
on 2008-10-28 11:53
> Prueba a dejar tu form fuera de la tabla, a ver si es por eso.

IN-CRE-ÍBLE. Me he quedado a cuadros, he sacado el <%= text_field %> de
la table y me funciona.

Muchas gracias crack porque te aseguro que no se me hubiera ocurrido en
la vida!

Un saludo...

david.
Fbef10e8904c80c015dce56f3fa09bea?d=identicon&s=25 Sergio Cambra .:: entreCables - Symbol Servicios (Guest)
on 2008-10-29 10:08
(Received via mailing list)
El Tuesday 28 October 2008 11:46:27 David Davidrv escribió:
>     </tr>
> Igual és porqué tengo el formulario en un controllador que no es "works"
> Gracias cracks!
Si quieres usar <td> para colocar los campos, al menos ponlo dentro de
un
<table> y un <tr>

--
Sergio Cambra .:: entreCables - Symbol Servicios Informáticos S.L. ::.
Nicolás Guillén 6, locales 2 y 3. 50.018 Zaragoza
T) 902 021 404 F) 976 52 98 07 E) sergio@entrecables.com
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2008-10-29 10:25
(Received via mailing list)
2008/10/29 Sergio Cambra .:: entreCables - Symbol Servicios Informáticos
S.L. ::. <sergio@entrecables.com>

> Si quieres usar <td> para colocar los campos, al menos ponlo dentro de un
> <table> y un <tr>
>

O mucho mejor, olvidémonos de las tablas para maquetar, que ya estamos
en
2008 y canta un poco :-)
45742831d67c80d12cd7b24907b8d760?d=identicon&s=25 Sergio Gil Pérez de la Manga (Guest)
on 2008-10-29 10:46
(Received via mailing list)
On Wed, Oct 29, 2008 at 10:25 AM, Manuel González Noriega
<manuel.gonzalez.noriega@gmail.com> wrote:
> 2008/10/29 Sergio Cambra .:: entreCables - Symbol Servicios Informáticos
> S.L. ::. <sergio@entrecables.com>
>>
>> Si quieres usar <td> para colocar los campos, al menos ponlo dentro de un
>> <table> y un <tr>
>
> O mucho mejor, olvidémonos de las tablas para maquetar, que ya estamos en
> 2008 y canta un poco :-)
>

Hombre Manu, se me ocurren algunas razones legítimas para querer meter
un formulario en una tabla que no implican usar las tablas para
maquetar... está bien poder saber cómo se hace.

Creo que "no usar tablas para maquetar" no es "no usar tablas", sino
no usarlas "para maquetar" (te presento a mi amigo Pero Grullo =;-) ).
Las tablas tienen su uso, que es representar series de datos
tabuladas. ¿No se puede querer hacer alguno de esos datos editables?
¿O (este es un caso supertípico que tiende a aparecer antes o
despuésen casi cualquier proyecto) añadir a cada fila un ckeckbox y un
botoncito de "borrar seleccionados" al pie?

Hablo desde un importante desconocimiento de las técnicas de
maquetación, pero a priori a mí no me parecen "prácticas tabú" por
mucho que requieran mezclar formulario y tabla. ¿Lo son?

Un abrazo,


--
Sergio Gil Pérez de la Manga
e-mail > sgilperez@gmail.com
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras
7f82e7eaa0037b12d844f888afd0398c?d=identicon&s=25 Dani Doni (Guest)
on 2008-10-29 10:56
(Received via mailing list)
2008/10/29 Sergio Gil Pérez de la Manga <sgilperez@gmail.com>:
> Creo que "no usar tablas para maquetar" no es "no usar tablas", sino
> no usarlas "para maquetar" (te presento a mi amigo Pero Grullo =;-) ).
> Las tablas tienen su uso, que es representar series de datos
> tabuladas. ¿No se puede querer hacer alguno de esos datos editables?
> ¿O (este es un caso supertípico que tiende a aparecer antes o después
> en casi cualquier proyecto) añadir a cada fila un ckeckbox y un
> botoncito de "borrar seleccionados" al pie?
Efectivamente. Las tablas, como tu dices, se usan  para representar
datos tabulados. No para posicionar los elementos en la pàgina (
layout ).
Lo que si que es cierto es que a veces usar forms y tablas da pàginas
"no w3c compliant", y si la validez del documento html es prioritario,
no hay más "klanders" que usar otros elementos: divs, ul-li's, etc...

> Hablo desde un importante desconocimiento de las técnicas de
> maquetación, pero a priori a mí no me parecen "prácticas tabú" por
> mucho que requieran mezclar formulario y tabla. ¿Lo son?
Las tablas estan para usarlas, pero sobretodo, para usarlas bien.
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2008-10-29 10:56
(Received via mailing list)
2008/10/29 Sergio Gil Pérez de la Manga <sgilperez@gmail.com>

> ¿O (este es un caso supertípico que tiende a aparecer antes o después
> en casi cualquier proyecto) añadir a cada fila un ckeckbox y un
> botoncito de "borrar seleccionados" al pie?
>
> Hablo desde un importante desconocimiento de las técnicas de
> maquetación, pero a priori a mí no me parecen "prácticas tabú" por
> mucho que requieran mezclar formulario y tabla. ¿Lo son?
>
>
Mmmmm, me has hecho una finta con el cuerpo ;) No es lo mismo maquetar
un
form con tabla que hacer que una tabla sea editable ("formicizar la
tabla")
Lo primero no, lo segundo sí, como tú dices. A estas horas de la
madrugada
he estado poco sutil para hacer la distinción y lo he cerrado con un
brochazo un poco gordo.

En todo caso, el 80% de los casos que examinemos, será de la primera
clase,
la mala :-) Y es sabido que las buenas practicas del marcado estructural
siendo como son patrones, se aplican de la misma forma de los patrones.
Es
decir, "a menos que estés lo suficientemente bien informado para saber
cómo
y por qué este patrón no aplica en tu caso"
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (fxn)
on 2008-10-29 11:09
(Received via mailing list)
2008/10/29 Dani Doni <dani.doni@gmail.com>:

> Lo que si que es cierto es que a veces usar forms y tablas da pàginas
> "no w3c compliant", y si la validez del documento html es prioritario,
> no hay más "klanders" que usar otros elementos: divs, ul-li's, etc...

En el caso de los forms, tengo algun libro sobre HTML/CSS donde añaden
el corolario que en el caso de los forms tipicos con "aspecto
tabulado" acabas antes con una tabla y arreando. "Head First HTML With
CSS & XHTML" me viene a la cabeza. Yo lo comparto humildérrimamente.

Para que la página valide hay que poner los tags en su sitio claro.
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2008-10-29 11:19
(Received via mailing list)
2008/10/29 Xavier Noria <fxn@hashref.com>

>
> Para que la página valide hay que poner los tags en su sitio claro.
>


Una cosa es la validación (corrección formal) y otra las buenas
prácticas
estructurales. Una página maquetada con tablas puede validar
perfectisisimamente, pero incumple una buena práctica estructural
fundamental: no se maqueta con tablas.

Y no conozco ese libro, pero ya para empezar no me suena nada bien eso
de
"se acaba antes con ..." Tambien se "acaba antes ..." sin tests, o
metiendo
todo en el controlador o haciendo Model.find en las vistas o duplicando
código php en ruby ... En definitiva, que me parece muy mal consejo y me
hace mirar con mucha cautela el libro (por no hablar de que el uso de
XHTML
en el título ya da mala pinta)

Pero nos estamos yendo de cabeza al off-topic y tendremos que dejarlo
aquí
:-)
49b6123803e4f327144e991daab62f77?d=identicon&s=25 Daniel Rodriguez Troitiño (Guest)
on 2008-10-29 11:33
(Received via mailing list)
La prueba del algodón es simple: coged un screen reader (FireVox
http://firevox.clcworld.net/ debe ser el más sencillo de conseguir),
cerrad los ojos o quitaros las gafas :P, y dejad que lea la página. Si
os hartais de "start table", "start row", "start cell", es que vuestro
diseño no se debía haber realizado con tablas, en otro caso, supongo
que está bien.

Tschüss!
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (fxn)
on 2008-10-29 14:36
(Received via mailing list)
2008/10/29 Manuel González Noriega <manuel.gonzalez.noriega@gmail.com>:

>> En el caso de los forms, tengo algun libro sobre HTML/CSS donde añaden
>> el corolario que en el caso de los forms tipicos con "aspecto
>> tabulado" acabas antes con una tabla y arreando. "Head First HTML With
>> CSS & XHTML" me viene a la cabeza. Yo lo comparto humildérrimamente.
>>
>> Para que la página valide hay que poner los tags en su sitio claro.
>
>
> Una cosa es la validación (corrección formal) y otra las buenas prácticas
> estructurales.

Si, si claro.


> Una página maquetada con tablas puede validar
> perfectisisimamente, pero incumple una buena práctica estructural
> fundamental: no se maqueta con tablas.
>
> Y no conozco ese libro, pero ya para empezar no me suena nada bien eso de
> "se acaba antes con ..." Tambien se "acaba antes ..." sin tests, o metiendo
> todo en el controlador o haciendo Model.find en las vistas o duplicando
> código php en ruby ...

Ahi te has pasao generalizando mi comentario :-).

La serie "Head First" de O'Reilly es en mi opinion extaordinaria.
Naturalmente tiene autores competentes a los que les asumo que no
dicen gilipolleces gratuitas. Esa excepcion se encuentra en el
capitulo de forms con un titulo "To Table or Not to Table?" en un
libro que por lo demas enseña uso de HTML + CSS canonico y formalmente
impecable.

Ante el axioma "aqui no se maqueta en tablas ni una coma" hay que
observar que gente que esta en el tema admite esa excepcion en
concreto dada cuenta de que uno maqueta forms tabulares en HTML + CSS
y le sale tal castaña de codigo que no puede sino preguntarse si
merece la pena.

Y hay gente con criterio que cree que no siempre merece la pena (y
admite que es polemico).

Asi que yo soy de la opinion de que puedes tener un site de puta madre
super limpio y super CSS por todas las esquinas. Pero un listado de
clientes se formatea con una tabla (eso es un buen uso de las tablas,
como decia Sergio), y un form tabular lo formateo con una tabla porque
me parece una excepcion razonable a la regla general acerca de como se
hacen layouts modernamente.

Y entiendo que haya gente que no lo comparta.
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (fxn)
on 2008-10-29 15:11
(Received via mailing list)
Ah, y con esto termino.

El problema real de verdad en todo esto no es separacion
maquetacion/contenido. El problema de verdad que subyace es que CSS
por diseño es maquetacion de elementos que siguen un flujo.

Por tanto, por como es CSS hacer cosas con layout tabular en CSS es
una castaña y vas en contra de como esta pensado. Si CSS permitiera
decir "quiero una pagina con un header y una parte principal de 3
columnas con estos anchos relativos" sin tener que ir con floats ni
clears ni ecuaciones diferenciales que hay que resolver para algunas
cosas verias que todo el mundo usaria esas directivas "tabulares" sin
mas problema y sin ningun conflicto interno.

Ocurre que CSS no permite expresar ese tipo de cosas, y por eso
entiendo que haya gente que ante un problema muy concreto como es el
de los forms decida que ya le supera el umbral.
1f2eadfb41362800ebc2cf211b91d0f7?d=identicon&s=25 javier ramirez (Guest)
on 2008-10-29 15:51
(Received via mailing list)
> Ocurre que CSS no permite expresar ese tipo de cosas,

ya sí  http://www.w3.org/TR/CSS2/tables.html

muchos browsers modernos ya lo soportan y de hecho incluso IE8 parece
que lo soportará también. Así podrás pintar divs, y usar css para el
posicionamiento en formato tabular sin recurrir a floats ni cosas del
estilo. Y como sólo aplica a la clase del objeto y no al objeto en sí
mismo, no es semántico con lo que no hay problemas filosóficos.

saludos,

--
javier ramírez

..i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
..you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (fxn)
on 2008-10-29 16:25
(Received via mailing list)
2008/10/29 javier ramirez <jramirez@aspgems.com>:
>
>> Ocurre que CSS no permite expresar ese tipo de cosas,
>
> ya sí  http://www.w3.org/TR/CSS2/tables.html
>
> muchos browsers modernos ya lo soportan y de hecho incluso IE8 parece
> que lo soportará también.

Yo tengo entendido que esa parte de la spec en cuanto a HTML solo
aplica a tablas. No significa que puedas montar elementos maquetados
con un "lenguaje tabular". De ahi que para HTML especifique que:

   table-row-group (In HTML: TBODY)

por ejemplo.

Vamos, que no sirve para decir que los DIVs hijos de #signup-form
tiene un display "table-row". Segun entiendo es un estilo ilegal en
HTML pero el navegador debe saber parsearlo y hacer como si no
estuviera ahi:

"User agents may ignore these 'display' property values for HTML
documents, since authors should not alter an element's expected
behavior."

Pero tambien es verdad que he visto lo de IE8... Desde luego que si
algun dia se pudieran maquetar partes de la pagina de esa manera
ademas de lo que ya se puede hacer seria genial.
9baec5b20d55fcdced48dadd94d96db5?d=identicon&s=25 Jaime Mora Ramones (Guest)
on 2008-10-29 17:27
(Received via mailing list)
El 29 de octubre de 2008 7:35, Xavier Noria <fxn@hashref.com> escribió:

>
Simplemente muchas gracias Xavier !  Es precisamente la linea de
pensamiento
que a nosotros los simples mortales nos ayuda en el dia a dia para
cumplir
los multiples compromisos que tenenos.

Un abrazo.
Saludos cordiales.
5312077471dcb23fb2942bd2d94741df?d=identicon&s=25 David Davidrv (davidrv)
on 2008-10-29 19:14
Sergio Cambra .:: entreCables - Symbol Servicios
  wrote:
> El Tuesday 28 October 2008 11:46:27 David Davidrv escribió:
>>     </tr>
>> Igual és porqué tengo el formulario en un controllador que no es "works"
>> Gracias cracks!
> Si quieres usar <td> para colocar los campos, al menos ponlo dentro de
> un
> <table> y un <tr>
>
> --
> Sergio Cambra .:: entreCables - Symbol Servicios Informáticos S.L. ::.
> Nicolás Guillén 6, locales 2 y 3. 50.018 Zaragoza
> T) 902 021 404 F) 976 52 98 07 E) sergio@entrecables.com

Estan metidos en un <table> i un <tr>, simplemente los había omitido en
mi consulta para escribir menos.

Y NO maqueto con tablas, simplemente las uso "alguna vez" para
formularios con muchos campos (qüestión de mandra!!)

jejeje
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2008-10-29 22:20
(Received via mailing list)
2008/10/29 Xavier Noria <fxn@hashref.com>

> > Y no conozco ese libro, pero ya para empezar no me suena nada bien eso de
> > "se acaba antes con ..." Tambien se "acaba antes ..." sin tests, o
> metiendo
> > todo en el controlador o haciendo Model.find en las vistas o duplicando
> > código php en ruby ...
>
> Ahi te has pasao generalizando mi comentario :-).


Lo siento mucho si ha sido así, cosas de contestar rápido y estando a
mil
cosas :-)

>
>
> La serie "Head First" de O'Reilly es en mi opinion extaordinaria.
> Naturalmente tiene autores competentes a los que les asumo que no
> dicen gilipolleces gratuitas. Esa excepcion se encuentra en el
> capitulo de forms con un titulo "To Table or Not to Table?" en un
> libro que por lo demas enseña uso de HTML + CSS canonico y formalmente
> impecable.


Me alegro, no he criticado el libro, que no conozco. Sólo he dicho que
me
sonaba raro eso que decías



>
>
> Ante el axioma "aqui no se maqueta en tablas ni una coma" hay que
> observar que gente que esta en el tema admite esa excepcion en
> concreto dada cuenta de que uno maqueta forms tabulares en HTML + CSS
> y le sale tal castaña de codigo que no puede sino preguntarse si
> merece la pena.
>

En el desarrollo web los axiomas suelen tener poca eficacia. Como dije
en el
primer mail a Sergio, todas las buenas prácticas de marcado llevan el
corolario "a menos que sepas bien lo que estás haciendo". En el momento
en
el que se comprueba que las dos personas que discuten un punto tienen
claros
los principios, los porqués y los cómos, no tiene mucho sentido discutir
sobre casos teóricos.

 an

>
Mmmm, sí, ahora ya no estoy seguro de qué estamos discutiendo :-) Los
datos
tabulares se formatean con tablas. Estos datos tabulares pueden ser un
formulario y entonces también se usa una tabla. ¿En qué estábamos en
desacuerdo? :D

Resumiendo, las principales maneras de maquetar un formulario son, a
saber,

a) Con elementos de bloque genérico (div)

b) Con p

c) Como definition lists (dl)

d) Como tablas

Y de ahí, a elegir la que corresponda en cada momento, que es en
definitiva
a lo que se reduce el arte del marcado estructural
This topic is locked and can not be replied to.