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
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.
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.
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.
Gracias por la respuesta. Sin embargo, me gustaría saber, ¿qué tan malo es utilizar formularios desde el punto de vista del rendimiento? – Chirantan
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
- 1. Método automático para establecer el tabindex utilizando formularios auxiliares
- 2. Anula los auxiliares de rieles con acceso al original
- 3. Métodos auxiliares en C#: ¿Estático o no estático?
- 4. Configurar clase CSS predeterminada para los métodos auxiliares del generador de formularios de Rails
- 5. ¿cómo uso los auxiliares de rieles en trabajos de resquebramiento?
- 6. Diferencia entre archivos auxiliares y archivos lib en rieles
- 7. Cuándo utilizar la función "property" incorporada: funciones auxiliares y generadores
- 8. Rieles/gamba: ¿cómo utilizo los auxiliares de rieles dentro de una clase de gambas?
- 9. Incluye rieles auxiliares de tiempo en una aplicación que no es de Rails Ruby
- 10. Observadores de rieles: cuándo y cuándo no utilizar observadores en rieles
- 11. Múltiples formularios en la misma página con rieles
- 12. Cómo utilizar variables ya definidas en ConfigParser
- 13. DB: ¿Para utilizar la columna de identidad o no?
- 14. Ruby: ¿Cómo establecer una variable ya sea a 0 o, si ya está establecido, se incrementan en 1
- 15. rieles consola - utilizar image_tag método
- 16. donde poner métodos auxiliares solo para controladores?
- 17. dónde almacenar funciones auxiliares?
- 18. Una variable que no sea pública o
- 19. Cómo utilizar "_blank" o "_new" en Rails
- 20. ¿Puedo hacer que el constructor primario sea privado y mantener abiertos los constructores auxiliares en Scala?
- 21. Rieles (o Ruby): Sí/No en lugar de Verdadero/Falso
- 22. div o sección para formularios con un encabezado en html5?
- 23. Detectar en Rails after_filter ya sea que estemos renderizando o redirigiendo
- 24. ¿Debo crear un blog en rieles o usar algo que ya existe?
- 25. Rieles: cómo agregar protección CSRF a formularios creados en javascript?
- 26. Rieles - Cookies o Tienda de registros activos para sesiones
- 27. Cuándo utilizar!() O! = Cuando, si no nula
- 28. Cambiar el protocolo a https en todos los auxiliares de rieles
- 29. Obtener un std :: ostream ya sea desde std :: cout o std :: ofstream (archivo)
- 30. hacer que mi archivo legible ya sea como Perl o HTML
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. –
Gran argumento. – Zequez