Etiquetas: otro, javascript, frameworks
Hombre JQuery te ayuda bastante a lidiar con las diferencias entre navegadores, por ejemplo para cancelar la burbuja de eventos como comentabas o para visualizar o no un elemento.
Por supuesto JQuery es una librería de más bajo nivel que otras como EXT, SmarClient o incluso GWT. La guerra que JQuery si es posible que este ganando es la que le enfrenta a otras librerías que ofrecen una funcionalidad similar como prototype o mootools.
Si vas ha hacer una aplicación de gestión en la que necesitas widgets y no quieres pegarte con el CSS y el html (aunque nos guste o no están ahí abajo y al final no te vas a librar de ellos tan facilmente :P ) desde luego que hay frameworks que se adaptan mejor que JQuery.
No sé, pero creo yo que sería una buena idea que, cuando alguien mande una noticia primero escriba la noticia de forma objetiva y luego ponga su opinión personal como comentario.
Más que nada lo digo porque la noticia queda de todo menos informativa. ¿Una anécdota de un HTML mal formado (ul únicamente puede contener li pero no otro ul directamente) que te dió problemas? ¿A qué viene eso?
(Esto, por supuesto, es sólo mi opinión)
Hola Anonimo,
lo del ul y li es simplemente porque estaba programando un widget de Arbol y justamente me encontre con ese problema y lo peor fué llegar a la conclusión de que eso era lo que estaba fallando. Pq no tenía ni idea de pq en FF me funcionaba y en IE no.
Y viene a cuento pq jQuery no me hubiera ayudado mucho en mi problema. El que lo tendrá facil es el que use el Arbol que he hecho.
Respecto a lo primero del comentario personal , tengo que decirte que me gustan más la noticias en las que las que el autor da la noticia y expone su opinión. Además al publicar la noticia en el portal se marca como "opinión".
Saludos.
El asunto, logongas, es que es muy diferente (a) dar una noticia, (b) comentar una noticia y (c) contar una historia sobre lo que te pasó un día con la excusa de una noticia. Este caso es claramente (c).
Por lo demás, jQuery no te habría ayudado con tu HTML mal formado... pero lo que quieres decir es que Ext, Dojo o lo que sea ¿te habrían ayudado a resolver un problema que no tiene nada que ver con Javascript y casi nada con el DOM pero sí con un HTML mal formado? ¿O quizá es que lo que intentas decir es que preferirías que el mundo se concentrara en resolver ese otro problema antes que avanzar en otras cosas?
Más aún, volviendo a leer... dices: "Una duda que tiene la gente al empezar con CSS es si usar "display" o "visibility".¿jQuery me va a ayudar en eso?"
Y me pregunto yo ahora ¿realmente quieres que se pare todo el mundo y se concentre en tus problemas? ¿Qué coño tiene que ver no saber lo que significan display y visibility con el hecho de que MS incluya jQuery en sus herramientas de desarrollo?
logongas
creo que deberías leerte un manual de jquery antes de escribir tus opiniones
Saludos
¿Por qué será que la mala educación siempre aparece mucho más marcada en comentarios anónimos?
No tengo conocimientos para hablar de jQuery pero sí que agradezco a logongas que haya publicado la noticia, incluida su reflexión.
Saludos cordiales.
¿Qué reflexión ni qué ocho cuartos?
MS ya tenine un framework javascript: MAL = Microsoft Ajax Library
Igual con su nombre nos quería dar alguna pista sobre su futuro ;-)
Igual el tono del primer anónimo no es el correcto, pero si hay que reconocer que el desarrollo de esta noticia dista mucho del resto que podemos encontrar en la portada de JavaHispano. Además, su contenido poco tiene que ver con el título que presenta...
Una cuestión al autor. ¿Has comprobado que tengas el DOM construido correctamente? ¿Sabes que los únicos hijos aceptados de un ul son los tags li? ref: http://developer.mozilla.org/En/HTML/Element/Ul
Yo estoy desarrollando con jQuery una aplicación "empresarial" y me está salvando la vida. Efectos, Ajax, manipulación del DOM... todo de manera sencilla y rápida.
si quieres esconder un botón prueba con:
$("#idMyButton").hide();
donde idMyButton es el id del elemento que quieras ocultar. Y si lo quieres mostrar de nuevo:
$("#idMyButton").show();
Un saludo.
VictorR:
Una cuestión al autor. ¿Has comprobado que tengas el DOM construido correctamente? ¿Sabes que los únicos hijos aceptados de un ul son los tags li?
Eso no es correcto, según el W3C las listas se pueden anidar, otra cosa es que lo soporten correctamente los navegadores o que lo implementen del mismo modo.
Personalmente, construyo aplicaciones con frameworks que me permitan abstraerme del navegador y me proporcionen riqueza a nivel de controles. En estos momentos, uso el Richfaces, que me parece una maravilla.
Mantengamos las formas o luego que nadie se extrañe si su comentario no sale, gracias. Todo se puede expresar con educación o si no es mejor callar.
El primer anonimo creo que ha sido bastante correcto, luego la cosa ya empieza a degenerar. Yo personalmente voté en contra de la noticia, por que me parece más algo para un blog, es de JavaScript y Microsoft y la estructura/titul/conclusiones no me pareció clara, pero si al resto de la comunidad le interesa y votó a favor, pues sale publicada y listo. A partir de ahí se puede discrepar, pero siempre desde el respeto.
En cuanto a frameworks JavaScript... muchos tienen diferentes objetivos y sirven para diferentes cosas, así que compararlos en general o declarar un ganador me parece que tiene poco sentido.
Mis 2ec
Hola VictorR,
Si lo del "li" y "ul" ya lo solucioné. El problema es que yo quería un "Tree" y no pelearme con los tag "li" y "ul", pero como en HTML no existe el "Tree", tengo que "remangarme", bajar a nivel de "li" y "ul" , usar el DOM, etc, para acabar haciendomelo.
Para todo eso jQuery está muy bien y facilita mucho las cosas. Sin embargo lo que yo quiero es una librería que me "proporcione" el "Tree" no una que me "facilite" hacer un "Tree".
Así que mi opinión es que jQuery debería ser usado por gente que hace librerías de "Alto Nivel" y nosotros usar esas librerías de "Alto Nivel" y no descender a niveles de "DOM".
Saludos.
<UL>
<LI> ... Level one, number one...
<OL>
<LI> ... Level two, number one...
<LI> ... Level two, number two...
<OL start="10">
<LI> ... Level three, number one...
</OL>
<LI> ... Level two, number three...
</OL>
<LI> ... Level one, number two...
</UL>
en XHTML 1.0 deberíamos abrir y cerrar todos los tags (<li>...</li>).
Bonito ejemplo con la palabra DEPRECATED en mayúsculas justo delante.
Al último anónimo, es el ejemplo que pone la propia W3C, y aunque esté marcado como obsoleto no ha perdido vigencia. Si era correcto hace 6 meses para la versión 4.01, 6 meses después para la misma versión sigue siendo correcto.
logongas: "Sin embargo lo que yo quiero..."
Es decir, que me das la razón. Que tu lo que quieres es que no se solucionen otros temas mientras no se solucionen tus problemas. Que da igual si es buena idea o no que Microsoft incluya jQuery, lo que importa es que tú quieres un árbol y mientras no tengas tu árbol todo lo que se haga en el universo será contestado con un "pues sí, pues vale, pero yo quiero un árbol y esto no me lo soluciona".
Que sale una nueva versión de Hibernate? "pues sí, pues vale, pero yo quiero un árbol y esto no me lo soluciona". Que se lanza una nueva versión de las librerías Boost de C++? "pues sí, pues vale, pero yo quiero un árbol y esto no me lo soluciona". Que se soluciona el calentamiento globala o se cura el cáncer? "pues sí, pues vale, pero yo quiero un árbol y esto no me lo soluciona".
coutemeier, me da la sensación de que han pasado ya más de seis meses ddesde Diciembre de 1999, que es la fecha del documento que estás citando. Vamos, no sé si es eso lo que pretendías decir, pero parece que digas que ese documento es de hace 6 meses.
Tranquilo Anonimo de las 10:33,
no te preocupes tanto del calentamiento global.
Ya hace años que me hice mi MenuBar,ToolBar,LaterlaMenu,Grid,PopMenu, etc. Y tal y como creo que deberían hacerse. Me falta el Tab y el Tree (que ya lo hice la semana pasada).
Pero creo que indicando lo que a mi me interesa (que te repito que ya me lo hecho ) puedo hacer ver a la gente la diferencia entre frameworks JavaScript de bajo nivel como jQuery o de alto nivel como ExtJS.
@countemeier: como ves tu ejemplo, inserta los tags ol o ul dentro de otro tag li y no directamente dentro del tag ul como logongas comentaba en la noticia.
@logongas: en cuanto a que podría haber un framework de más alto nivel que te facilite hacer un "Tree", estoy deacuerdo contigo. Todo se puede mejorar, pero no quita para que jQuery sea un framework muy potente.
VictorR:
El ejemplo es de la especificación 4.01, de html, que, como sabes, no te obliga a cerrar tags. Me he limitado a plasmar el ejemplo de la w3c. La especificación 4.01 no dice si el ul debe ser hijo del li o del padre del li. En el caso de un XHTML 1.0 sería hijo del padre del li, ya que no es posible insertar un ul dentro de un li.
coutemeier, me da la sensación de que han pasado ya más de seis meses ddesde Diciembre de 1999, que es la fecha del documento que estás citando. Vamos, no sé si es eso lo que pretendías decir, pero parece que digas que ese documento es de hace 6 meses.
El documento es la especificación oficial del HTML 4.01. Interpreta esto como quieras, pero es lo que es. Que tenga 6 meses u ocho años es anecdótico, si la especificación más moderna es un borrador de la 5.0. Hoy en día, usarás un documento html tipo HTML 4.01 o un XHTML 1.0.
Y en cuanto a los estándares y/o ejemplos de HTML 4.01 no seré yo quien se salga de lo que marca la w3c, y, por supuesto, cuando w3c muestre un ejemplo de un tema que necesito, pondré su ejemplo, que para algo son el w3c.
Otra cosa es que queramos discutir sobre la necesidad de una versión nueva (por ahí colea la HTML 5.0 borrador, pero habrá que esperar a ver implementada en los navegadores la versión no borrador cuando salga).
Creo que en esta opinión se han juntado varios temas pero con la sensación de que se hablaba de uno sólo, aunque no hace falta resultar despreciativo para comentar este aspecto.
Según la web de jQuery "jQuery is designed to change the way that you write JavaScript." pero no la manera en que construyes tu HTML de forma básica. Creo que jQuery sí que ayuda mucho a la hora de usar Javascript para manipular la página construida, tiene mucha potencia por la sencillez que aporta.
Ahora bien, si lo que quieres es construir página HTML y XHTML de forma correcta, independientemente del navegador, tal vez necesites otro tipo de framework más orientado a describir componentes de alto nivel (por ejemplo con árboles ya definidos) sin necesidad de programarlo una vez más. jQuery UI, Richfaces, Icefaces, myfaces, GWT, YUI, etc., etc., etc.
coutemeier, te equivocas. La especificación de 4.01 sí dice que ul sólo puede contener li. No hay más que leer el DTD, leer la explicación y ver que tu ejemplo es un ejemplo marcado como obsoleto. Si crees que seguir las recomendaciones del W3C es seguir los ejemplos que pongan como obsoleto, te deseo lo mejro, pero no cuentes con que el resto del mundo te siga. (Por cierto, el DTD de 4.01 Strict NO incluye los casos DEPRECATED. ¿Sigues usando Transitional? ¿Por alguna razón válida?)
logongas, el asunto es el siguiente: Sale una noticia. La noticia es el uso de jQuery por parte de Microsoft. La noticia es esa. ¿Quieres explicar a qué nivel está orientado jQuery? Perfecto, es una información que puede aportar a la noticia. Ahora bien, ¿crees que la mejor forma de decirlo es básicamente despreciar jQuery porque no soluciona un problema tuyo que jQuery ni siquiera está orientado para resolver? Pues bueno, yo no creo que esa sea ni la mejor forma ni siquiera una forma adecuada de decirlo.
No sé, pero creo yo ("creo yo" = mi opinión, nada más y nada menos) que si uno quiere añadir a una noticia algo de opinión personal, deseando que "ojalá incluyeran también una librería de componentes que me libere de la tortura que significa aprender a entender HTML, CSS, el DOM y Javascript" es ferpectamente libre de hacerlo. Pero eso es algo muy distinto que decir que "buah, esto no resuelve mi problema" cuando es que ni siquiera están intentando resolver ese tipo de problema.
Bueno, pues ahora voy yo, que aún no había dicho nada ;)
jQuery, como framework javascript, está pensado para facilitar el trabajo con el árbol DOM del documento (crear y manipular nodos, añadir estilos...). No se trata de una librería de widgets, ni nada por el estilo.
En efecto, jQuery no tiene (ni tendrá) una clase Tree que permita crear árboles, pero da las herramientas para facilitar la creación de esa Tree por un tercero. De ahí que, junto con el "core" de jQuery, se estén desarrollando cientos de plugins. Por ejemplo, te animo a que pruebes este: http://jquery.bassistance.de/treeview/demo/. Se trata de una implementación de árboles utilizando jQuery como base.
Si necesitas hacer algo con jQuery, antes de programarlo "a pelo", puedes pasarte por plugins.jquery.com, donde están publicados todos los plugins.
En este sentido, digamos que jQuery funciona como base o núcleo sobre el cual se puede construir una mega-librería javascript usando todos los plugins que necesites y programándolos por tí mismo aquellos que no existan.
Ala, ahí queda eso :)
Saludos
Sin ánimo de crear polémica, pero resulta curioso que siguiendo este tipo de "conversaciones" se entiende por qué en el mundo del desarrollo de soft hay demasiadas implementaciones para resolver los mismos problemas y por qué la solución de muchos desarrolladores es hacerse las cosas uno mismo porque las demás soluciones no le dan lo que quieren.
Tal vez haya que abrir una sección de estudio sociológico en JavaHispano :)
Acerca de las listas, definición del LI
<!ELEMENT LI - O (%flow;)* -- list item -->
<!ATTLIST LI
%attrs; -- %coreattrs, %i18n, %events --
>
Es decir, que un LI debe llevar al menos un elemento de tipo flow.
Definición del %flow:
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
<!ENTITY % flow "%block; | %inline;">
y definición del %list (que, como vemos, es un elemento válido en %block):
<!ENTITY % list "UL | OL">
Consecuencia:
Sí se soporta anidamiento de UL dentro de LI
Ejemplo:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<title>Ejemplo</title>
</head>
<body>
<ul>
<li>Elemento 1</li>
<li>Elemento 2</li>
<li style="list-style-type: none">
<ul>
<li>Elemento 2.1</li>
</ul>
</li>
</ul>
</body>
</html>
(pasa el test del html 4.01 Strict).
Perdón, con LI quería decir que puede llevar 0 o más elementos flow, no que lleva uno o más (las prisas)
Hola jFuentes,
estoy totalmente de acuerdo con lo que dices y no creo haber dicho lo contrario. Pero si leeis alguno de los enlaces que he puesto:
jQuery Has Won The 3+ Year Javascript Framework Battle : Indica que JavaScrip ha ganado la batalla de los frameworks JavaScript.
Content, Presentation, Behavior and Border Layouts :Dice que se ha pasado de ExtJS a jQuery.
jQuery, Microsoft, and Nokia:MS va a usar jQuery en VS y Nokia se lo está pensando.
Puede hacer que alguien llege a la conclusión que jQuery es el ganador absoluto en Frameworks JavaScript.
Y mi opinión en base a estas noticias es resaltar que jQuery es de bajo nivel y no apto para todo el mundo, ya que hay frameworks JavaScript que se pueden acoplar mucho más las necesidades de cada uno.Y no digo que sean mejores o peores que jQueru simplemente que cubren otras necesidades.
Se me olvidaba, cambiando a XHTML 1.0:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Pasa el test también.
coutemeier, gracias por darme la razón: "Sí se soporta anidamiento de UL dentro de LI"
Sí, eso sí, pero NO se soporta anidamiento de UL directamente dentro de UL, que es lo que logongas tenía mal en su HTML y lo que desde el principio he dicho que estaba mal. Gracias :)
Vale. Al final después de tantos comentarios estaremos todos de acuerdo en: el "mejor" framework no existe, sino que cada uno se adapta a un conjunto de necesidades concretas. Si necesitamos una librería de widgets, efectos, etc, usaremos un framework. Si necesitamos una librería que nos permita programar en DOM "fácil" usaremos otro...
Y así todos contentos :)
Ok, te había leído mal, entono el mea culpa. Lo que yo defendía es que sí es posible el anidamiento, pero hay que hacerlo correctamente, y que otra cosa es lo que interpreten los navegadores. Defendí que sí, y desde luego el ejemplo lo busqué en el w3c.
lolongas cada tecnología tiene su lugar y responde a una necesidad, jQuery tiene como principal misión añadir una capa que resuelva las diferencias de la implementación DOM de cada navegador, sobre todo los del Internet Explorer respecto al W3C que es el que siguen los demás. Una vez puestos también hay lugar para añadir APIs que disminuyan la cantidad de código que se escribe tal y como el método hide() que me imagino que hará algo así como:
elem.style.visibility = "hidden";
¿Qué es de demasiado bajo nivel para tí? vale, pero hay muchos que no quieren casarse con un sistema de componentes de alto nivel porque normalmente son tremendamente invasivos y cerrados, si te valen estupendo pero como tengas que salirte del comportamiento y visualización del componente lo tienes chungo. Es la eterna lucha entre el alto nivel (programación rápida pero inflexible) y el bajo nivel (más curro y generalmente más conocimientos).
Por eso herramientas como jQuery son interesantes porque al ser de bajo nivel no te quita libertad.
Ahora bien si no tienes problemas en usar una alternativa céntrica en el servidor (jQuery claramente es una herramienta cliente), tienes ItsNat que te da la misma funcionalidad que jQuery pero en puro Java W3C.
jmarranz, casi totalmente de acuerdo contigo. Simplemente puntualizo que un sistema de componentes de alto nivel bien diseñado no tiene por qué ser inflexible en la medida en que facilite el desarrollo de nuevos componentes e incluya los suficientes puntos de extensión.
Cuando escribo esto, estoy pensando en la VCL que Borland creó para Delphi. Tenías toda la facilidad de VisualBasic y toda la potencia que pudieras necesitar: no había más que ver cómo proliferaron las webs donde te podías descargar cientos y cientos de componentes hechos por terceros.
Por ahí se pueden encontrar multitud de plugins para jQuery que implementan controles de interfaz de usuario. El problema de usar esos plugins de terceros es el soporte y la esperanza de continuidad en el mantenimiento. Por eso echo de menos disponer de una paleta de controles "oficiales" más amplia (parece que jQuery UI todavía está bastante verde) y en casos excepcionales, cuando se necesite alguna característica adicional, poder acudir a los plugins de terceros o desarrollar uno propio.
Hola jmarranz, yo estoy con "supertorpe".
@jmarranz:"Es la eterna lucha entre el alto nivel (programación rápida pero inflexible) y el bajo nivel (más curro y generalmente más conocimientos)."
Opino que siempre escaba ganando el alto nivel excepto para caso muy concreto, así que a no ser que tengas requerimientos muy especiales en una aplicación empresarial, usa componentes de alto nivel.
@jmarranz: "hay muchos que no quieren casarse con un sistema de componentes de alto nivel porque normalmente son tremendamente invasivos y cerrados, si te valen estupendo pero como tengas que salirte del comportamiento y visualización del componente lo tienes chungo"
Es una afirmación que siempre me sorprende.¿No hacemos aplicaciones en swing con los componentes que hay?¿No las haciamos en VB, Delphi, en incluso TurboPascal con sus componentes? Entonces, porqué no vamos a poner hacerlas en la Web.
@supertorpe:"Por eso echo de menos disponer de una paleta de controles 'oficiales' "
En eso estoy de acuerdo contigo.Una ventaja de cuando apareció Windows con respecto a MS-DOS es que todas las aplicaciones empezaron a aparecerse entre si y para ello ayudó el tener los componentes estándar de Windows. El problema es que en la Web (ya no digo solo jQuery) no los hay, ni creo que los haya. Y el problema lo veo en definir que es un control. Si es solo HTML+CSS o le añadimos JavaScript, si en la parte servidor también tiene que existir o no. Si los eventos se generan en JavaScript o van al servidor , las tecnologías de servidor que soportará, Etc. O simplemente deberán soportar todo lo anterior.
Saludos.
PD: jmarranz, mi nick es "logongas" no "lolongas" :-)
logongas, yo creo que aquí la diferencia está en que para hacer aplicaciones de escritorio no existía (porque no era necesario) la figura del diseñador-maquetador artístico. Es decir, podría haber alguien experto en usabilidad que ayudase o guiase en el diseño de las pantallas, pero no intervenía codificándolas. En los desarrollos web esa figura sí codifica y ahí es donde comienzan las dificultades, ya que restringe mucho la libertad a la hora de diseñar el sistema de componentes: tiene que ser amigable con el diseñador, pero potente para el desarrollador. Si no fuera así, me podría decantar directamente por wicket y programarlo todo en Java, o usar webcream o cualquier otra tecnología-framework que ignorase ese aspecto estético-artístico del desarrollo web.
Cuando se empezó a hablar de JSF y leí la JSR pensé que eso era lo que se necesitaba: un sistema de componentes reutilizables, extensibles... sin embargo, no sé si por falta de recursos, nació con un montón de deficiencias y un modelo muy complejo que dificulta la creación de componentes y han pasado un montón de años para que se hayan ido corrigiendo poco a poco, muchas veces con ayuda de terceros (p.e. facelets). Curiosamente (no quiero iniciar un flame aquí), .NET parece que tuvo más éxito en ese aspecto.
...sin embargo, y ya me estoy saliendo de tema, JSF es mucho más flexible que ASP.NET. Pero, con unas pocas ayudas en el IDE sería posible hacer aplicaciones JSF "a la ASP.NET" (disclaimer: no sería apropiado para todas las circunstancias y aplicaciones, pero sí para muchas). Aquí propongo tres:
- al crear una página, crear un backing bean para la página con scope request (algo parecido a lo que hace Netbeans), de tal modo que tengamos todo el código relacionado con la página localizado en una clase.
- al insertar un componente JSF en modo visual, que inserte un atributo y lo enlace a dicho componente en el backing bean de la página, de tal modo que desde cualquier método podamos acceder directamente a manipular los controles sin tener que buscarlos.
- facilitar la codificación de eventos: al marcar en modo visual que deseamos implementar un manejador de un evento, que el IDE inserte el esqueleto del manejador en el backingbean de la página.
Creo que esas tres cositas serían un gran paso adelante para facilitar el hacer aplicaciones como churros.
supertorpe: ya que restringe mucho la libertad a la hora de diseñar el sistema de componentes: tiene que ser amigable con el diseñador, pero potente para el desarrollador. Si no fuera así, me podría decantar directamente por wicket y programarlo todo en Java, o usar webcream o cualquier otra tecnología-framework que ignorase ese aspecto estético-artístico del desarrollo web.
Me sorprende que hayas incluido Wicket como un framework "poco amigable con el diseñador" y que consideres que "se programa todo en Java", no es verdad, los templates de Wicket son un 90% HTML puro. Wicket usa la idea de patrón HTML/componente Java: un trozo de HTML en el template es asociado a un componente en Java tal que en Java principalmente se programa la lógica de datos, el framework cambia la parte visual de acuerdo a esa lógica y algo de manipulación visual es posible desde Java a medida. La mayor parte de la definición estética se hace en HTML normal y corriente que es sin duda el terreno que dominan los diseñadores web.
ItsNat es en algunos aspectos parecido a Wicket pero consiguiendo un HTML puro 100% en los templates con 0 custom tags, que pueden abrirse con cualquier editor HTML, posibilidad de control fino de la lógica visual desde Java y en teoría no son necesarios componentes (los cuales ayudan pues son comportamientos prediseñados de manipulación visual vinculados a datos).
Wicket, Tapestry e ItsNat son en mi opinión los frameworks Java más respectuosos con el diseñador web (aunque Tapestry cada vez se aleja más de esto).
La familiaridad con el diseñador web no es precisamente el punto fuerte de JSF el cual por definición oculta el HTML detrás de su sistema de custom tags.
Hola supertorpe,
"En los desarrollos web esa figura sí codifica y ahí es donde comienzan las dificultades"
En todo este hilo siempre estoy hablando de aplicaciones empresariales, así que ¿para que necesito un diseñador-maquetador? Nunca me hizo falta en VB-Delphi-Developer y ahora tampoco me tiene que hacer falta.
Respecto a la dificultad de usar componentes,lo normal es que a mayor facilidad menor versatilidad y viceversa. Pero ¿necesitamos toda esa versatilidad? Ya he dicho que en otros lenguajes los controles eran faciles de usar.
Y mi propuesta de controles es la siguiente:
Página JSP:
<%
Button buttonEntrar=new Button("buttonEntrar","Entrar");
buttonEntrar.setEnabled(false);
%>
function buttonEntrar_onClick() {
buttonEntrar.setVisible(false);
}
blablabla <%= buttonEntrar.toHTML() %> blablabla
El control se crea en Java y se genera todo el HTML+CSS+JavaScript y luego el modelo de ventos es simplemente llamar a una función JavaScript (si quieres puedes añadir listeners pero desde JavaScript) y ya te apañaras tu en hacer lo que quieras: LLamar al servidor via AJAX, hacer algo en JavaScript, navegar a otra página. Tienes toda la libertad del mundo.Y más facil imposible.
Se ha comido todos los tags HTML:
<%
Button buttonEntrar=new Button("buttonEntrar","Entrar");
buttonEntrar.setEnabled(false);
%>
<html>
<head>
function buttonEntrar_onClick() {
buttonEntrar.setVisible(false);
}
</head>
<body>
blablabla <%= buttonEntrar.toHTML() %> blablabla
</body>
</html>
Uf, he dejado el tag script por poner :-(
<%
Button buttonEntrar=new Button("buttonEntrar","Entrar");
buttonEntrar.setEnabled(false);
%>
<html>
<head>
<script>
function buttonEntrar_onClick() {
buttonEntrar.setVisible(false);
}
</script>
</head>
<body>
blablabla <%= buttonEntrar.toHTML() %> blablabla
</body>
</html>
logongas: Es una afirmación que siempre me sorprende.¿No hacemos aplicaciones en swing con los componentes que hay?¿No las haciamos en VB, Delphi, en incluso TurboPascal con sus componentes? Entonces, porqué no vamos a poner hacerlas en la Web.
Como dicen por ahí arriba usamos los componentes Swing porque es lo que hay, la tradición de aplicaciones Swing feas de narices es conocida por todos en buena parte porque la estética de los componentes por defecto era fea de narices.
Swing es un caso interesante porque en teoría puedes diseñar totalmente nuevos componentes y transformar profundamente los que hay, pero como es una tecnología de pixel es complicado de narices. Además no ha existido la presión de hacer cosas bonitas porque Swing ha sido utilizado casi únicamente en el mundo profesional para herramientas de gestión.
El caso web es curioso porque por una parte está destinado al usuario final y la estética es muy importante, y por otra parte el HTML viene a ser piezas de lego mucho más fáciles de manejar para construir piezas más complejas ("componentes") con cierta facilidad aunque no tengas el control tan fino de Swing.
Por eso tú te atreves a hacer tus propios componentes HTML porque tienes una intuición de las piezas de lego que necesitas, en Swing seguramente no te lo plantearías porque no sabrías ni por donde empezar (no digo que no pudieras, que se puede, no valoro tus capacidades, simplemente comparo tecnologías y más bien estoy hablando de mi mismo).
Y finalmente por eso la renuncia al control del HTML respecto a componentes de alto nivel en plan "todo hecho", es algo que hay que tener claro, porque es la renuncia a un nivel de control en el que más o menos todo el mundo es competente y que deja fuera a los diseñadores web (o al diseñador web bueno o malo que somos todos).
Cuando diseñe los componentes de ItsNat tuve claro que iban destinados a programadores que no querían renunciar al control del HTML ni siquiera en los componentes, por ello son ciertamente de más de bajo nivel y requieren que el usuario defina la vista, la estética e incluso con un gran control de como cambia.
Por una lado el web todavía esta bastante inmaduro en cuanto a ponerse de acuerdo en como hacer las aplicaciones. Y por otro lado las "exigencias" de las interfaces en aplicaciones web son tan heterogeneas que intentar hacer una solución universal me parece demasiado atrevido, al menos de momento.
Y bueno, quiza se puede pensar que en el pasado VB y Delphi consiguieron crear el sistema de componentes de alto nivel que permitía hacerlo casi todo, pero eso es por que alguien a bajo nivel tenia que pegarse para hacer los de alto nivel. Y si habia tanta variedad de componentes de alto nivel sería por que los estandar no servían para todo.
Y el problema tambien es que aunque deseemos y esperemos que los componentes de alto nivel nos permitan jugar tanto que no necesitemos irnos a bajo nivel, la realidad es que ahora mismo en muchos casos no dan la talla, y las aplicaciones hay que hacerlas ahora con lo que existe, no con lo que supuestamente habrá en un futuro. Así que por eso en web sigue habiendo un nicho para el bajo nivel, ya que el alto nivel es bastante inmaduro.
OT: Yo de acuerdo con jmarranz... joé se me nota el catarro :P
jmarranz tienes razón, se me ha ido la pinza con wicket. Recordaba al haber visto los ejemplos que muestran en su web mucho "new Label()", "new TextArea()"... pero he comprobado que no eran para crear los controles, sino para crear referencias a los mismos que están definidos en HTML.
De acuerdo en lo de JSF, aunque facelets nos permite usar el atributo "jsfc" al estilo de tapestry "jwcid"
No es que me haya sorprendido, porque es una idea bastante extendida, pero sí me ha llamado la atención verla expresada tan directamente. Me refiero a "...estoy hablando de aplicaciones empresariales, así que ¿para que necesito un diseñador-maquetador?" y a "no ha existido la presión de hacer cosas bonitas porque Swing ha sido utilizado casi únicamente en el mundo profesional para herramientas de gestión."
Como digo es una idea bastante extendida. Como es una aplicación "seria", "para trabajar" no necesitamos un diseñador, puede ser fea. Así luego vemos interfaces tan fantásticos como los de... cualquier aplicación SAP, por ejemplo. Es decir, una auténtica basura. Pero "como es una aplicación para trabajar"... O mejor aún, todos esos paquetes de inventario y gestión de stocks que funcionan aún en modo terminal y en los que aparece, porque no cabe más, "TORNILLO GALV. 8D 32" y "TORNILLO GALV. 8D 32" y es el encargado el que tiene que almacenar en su memoria qué es cada uno, no sea que intente vender tornillos para madera a alguien que necesita para metal (o viceversa). O que para imputar las horas de trabajo de la semana tengas que tardar alrededor de 1 hora porque el proceso es repetitivo y tedioso y confuso y hay que hacerlo día a día.
No, lo siento, pero el ser una idea extendida, no la hace menos errónea. En una aplicación empresarial, el interfaz también es algo importante. Y no, el diseño no consiste sólo en hacerlo bonito. Y el poder ir soltando componentes desde la barra a tu formulario no significa que ya sepas diseñar un interfaz. Ni con VB, ni con Delphi, ni con Swing, ni con HTML.
El diseño del interfaz no es sólo hacerlo bonito por hacerlo llamativo. También es conseguir que sea agradable de usar, que sea usable, que no acabemos hasta los **** de estar delante de una aplicación gris y horrible durante un buen montón de horas al día. Que no tengamos que pelearnos por encontrar una opción que usamos mucho pero que el programador ha metido en un submenú de un menú que además cambia de sitio según estemos en el módulo de compras o en el de proveedores.
Ah, y los usuarios empresariales también son usuarios, como otro cualquiera. Que la aplicación se use para trabajar no equivale a que tenga que ser fea, incómoda y poco amigable. Y sí, todo eso es parte del diseño de interfaz, no sólo que sea "bonita".
De acuerdo anónimo, pero en este aspecto hay una diferencia importante entre aplicaciones de gestión y websites: para las primeras el problema se resuelve con un rol de experto en usabilidad, el cual ha brillado por su asuencia en todas esas aplicaciones que comentas, y que no necesita picar código. En las segundas es necesario el rol de diseñador-maquetador que sí necesita picar código y esa diferencia es fundamental. Porque yo puedo hacer aplicaciones de gestión cuya interfaz esté bien diseñada pero que haya sido totalmente programada por un desarrollador, cosa impensable para websites.
greeneyed: OT: Yo de acuerdo con jmarranz... joé se me nota el catarro :P
XD
Buen comentario el del anterior anónimo (¿por qué no te registras?). Cuando dije que el antiguo Swing era feo (el look and feel por defecto) no quise decir que no se pudieran hacer aplicaciones bien concebidas desde el punto de vista de la usabilidad, una aplicación fea puede ser mucho más "usable" que una aplicación sobrecargada de efectos usables y aunque sea fea al final se le coje cariño si cumple bien su función.
Un ejemplo no Java: Nero vs Roxio Easy Creator en versiones más antiguas. Nero era más sos, "feo" pero funcionaba mucho mejor que Roxio que era mucho más recargado visualmente hasta tal punto que tenía unos retardos horrorosos y fallaba como una escopeta de feria.
Pero lo importante de mi comentario es que no creo que se considere una prioridad dedicar muchos recursos en hacer más "bonita" una aplicación Swing *de uso interno*, para empezar porque no es nada trivial. La paradoja es que en HTML no es necesario demasiado esfuerzo para mejorar la estética.
"efectos usables" debería poner "efectos visuales"
Anonimo,
Yo estoy con supertorpe.
No he hablado de la usabilidad de la aplicación sino que necesite aun diseñador-maquetador para hacerla bonita.
Así con unos controles es perfectamente posible hacer una aplicación usable sin tener que bajar al HTML,DOM, etc.
Además nada impide que los controles esten diseñados por un buen diseñador-maquetador para hacerlos bonitos y usables pero lo que yo quiero luego es no tener que or al bajo nivel.
Eso es lo que dices ahora, pero antes tu frase ha sido claramente "es una aplicación empresarial, luego no necesito un diseñador". Y de eso es de lo que yo he hablado, no de bajo nivel o alto nivel.
Esta claro que no hay soluciones universales, jquery para lo que esta pensado es fantastica, pero es una librería de bajo nivel que requiere conocimientos avanzados de js, html y css si quieres hacer algo que quede bonito. Yo voy a hacer una defensa de los framewoks de alto nivel, mirar esto:
http://extjs.com/deploy/dev/examples/feed-viewer/view.html
¿es feo?, ¿es una aplicación de gestión gris y horrorosa?, pues a mi me parece bastante presentable y me pongo a pensar como hacer algo así a bajo nivel con JQuery y se me ponen los pelos de punta ¿cuantos gurus de js/html/css conoceis capaces de montar algo así en un tiempo razonable?
Con estos frameworks puedo hacer aplicaciones bastante resultonas de forma relativamente sencilla, y cuando no me llegue con lo que ofrece el framework o con el nivel de personalización de sus componentes siempre puedo tirar de js a pelo y montarmelo como yo quiera, al fin y al cabo por mucho que use un framework de este tipo nadie me impide cojer el DOM de la pagina y hacer con el lo que quiera que sigue estando ahí abajo.
Por supuesto esto hablando del caso de uso de aplicaciones de gestión o similares, ¿que componentes se usan habitualmente en estas aplicaciones?: formularios, árboles, grids de datos, layouts, menús y realmente poco más, ya que he puesto de ejemplo una demo de EXT, esta librería ofrece esos componentes y muchos otros y es bastante personalizable y extensible, exiten por supuesto otras opciones como SmartClient y unas cuantas más de funcionalidad similar (ext es la que personalmente más conozco).
Ahora una reflexión sobre los diseñadores, en los ultimos años la combinación "diseñador prepara plantilla programador incluye datos dinamicos" se ha extendido como la formula más habitual de desarrollo web, pero claro esto estaba muy bien cuando las paginas se hacian a la vieja usanza y el diseño era estatico pero ¿que pasa con la web 2.0 y los diseñadores?, es decir, ahora el diseño no es sólo un html estatico, el diseño tiene que ver con la forma de interactuar con la pagina, tiene que ver con comunicaciones asincronas y trozos que se recargan dinamicamente, animación por aqui y por alla, es decir, ahora el diseño no es sólo estatico sino que incluye COMPORTAMIENTOS con lo que la vieja formula de diseñador+programador se nos queda corta para abordar aplicaciones de este tipo.
A veces me da la sensacion de que se intenta forzar el seguir usando esta formula cuando ya claramente no encaja, para lograr buenos resultados en aplicaciones de este tipo en mi opinión se necesita una colaboración más estrecha entre diseño y desarrollo, no vale con el tipico "toma la plantilla metele los datos" sino que el diseñador se tiene que sentar al lado del desarrollador para trabajar de forma conjunta e ir viendo cual es la mejor forma de presentar el interfaz en cada caso, o quizas necesitemos para estas aplicaciones gente con conocimientos de ambas cosas que sean capaces de hacer un diseño chulo con html/css y añadirle comportamientos con js. Lo que me parece claro es que si queremos ser el "nova más" en las interfaces web que presentamos no podemos seguir trabajando con los planteamientos que se usaban en la "web 1.0". La parte dificil es que estos cambios son MUY COMPLEJOS de llevar a cabo cuando en una empresa esta establecida cierta forma de hacer las cosas y se intenta hacer algo "güeb 2.0" con calzador por que es lo que mola, y al final resulta que diseñador y programador andan perdidos porque ya no esta tan clara la barrera entre diseño y programación en este tipo de aplicaciones.
@remoh "al final resulta que diseñador y programador andan perdidos porque ya no esta tan clara la barrera entre diseño y programación"
Es que teniendo ExtJS , ¿para que necesito un diseñador?¿No lo puede hacer todo un programador? Es algo que nunca he entendido. Quizas será porque soy programador y no tengo nada de diseñador.
Saludos
PD:Por diseñador se entiende "diseñador gráfico".
Tanto logongas como remoh estais hablando de aplicaciones claramente de gestión sin embargo hoy día prácticamente cualquier web ES una aplicación y hay otros factores como es la imagen corporativa, la presencia de partes estáticas junto con dinámicas etc. Es más, las partes dinámicas suelen partes pequeñas dentro de las partes estáticas y no al revés que es lo típico de los frameworks dinámicos.
Lo del acceso al DOM si es necesario que menciona remoh es una esperanza muy optimista :) el framework espera que todos los elementos estén en su sitio salvo cambios estéticos (CSS via objeto/atributo style) es difícil que puedas hacer algun cambio sin romper el componente. Te lo digo por experiencia, en los componentes de ItsNat el programador puede tocar muchas cosas, para ello se proporciona el concepto de renderers, pero sólo ciertas zonas y si es necesario se lo dice al componente (el concepto de estructura), pero si toca otras puede romper el componente y estamos hablando de componentes más sencillos en donde el HTML inicial lo ha proporcionado el propio programador, no es generado de cero como en ExtJS o similares.
Siguiendo el ejemplo que has puesto de Ext JS, Ext JS es fabuloso para aplicaciones puras y duras si te vale tal y como está (y te "gusta" JavaScript, sino, mejor la versión GWT). Pero si echas un vistazo con el FireFox a esta página de la web corporativa de ExtJS:
http://extjs.com/products/extjs/
En dicha página se usa el propio ExtJS entre los apartados:
"Ext JS: Cross-Browser Rich Internet Application Framework"
y "Ext JS Overview"
Ahora echa un vistazo al código fuente, busca el código entre ambos apartados, verás que no hay prácticamente nada, esa parte, complejísima, está generada con JavaScript.
En el ámbito Ext JS no hay problema pues responde a los patrones de visualización de los autores de Ext JS pero en una web cualquiera existe el altísimo riesgo de que tu jefe inocentemente te diga algo así como "muy bonito pero podrías hacer que se hiciera..." y entonces es cuando te cagas la pata abajo.
Bah, tienes razón en la idea que quieres transmitir, pero ese código no es tan complejo, jmarranz. De hecho, es bastante sencillo. Creo yo que cualquiera, sin conocer ExtJS y conociendo un poco de Javascript podría entender sin problema al menos el 80-90% de samples2.js Y el resto con una pequeña explicación.
Realmente el problema de frameworks a muy alto nivel, como puede ser el caso de ExtJS es que te da un montón de cosas. De ese montón, por un lado tienes el problema comentado -que nunca va a cubrir cualquier necesidad que se te ocurra con lo que tendrás que acabar haciéndote tú ese caso particular a mano- y por otro lado la mitad de las cosas que te ofrece no las vas a necesitar.
Un ejemplo práctico. En ese código aparecía una función que no sabía yo que tenía ExtJS (porque no uso ExtJS) es radioClass(). Posiblemente es una operación que aparece en un número razonable de casos: añadir una clase a un elemento y quitársela a todos sus elementos hijos. Yo no recuerdo ahora mismo si he tenido que hacer esa operación recientemente, pero hay dos formas de plantear esto.
Si orientas tu librería a un nivel más alto (*), incluyes radioClass() en ella. La ventaja es clara: que llamas a la función y punto. La desventaja principal es que acabas teniendo un montón de funciones y luego el programador tiene que saber que están ahí. ¿Habrá una función que añada una clase u otra alternativamente a una lista de elementos? ¿Cómo se llamará?
Si tu librería está orientada a un nivel más bajo (*), lo que haces es incluir todas las facilidades genéricas necesarias para que el usuario pueda implementar esa funcionalidad de la forma más sencilla posible si la necesita. La desventaja es clara: que tienes que implementarlo tú. Pero la ventaja también lo es: Sólo necesitas conocer una serie mucho más pequeña de funciones (y posiblemente reglas de composición de esas funciones, epro esto va implícito en ambos casos) y realizar cualquier funcionalidad nueva no contemplada por la librerías es más sencillo.
(Con jQuery podrías hacer $('#elemento').addClass('bla').children().removeClass('bla') que es un poco más largo que Ext.get('elemento').radioClass('bla'), por supuesto, pero desde otro punto de vista, más sencillo y más fácil de seguir. Y también más fácil de modificar.)
A mi personalmente, lo que más me... entristece (en realidad me produce una mezcla de sensaciones, entre ellas la tristeza, pero lo dejaremos en eso) es ver que la idea de muchos de elegir una librería o un framework es fijarse en si, como dice remoh, "requiere conocimientos" o quizá mejor en cuánto conocimiento requiere. Creo yo que tratar de buscar una librería o framework o plataforma cuya misión principal no es tanto que te solucione los problemas sino que no tengas que saber cómo se solucionan esos problemas, es triste. También es arriesgado, por cierto, porque tú te dedicas a apoyarte en esa librería y aprendes a usar esa librería pero no sabes nada de lo que hay por debajo, de cómo funcionan realmente las cosas.
Y ojo, que no digo que haya que meterse a trabajar a bajo nivel, lo que digo es que hay que saber nosólo cómo funciona la librería desde el punto de vista de su uso, si no que hay que saber qué está pasando a bajo nivel. Luego ocurre lo que ocurre, que te encuentras mucha gente que sabe que para que una función haga X hay que pasarle tal parámetro con valor Y, pero no saben realmente qué significado tiene, qué es lo que se hace con ese parámetro Y o por qué es necesario. Es magia.
(*) Otro asunto sería preguntarse si radioClass() representa realmente alto nivel o sólo un nivel medio. Pero es irrelevante. Lo que importa es que es de más alto nivel.
Con lo de "complejísima" me refería al resultado no a que sea complicado hacerlo con ExtJS, para eso es una librería de alto nivel. A donde quiero llegar es que en una aplicación interna es posible tragarse/aceptar un "porque sí" cuando un componente no hace lo que quieres y es muy complicado cambiarlo, en una aplicación/web pública es más problemático.
No acabo de pillar lo que quieres decir... Por un lado me sorprende que creas que ese es un componente complejísimo (ya me sorprendía que te refirieras al código, pero ese funcionalmente el componente no es tan complejo, la verdad).
Por otro lado, si estás diciendo que es difícil salirse de los componentes que ofrece el framework pero luego estás diciendo que ese -que no es un componente estándar del framework sino que está hecho a mano- es sencillo... No sé, no acaba de encajar una cosa con otra, ¿no?
Tienes parte de razón Anónimo, no había visto que el código samples2.js es más o menos a medida, pensaba que era un componente precocinado y mucho más sencillo, por otra parte el código ahora que lo he visto no es nada sencillo en mi opinión pero bueno.
Ciertamente no es un buen ejemplo de lo que estamos hablando porque el uso que se hace de ExtJS es de bastante bajo nivel usando mucho HTML a medida.
Que pesados, pare que que estubieran compitiendo haber quien la tiene mas larga :-p solo hay que recordar que para cada problema existe una solución, no existe una solución para todos los problemas (Hablando en alto nivel).
Saludos,
Runaway.
Personalmente, creo que los lenguajes de script o de etiquetas estilo html/css/javascript deberian hacerse en lenguajes de programacion "standar" sin tantas tonterias, os imaginais programando distintos Java segun la version, so, etc, no digo librerias digo lenguaje.
Es un poco ABSURDO que en el siglo XXI 40 años despues del nacimiento de casi todos los lenguajes (-java) NADIE se haya planteado hacer un navegador en un lenguaje estandar, estan cosas pasan cuando se deja a Microsoft campar a sus anchas y una vez que la la web la programar diseñadores.
La pagina que no este bien formada no deberia ser cargada.
Comprendo como estais hartos de tanta WEB 2.0 y librerias "sencillitas" que te lo solucionan todo.
"40 años despues del nacimiento de casi todos los lenguajes (-java)"
O sea que después de Logo ya no ha nacido ningún lenguaje más que Java? Ja, ja, ja.
...y ja.
Ah, y otro ja.
"NADIE se haya planteado hacer un navegador en un lenguaje estandar"
Ah, ah, perdona, que no había pillado que tu comentario era humorístico.
Java creo que es del 91, luego solo se ha creado c# y algun que otro lenguaje basado XML..
HTML es muy poco formal, justo lo que seria cualquier lenguaje de programacion.
Java creo que es del 91, luego solo se ha creado c# y algun que otro lenguaje basado XML..
¿Es coña no? Por mencionar dos bastante conocidos: Groovy y Scala.
Y eso de que todos nacieron hace 40 años, menos Java,... en fin, sin comentarios.
Pascal, Modula, SmallTalk, Prolog, AWK... tienen menos de 40.
Objective-C, Ada, C++, Object Pascal, Eiffel, Perl, Oberon, Tcl... Tienen menos de 25 (salvo Obj-C que tiene 26)
Haskell, Python, Ruby, Lua, PHP, Javascript, Erlang... rondan la edad de Java (algunos una poco anteriores otros posteriores)
D, C#, Io, Factor, Scala, Groovy, F#... son todos más jóvenes que Java.
Lo cuál me lleva a preguntarme... ¿es que nadie se toma la puta molestia de fijarse en lo que va a decir antes de decirlo?
Escribe tu comentario