Aplicar estilos a <%= text_field_tag %>

Community ES
1

Buenas,

Soy bastante nuevo en RoR. El caso es que me gustaria aplicar una clase
css
(ej class=“red”) a la siguiente linea:

<%= text_field_tag(“merchant_name”, “By Name”) %>

Como lo puedo hacer?

Gracias y un saludo

2

Yo lo haría:

<%= text_field_tag “merchant_name”, “By name”, :class => “red” %>

salu2,

Javi

El 27/06/07, Hector Muñoz [email protected]
escribi

3

yo no le pondría “red” porque no es semántico
aún así yo accedería al elemento mediante input, ponerle una clase
creo que no sería necesario

El 27/06/2007, a las 12:17, Javier Vidal P.
escribió:

Yo lo haría:

4

Fernando S. wrote:

Gracias y un saludo

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

Te lo digo de memoria pero creo que es algo como

<%= text_field_tag “merchant_name”, “By name”, {:style =>
“class="red"”} %>

–
jabberID: [email protected]
blog: http://llibertat.wordpress.com
SIP: [email protected]

5

El 27/06/2007, a las 15:04, Fernando S. escribió:

no entiendo que quieres decir con acceder al elemento mediante input.

si por ejemplo tienes

Title:

desde el css puedes hacer

p input {
border: 1px solid #f00
}

corrígeme si las tags están mal, con tanto helper ya no me acuerdo de
HTML!
en general yo trato de minimizar el número de selectores innecesarios
y agruparlos bajo divs para luego llamarlos desde javascript o css

un saludo!
marze

6

Interesante,

O sea que en realidad a todos los efectos este helper (text_field_tag )
no
es mas que un input en xhtml. Y lo mismo pasara con todos (mas o menos)
correcto?

un saludo y gracias

El día 27/06/07, Marze [email protected] escribió:

7

Hola gracias a todos por las respuestas,

Funciono perfectamente. Hoal MArze, “Red” era solo un ejemplo (tienes
razon
no es semantico) pero no entiendo que quieres decir con acceder al
elemento
mediante input.

gracias de nuevo y un saludito

El día 27/06/07, Marze [email protected] escribió:

8

efectiviwonder
lo único que haces es generar código
yo siempre pienso en una trituradora de carne, :slight_smile:

es el poder de rails en tus manos…

El 27/06/2007, a las 15:26, Fernando S. escribió:

9

Aunque esto ya tiene más que ver con maquetación en css que con rails,
tan sólo comentar que el ‘problema’ de acceder directamente al elemento
input es que también afectaría al resto de elementos de tipo input
aparte del textfield(botones, radio buttons, checkboxes, selector de
ficheros, etc.). Por eso en este caso yo sí que suelo crear una clase
específica para cada input:

<%= text_field_tag :nombre, :valor, :class => “textfield” %>

y luego meto en la hoja de estilos algo tal que
así:
input.textfield {
…
}

Saludos.

Marze
escribió:> yo no le pondría “red” porque no es semántico

10

On 6/27/07, Borja Martín [email protected] wrote:

Aunque esto ya tiene más que ver con maquetación en css que con rails,
tan sólo comentar que el ‘problema’ de acceder directamente al elemento
input es que también afectaría al resto de elementos de tipo input
aparte del textfield(botones, radio buttons, checkboxes, selector de
ficheros, etc.). Por eso en este caso yo sí que suelo crear una clase
específica para cada input:

O si no te importa IE (o si estás en una intranet en la que tus
usuarios usan browsers decentes):

input[type=“text”]
{
/* Solo para <input type="text /> */
}

(si no me equivoco, esto funciona también en IE7)

11

On Jun 28, 2007, at 4:43 AM, Damian J. wrote:

O si no te importa IE (o si estás en una intranet en la que tus
usuarios usan browsers decentes):

input[type=“text”]
{
/* Solo para <input type="text /> */
}

Para hacer esto portable suelo tirar de Prototype, en application.js:

function set_style_for_textfields() {
var set_style = function (input) {
…
};
$$(‘input[type=“text”]’).each(set_style);
$$(‘input[type=“password”]’).each(set_style);
}
Event.observe(window, ‘load’, set_style_for_textfields);

Tiene el contra, por eso, de que si la pagina carga lenta pueden
llegar a verse los widgets sin estilo por un momento.

– fxn

12

El 27/06/2007, a las 18:42, Borja Martín escribió:

y luego meto en la hoja de estilos algo tal que así:

cierto, yo tb lo hago con textfield xq a veces no le quieres aplicar
el mismo estilo

13

On Jun 28, 2007, at 9:55 AM, Manuel González Noriega wrote:

Hola Xavier,

disculpa si me falta algún dato clave para entender esto, pero
¿utilizas JS para definir un estilo CSS? ¿Por qué?

La situacion es que quieres un mismo estilo para todos los campos de
texto de la aplicacion. La manera CSS fina de hacerlo es

input[type=text] {
…
}

Pero sucede que IE6 no lo soporta. Por lo tanto pasas a una clase:

.estilo-para-campos-de-texto {
…
}

Bien, ahora como aplicamos la clase?

Una solucion es acordarte en cada textfield de ponerla a mano. Esto,
para nosotros Raileros, si el web site tiene mas de dos paginas ni
soñarlo. Otra solucion es redefinir helpers o crear algun wrapper. Y
otra es meter la clase con JavaScript, que es la que suelo usar
porque es robusto y sencillo. Piensa que en el JavaScript lo unico
que haces en este caso es meter la clase como lo harias en HTML:

function set_style_for_textfields() {
  var set_style = function (input) {
      input.addClassName("estilo-para-campos-de-texto");
  };
  $$('input[type="text"]').each(set_style);
  $$('input[type="password"]').each(set_style);
}
Event.observe(window, 'load', set_style_for_textfields);

– fxn

P.D.: Seguramente se podria meter el selector en el CSS y condicionar
ese onload a que el navegador sea IE6. Necesitas tener dos cachos de
CSS iguales salvo el selector, pero te quitarias el flip-flop del
principio en el resto de navegadores.

14

On 28/06/07, Xavier N. [email protected] wrote:

}

Bien, ahora como aplicamos la clase?

Sí, parece que había entendido el problema, pero no estoy en absoluto
de acuerdo con esa solución. Si se quiere dar soporte a agentes de
usuario sin capacidad de interpretar selectores CSS de atributo, se
hace mediantes ids/clases. De lo contrario, agentes de usuario sin
javascript (o si el javascript tiene algún problema) se quedarían con
los inputs sin el estilo adecuado. No me parece robusto y además viola
innecesariamente la separación en capas.

Una cosa es que nos guste la sencillez y el ahorro de trabajo y otra
que acostumbrarnos a “the rails way” nos aparte de seguir otras buenas
prácticas de más bajo nivel :wink:

–
Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o simplelogica.net
Recuerda comer mucha fruta y verdura.

15

On Jun 28, 2007, at 11:42 AM, Manuel González Noriega wrote:

Sí, parece que había entendido el problema, pero no estoy en absoluto
de acuerdo con esa solución. Si se quiere dar soporte a agentes de
usuario sin capacidad de interpretar selectores CSS de atributo, se
hace mediantes ids/clases. De lo contrario, agentes de usuario sin
javascript (o si el javascript tiene algún problema) se quedarían con
los inputs sin el estilo adecuado. No me parece robusto y además viola
innecesariamente la separación en capas.

Desde luego, si quieres que el site funcione sin JavaScript y ademas
tenga el estilo OK en campos de textos esa solucion no te vale.

Mis aplicaciones solo funcionan con JavaScript. Estamos en el 2007.
No es que abuse de ello pero asumo Ajax y siempre cae algo en
application.js. Deshabilitar JavaScript es algo licito por parte del
usuario, pero mi opcion es no invertir esfuerzo en darle soporte.

– fxn

16

On 28/06/07, Xavier N. [email protected] wrote:

On Jun 28, 2007, at 11:42 AM, Manuel González Noriega wrote:

Mis aplicaciones solo funcionan con JavaScript. Estamos en el 2007.
No es que abuse de ello pero asumo Ajax y siempre cae algo en
application.js. Deshabilitar JavaScript es algo licito por parte del
usuario, pero mi opcion es no invertir esfuerzo en darle soporte.

Pues estás en tu derecho de hacer lo que quieras, otra cosa son los
posibles problemas éticos o legales (1) que te puedas llegar a
encontrar.

Solo me queda animar a terceros a que, dentro del enorme respeto y
admiración que me causan el trabajo de Xavier y a sus aportaciones a
la lista, en este tema concreto y solo en este tema NO le hagan caso y
apuesten por otras metodologías (2). Para más dudas, accesoweb (3)

(1) SIDAR: Legislación española sobre accesibilidad en la Sociedad de la Información.
(2) Progressive enhancement - Wikipedia
(3) Yahoo | Mail, Weather, Search, Politics, News, Finance, Sports & Videos

–
Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o simplelogica.net
Recuerda comer mucha fruta y verdura.

17

On Jun 28, 2007, at 12:00 PM, Manuel González Noriega wrote:

Solo me queda animar a terceros a que, dentro del enorme respeto y
admiración que me causan el trabajo de Xavier y a sus aportaciones a
la lista, en este tema concreto y solo en este tema NO le hagan caso y
apuesten por otras metodologías (2). Para más dudas, accesoweb (3)

Desde luego que esto me parece fenomeno Manuel.

Mi postura es que depende de la aplicacion. Esta bien que una
PlayStation este preparada para invidentes, pero los que programan
Collin McRae me parece bien que lo hagan para gente que ve y puede
manejarse con destreza.

Si se trata de un site de la administracion, la web de un
periodico, …, pero hay ciertas aplicaciones comerciales para las
que sencillamente no me planteo que funcionen sin JavaScript.

– fxn

18

On 6/28/07, Xavier N. [email protected] wrote:

Si se trata de un site de la administracion, la web de un
periodico, …, pero hay ciertas aplicaciones comerciales para las
que sencillamente no me planteo que funcionen sin JavaScript.

Siento no estar de acuerdo :frowning:

Precisamente porque estamos en 2007 tenemos que preocuparnos por hacer
las aplicaciones accesibles sin JavaScript, ahora es cuando la Web se
está abriendo a dispositivos que no son navegadores de escritorio
(consolas, móviles…), y es bastante probable que estos dispositivos
tengan un acceso limitado a JavaScript (incluso algunos no lo
tendránen absoluto).

Y tengamos en cuenta otra cosa, si tu aplicación no funciona sin
JavaScript, tampoco funciona si tu JavaScript casca. Es decir,
estáshaciendo millones de tests en Rails para asegurarte de que tu backend
es a prueba de bomba y luego delegas el funcionamiento de tu
aplicación en la tecnología menos estandarizada que hay en la Web
(JavaScript, con todos sus niveles de DOM, todas las diferencias de
implementación entre navegadores y todos esos memory leaks y demás).

–
David A., el único desarrollador con una orden de alejamiento de
Jeffrey Zeldman
Simplelogica.net, ahora con un 33,3% más de intromisión en listas de correo

Cuando no hago otra cosa escribo en mildiez.net

19

On 28/06/07, Xavier N. [email protected] wrote:

On Jun 28, 2007, at 4:43 AM, Damian J. wrote:

Para hacer esto portable suelo tirar de Prototype, en application.js:

…

Event.observe(window, ‘load’, set_style_for_textfields);

Hola Xavier,

disculpa si me falta algún dato clave para entender esto, pero
¿utilizas JS para definir un estilo CSS? ¿Por
qué?

Manuel, que
piensa que eres una excelente persona y medra en torno a
http://simplelogica.net y/o simplelogica.net
Recuerda comer mucha fruta y verdura.

20

Aprovechando la ocasion para complicarles mas la vida, esta seria la
forma mas elegante de resolver el problema usando solo Rails.

Si se van al codigo fuente veran que helpers como “text_field” y
“select” llaman a su vez a “text_field_tag” y “select_tag”, y estos a
su vez llaman a “tag” o “content_tag”. Lo ideal seria que estas dos
funciones tuvieran logica que, cuando el tag tiene un atributo
“type”, insertaran un “class” apropiado.

Como esto es Ruby, podemos redefinir la funcion a nuestro gusto:

module ActionView::Helpers::TagHelper
def tag_with_automatic_type_class(name, options = nil, open = false)
options = options.with_indifferent_access
if options[:type]
options[:class] = options[:class].blank? ? " " : (options
[:class] + " ")
options[:class] += “type_#{options[:type]}”
end
tag_without_automatic_type_class(name, options, open)
end

alias_method_chain :tag, :automatic_type_class
end

La linea
options = options.with_indifferent_access
permite accesar el hash con simbolos o strings indiferentemente. Esto
es necesario para poder manejar tag(:class => “blah”) y tag(“class”
=> “blah”) sin problemas.

La linea
options[:class] = options[:class].blank? ? " " : (options
[:class] + " ")
considera el caso donde ya hay una clase definida, donde hay que
agregar la clase adicional separada por espacios

La linea
tag_without_automatic_type_class(name, options, open)
es la llamada al metodo “tag” original

Y finalmente, la linea
alias_method_chain :tag, :automatic_type_class
es donde se redefine el metodo “tag” original como
“tag_without_automatic_type_class” y es reemplazado por el
“tag_with_automatic_type_class” que definimos previamente.

Listo. Con esto, cualquier llamada a cualquier tag que tenga
“type=‘algo’” tambien tendra “class=‘type_algo’”