2009-01-10 15 views
6

En rieles, ¿se recomienda utilizar ayudantes de formulario? Internamente, todo se reduce a HTML simple, ¿por qué no escribir el html directamente? Obviamente, el rendimiento será mejor al escribir html directo que con ayudantes. ¿Utilizar form helpers como una convención o algo que los desarrolladores de rails deben seguir?En rieles, ya sea para utilizar formularios auxiliares o no?

Respuesta

13

Define el rendimiento. Su rendimiento o las aplicaciones? Supongamos que tiene el mismo fragmento de rhtml en todas sus vistas. Digamos que lo tienes en miles de lugares. Tal vez incluso no lo ha obtenido exactamente lo mismo en todos los lugares. Ahora su cliente quiere cambiar esto (tal vez diferente orden de presentación o algo así). Te llevará un tiempo hacerlo en todos los puntos de vista, ¿verdad? Y es probable que no lo haga bien la primera vez. Lo más probable es que sigas recibiendo informes de errores durante años en lugares que te has perdido para cambiar.

El cliente terminará pagando mucho por ese "rendimiento" ganado. Tal vez cientos de horas de trabajo. Tal vez decenas de miles si evitas el principio DRY por principio. Piense en todos los servidores y en toda la RAM que podría comprar para esas horas de trabajo. Si ella gastara todo en hardware su aplicación podría correr cientos de veces más rápido. Piense en todas las cosas divertidas con las que podría estar trabajando en lugar de monkear cambiando fragmentos de html.

+1

Uno de los beneficios de Rails y DRY es un caso como el delineado, ¡gracias por señalar esto! El rendimiento es más que la velocidad de renderizado, también es la velocidad de desarrollo. –

+0

Gran argumento. – Zequez

4

Creo que form helpers es un reflejo del principio DRY (no te repitas). En lugar de escribir el mismo código para realizar tareas similares, crear un ayudante de formulario que le permita reutilizar ese código es el camino a seguir. De esta forma, si necesita hacer un cambio o una solución, solo necesita hacerlo en un solo lugar. También ayuda a que su código sea más compacto y legible para abstraer una acción compleja en un asistente de formularios. Lo mismo es cierto para las vistas parciales, aunque las vistas parciales tienden a encapsular marcas más complejas que las de un asistente de formularios.

3

Los ayudantes de formularios son especialmente útiles para permitir que los rieles manejen la creación de formularios según su modelo. Para citar el ejemplo de la documentación de la API:

El código

<% form_for :person, @person, :url => { :action => "create" } do |f| %> 
    <%= f.text_field :first_name %> 
    <%= f.text_field :last_name %> 
    <%= submit_tag 'Create' %> 
<% end %> 

siguiente genera este código HTML

<form action="/persons/create" method="post"> 
    <input id="person_first_name" name="person[first_name]" size="30" type="text" /> 
    <input id="person_last_name" name="person[last_name]" size="30" type="text" /> 
    <input name="commit" type="submit" value="Create" /> 
</form> 

Se puede escribir el código HTML por sí mismo, pero usando los helpers de formularios que tienen que escriba menos y haga que la creación del formulario sea menos dependiente de la implementación de los rieles. Siempre obtiene un formulario que escribe datos en su modelo cuando presiona el botón de enviar. Si los desarrolladores de rieles alguna vez cambian la implementación de esto, automáticamente obtendrá la salida correcta de html de sus ayudantes. Si hubiera escrito el html manualmente, tendría que actualizarlo todo para reflejar los cambios en el funcionamiento interno de los rieles.

+0

Gracias por la respuesta. Sin embargo, me gustaría saber, ¿qué tan malo es utilizar formularios desde el punto de vista del rendimiento? – Chirantan

1

Parece bueno cuando un desarrollador tiene el mismo nombre para la clase, identificación y ningún valor para un campo de entrada si necesita un nombre diferente y también le da valor, entonces tiene que escribir <% = text_field_tag ​​"name",: value => "valor",: id => "id",: clase => "" clase%> y para el mismo html puede ser < input type = "text" value = "value" class = "class" name = "nombre" id = "id" /> piensan ahora sobrecarga 1. evaluar primer ayudante en html 2. ahora también considerar la longitud de la de ayudante también tenemos que escribir:, => 3. a veces se te olvida usar: o, por error entonces creo que preferimos html en ese caso Y una cosa si tu servidor recibe muchas solicitudes que se llenan demasiado y el tiempo de respuesta aumentará porque <% =% > debería tener que ejecutar

Cuestiones relacionadas