ruby on rails - En rieles, ya sea para usar formularios auxiliares o no?

ruby-on-rails performance

Question

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?

Answer 1

Creo que los helper de formularios son 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.

Answer 2

Definir 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. Quizás ni siquiera lo hayas obtenido exactamente 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.

Answer 3

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

El siguiente 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 %>

genera este 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>

Puede escribir el html usted mismo, pero al usar los ayudantes de formulario debe escribir menos y hacer que la creación del formulario dependa menos 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.

Answer 4

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