Sv Community El Salvador
Soporte y Tecnología => Programación => Scripts => Mensaje iniciado por: g00mba en enero 26, 2012, 08:52:39 am
-
No muchacho, usted está confundido. Framework viene de algo más general que al español se podría traducir como "Entorno de trabajo" o más literalmente "marco de trabajo". Un ejemplo sencillo: el .NET Framework, es un conjunto de bibliotecas, que te dan un montón de herramientas para trabajar tus aplicaciones. Un Framework NO NECESARIAMENTE te dice como tu aplicación tiene que estar estructurada. Si bien el Visual Studio te fuerza a seguir cierta convención (separando el código de la página del código de aplicación) no es ley que vos tengas que seguir la arquitectura MVC por ejemplo.
Tu confusión debe de originarse debido a que has utilizado varios Frameworks que se basan en "convención sobre configuración" como RoR o CakePHP donde ya existe una convención de la arquitectura a utilizar para construir tu aplicación.
Obviamente existen Frameworks que no te dan un esqueleto como CakePHP. Realmente Framework es nombre genérico que se le da a una serie de bibliotecas que te ayudan a desarollar aplicaciones como mencionó g00mba arriba. Alguien podría decir que las bibliotecas de java también son un framework y no estaría demasiado equivocado.
Tal vez sería más correcto decir que un Framework puede ser un conjunto de bibliotecas distribuidas como un conjunto más que de manera individual.
Bibliotecas como jQuery están en un area gris ya que podrías considerarla "framework" porque proveen diferentes herramientas que te ayudan a programar aplicaciones escritas en Javascript (orientado a navegadores), pero también podrías considerarla como una biblioteca si la estas usando en conjunto con otras bibliotecas diferentes.
osea básicamente la idea que vos tenes sobre framework es parecida a la mia. vos podes tener un framework en una bibloteca o en veinte, con un esqueleto estructural o sin el, pero al final depende si vos las usas como bibliotecas sueltas o como realmente un framework.
Buenas, acá estoy nuevamente...
miren, a mi no me gusta presumir de cosas que no sé, si dije que manejo perfectamente ajax, es porque es cierto, sin embargo creo que usé el tono y las palabras que no debía usar, por lo general no soy nada agrandado sino todo lo contrario, la verdad es que no quiero echar más leña al fuego,
te felicito, pero no creo que nadie aqui crea que vos tenes bases sobre ajax para nada. te lo digo porque la única referencia que tenemos al respecto es ese tu post incendiario que demostró más desconocimiento que habilidad en el tema, te lo digo para que tengas en cuenta situaciones asi en el futuro y entendas porqué nuestro escepticismo. yo puedo venir y decir "yo soy un ingeniero agrónomo certificado super pro" y ni criar una planta de frijoles puedo...
el foro aguanta con lo que le queras escribir sin embargo vos podes poner mil veces que sabes ajax, igual no te vamos a creer. mejor DEMOSTRALO. hablá algo razonable. así es como se te respeta aqui.
ahora, viéndolo de otra forma en base a esto se consiguió tener un excelente post sobre ajax!
pd. la discusión NO se refiere a ajax sinó a la definición de framework y bibliotecas.
-
osea básicamente la idea que vos tenes sobre framework es parecida a la mia. vos podes tener un framework en una bibloteca o en veinte, con un esqueleto estructural o sin el, pero al final depende si vos las usas como bibliotecas sueltas o como realmente un framework.
Es lo malo de "enamorarse" de un framework específico, pensas que todos los demás tienen que ser como ese que te gusta a vos jajaajaja El rdoggsv es otro enamorado de RoR fasklj hflkfjas fjd ahsklasjfdas
-
Pues estoy de acuerdo también en varias cosas con el_quick en sus comentarios, y que bueno ver que después de tantos comentarios en su contra mantiene la calma. Creo que si esta equivocado en el pensamiento que ajax es solo visual como lo planteo en su primer post, pero ya se retracto de eso, la idea creo que va en que la mayoría de veces ajax se ocupa para actualizar la página que estas viendo sin necesidad de cambiarla, y eso es algo que últimamente el usuario ve como "visual" porque estaba viendo una pantalla con un contenido, y luego "magicamente" cambio a otro sin refrescar completamente, a eso le agregas el hecho que muchas veces cuando esta listo el nuevo contenido a ser actualizado casi en todos lados le meten algún efecto para que vos te des cuenta que el contenido cambio y que ya no estas viendo el mismo.
Pero si que regada la actitud de el primer post de saltar demasiado a la defensiva, lo otro es que también considero cierto que no hay que cometer el mismo error que con flash, que solo porque algo lleva efectos de javascript después se lo quieren meter por todos lados, tipo como el boom de "dhtml" que ponian javascript para todo y al final quedaban unos macarronnes de enredo.
Así como hay sitios que hacen uso masivo de ajax, y de efectos javascript para brindar una gran usabilidad a los sitios, hay otros que prefieren utilzarlo poco, o no utilizar nada, y siempre pueden ser muy buenos.
Ya si estas hablando de aplicaciones web, que requieran tener una funcionalidad muy parecida a la de escritorio si estamos en otro tema, en donde el uso de ajax y javascript para muchos efectos se vuelve una necesidad :)
-
Ya si estas hablando de aplicaciones web, que requieran tener una funcionalidad muy parecida a la de escritorio si estamos en otro tema, en donde el uso de ajax y javascript para muchos efectos se vuelve una necesidad :)
en ese aspecto, creo que Spry lleva bastante ventaja sobre los otros.
-
en ese aspecto, creo que Spry lleva bastante ventaja sobre los otros.
Por que lo decis g00mba ?
Te pregunto porque no soy cliente frecuente de adobe, y siempre en lecturas que hago para refrescar conocimientos, nunca encuentro mencionado spry como una gran cosa o algo que deba de revisar
-
en ese aspecto, creo que Spry lleva bastante ventaja sobre los otros.
Ext Js...tambien es una opcion a considerar, aunque el unico contra que le veo es que la version mas poderosa es la de pago.
http://www.sencha.com/products/extjs (http://www.sencha.com/products/extjs)
-
para paginacion uso PAGER, y me gusta porq lo puedo usar con PDO
http://xtremenews.info/2011/03/30/paginacion-sencilla-en-php-usando-pager-y-pdo/
-
Ext Js...tambien es una opcion a considerar, aunque el unico contra que le veo es que la version mas poderosa es la de pago.
http://www.sencha.com/products/extjs (http://www.sencha.com/products/extjs)
Pues por $329 sin incluir el soporte no está así como extremadamente caro. Digamos si haces una aplicacion para un cliente podes incluirle el precio de su licencia.
-
Que bonito darse cuenta uno de su propia ignorancia. Esto nos ayuda a motivarnos más por aprender y ver mas allá de nuestras narices :)
-
Por que lo decis g00mba ?
Te pregunto porque no soy cliente frecuente de adobe, y siempre en lecturas que hago para refrescar conocimientos, nunca encuentro mencionado spry como una gran cosa o algo que deba de revisar
yo tampoco soy fan de adobe, sin embargo, spry es de uso libre si queres incorporarlo en tus apps. OJO que la ventaja de SPRY es solamente cuando estamos hablando de RIA, en otras palabras, su fuerte es la estética de la aplicación y la estética y simplicidad del código.
tiene todo lo estándard de un framework moderno como el manejo de data set, widgets para presentación de los datos, etc. pero la ventaja que le veo es la misma que tiene dreamweaver: está elegantemente implementado, y estéticamente, te queda un muy buen código por lo general, limpio y sencillo, osea tiene un nivel de abstracción de funciones bastante alto, incluso para peticiones json.
tiene ventaja en el sector profesional primero por ser el por defecto de dreamweaver (eso creo que influencia mas a los diseñadores/fans de adobe que a los programadores de hueso colorado que les gusta con pala y piocha) pero habiendolo usado un par de veces, es MUY intuitivo y la integracion con DW es impecable, es realmente divertido sencillo y rápido hacer ondas con spry. con la integración a pata en otros IDE no puedo hablar, pero cuando menos ha de ser igual de buena que jquery si no es que mejor.
ademas, siguiendo en el tema de las RIA *creo* que es más directa la transición de una webapp con spry a un standalone desktop app con adobe air.
-
Empiezo diciendo que voy a seguir usando los términos en ingles. Vivo en gringolandia EEUU, trabajo aqui y aprendo aqui. Hay términos que me toma tiempo asociar en español, ambito con scope por ejemplo. No tomen mi uso de términos en ingles como una imposición cultural u otra idea rara, sino mas bien una manera de mantener precision de lo que digo.
No muchacho, usted está confundido. Framework viene de algo más general que al español se podría traducir como "Entorno de trabajo" o más literalmente "marco de trabajo". Un ejemplo sencillo: el .NET Framework, es un conjunto de bibliotecas, que te dan un montón de herramientas para trabajar tus aplicaciones. Un Framework NO NECESARIAMENTE te dice como tu aplicación tiene que estar estructurada. Si bien el Visual Studio te fuerza a seguir cierta convención (separando el código de la página del código de aplicación) no es ley que vos tengas que seguir la arquitectura MVC por ejemplo.
Tu confusión debe de originarse debido a que has utilizado varios Frameworks que se basan en "convención sobre configuración" como RoR o CakePHP donde ya existe una convención de la arquitectura a utilizar para construir tu aplicación.
mx, siempre me ha llamado la atención la certeza con la que saltas a decir que alguien se equivoca y nitpick ciertos detalles y hacer a hell lot of assumptions. No voy a responder todos tus puntos, algunos los estas trayendo como si solo quisieras mostrar que andas en la jugada.
Por ejemplo, empezas diciendo que un framework se podría traducir como un entorno de trabajo, lo cual suena bastante a lo que un IDE hace y ocupas a visual studio como ejemplo, nota como si yo siguiera tu estilo de comunicación, I'd nitpick este detalle y te diria "marachito, estas confundido [blah blah historia no tan necesaria]... " y terminaria haciendo un assine comment sobre como visual studio rots the mind. Sin embargo IMHO tales maniobras no son necesarias.
Obviamente existen Frameworks que no te dan un esqueleto como CakePHP. Realmente Framework es nombre genérico que se le da a una serie de bibliotecas que te ayudan a desarollar aplicaciones como mencionó g00mba arriba. Alguien podría decir que las bibliotecas de java también son un framework y no estaría demasiado equivocado.
Tal vez sería más correcto decir que un Framework puede ser un conjunto de bibliotecas distribuidas como un conjunto más que de manera individual.
Esa idea de framework es bastante simplista y el decir que CakePHP no te da el esqueleto suena naive. Lee mi post otra ves, y vas a encontrar esto "pero la característica a notar es que esta capa oculta y controla el flujo de ejecución." La palabra clave es flujo de ejecución. Hay frases bien simplistas que ayudan a entender la diferencia entre framework y libreria, la que mas me gusta es una llamada the Hollywood Principle "Don't call us, we call you", lo cual ejemplificaría como las capas de abstracción proveídas por el framework proveen patrones que controlan el comportamiento de tu aplicación. En otras palabras "you call a library, a framework calls you."
-
Ya si estas hablando de aplicaciones web, que requieran tener una funcionalidad muy parecida a la de escritorio si estamos en otro tema, en donde el uso de ajax y javascript para muchos efectos se vuelve una necesidad :)
Las distinciones a notar son
* Sitio web
* Aplicación web
* Single page app
La tercera es el tipo de apps que yo hago, donde todo la comunicación con el servidor es con ajax o websockets.
en ese aspecto, creo que Spry lleva bastante ventaja sobre los otros.
Ext Js...tambien es una opcion a considerar, aunque el unico contra que le veo es que la version mas poderosa es la de pago.
http://www.sencha.com/products/extjs (http://www.sencha.com/products/extjs)
Yo no usaria ninguna de esas dos. Quizas vivo en una burbuja de startup land, pero nadie que conosco usaria esas librerías. Mis recomendaciones son Ember.js o Backbone.js.
-
Single page app no sería como una subcategoría de aplicación web? pues si las ves en macro son sitios web y aplicaciones web, en cuantas páginas lo dividas sería semi relativo al hecho de decir multiple page web apps, single page web apps, o que se yo.
Y podrías profundizar en las recomendaciones de Ember.js o Backbone.js me interesa el tema, pero estoy un poco lejos de conocimiento acerca de pros y contras, que sería interesante algo así como un mini comparativo para ver en cual conviene invertir un par de horas :)
-
Empiezo diciendo que voy a seguir usando los términos en ingles. Vivo en gringolandia EEUU, trabajo aqui y aprendo aqui. Hay términos que me toma tiempo asociar en español, ambito con scope por ejemplo. No tomen mi uso de términos en ingles como una imposición cultural u otra idea rara, sino mas bien una manera de mantener precision de lo que digo.
mx, siempre me ha llamado la atención la certeza con la que saltas a decir que alguien se equivoca y nitpick ciertos detalles y hacer a hell lot of assumptions. No voy a responder todos tus puntos, algunos los estas trayendo como si solo quisieras mostrar que andas en la jugada.
Por ejemplo, empezas diciendo que un framework se podría traducir como un entorno de trabajo, lo cual suena bastante a lo que un IDE hace y ocupas a visual studio como ejemplo, nota como si yo siguiera tu estilo de comunicación, I'd nitpick este detalle y te diria "marachito, estas confundido [blah blah historia no tan necesaria]... " y terminaria haciendo un assine comment sobre como visual studio rots the mind. Sin embargo IMHO tales maniobras no son necesarias.
Esa idea de framework es bastante simplista y el decir que CakePHP no te da el esqueleto suena naive. Lee mi post otra ves, y vas a encontrar esto "pero la característica a notar es que esta capa oculta y controla el flujo de ejecución." La palabra clave es flujo de ejecución. Hay frases bien simplistas que ayudan a entender la diferencia entre framework y libreria, la que mas me gusta es una llamada the Hollywood Principle "Don't call us, we call you", lo cual ejemplificaría como las capas de abstracción proveídas por el framework proveen patrones que controlan el comportamiento de tu aplicación. En otras palabras "you call a library, a framework calls you."
Hace algunos años cuando todavía estaba en la U hicimos algo que tu podrías llamar Framework de juegos, era un programita muy sencillo que tenía una API con unas cuantas interfaces que tu tenías que heredar para definir varias clases que controlaran la lógica del juego , la parte gráfica y la multimedia (¿Te suena similar a un a Framework?). Para esos días no se había puesto de moda la palabra (hace casi 10 años ya) y la bautizamos simplemente como "API de Juegos".
Al punto que quiero llegar y es donde estoy en desacuerdo con vos y con las referencias que pusiste. Que un Framework es la capa de abstracción, que en este caso puede o no controlar el flujo de ejecución. Y de capas de abstracción las hay en distintos niveles, por lo que no es correcto decir que un Framework es única y exclusivamente aquel que cuenta con las características de por ejemplo RoR o CakePHP.
Te sugeriría que leyeras otra vez mi comentario porque en ningún momento he dicho que CakePHP no te da un esqueleto, tal vez la redacción es un poco confusa, a donde dice:
Obviamente existen Frameworks que no te dan un esqueleto como CakePHP.
Debería haberse leído:
Obviamente existen Frameworks que no te dan un esqueleto como lo hace CakePHP.
Yo puedo venir, definir algunas convenciones de diseño y montar una API que facilite cierta tarea. Puede que la diseñe de tal manera que controle el flujo de ejecución o no. ¿A donde termina un Framework y comienza una API? Si bien estoy de acuerdo en que el framework es algo más grande que una api o una biblioteca, no estoy de acuerdo con tu aseveración (o de tu referencia) de que todo lo que no controle el flujo de ejecución no es un framework.
-
Single page app no sería como una subcategoría de aplicación web? pues si las ves en macro son sitios web y aplicaciones web, en cuantas páginas lo dividas sería semi relativo al hecho de decir multiple page web apps, single page web apps, o que se yo.
Y podrías profundizar en las recomendaciones de Ember.js o Backbone.js me interesa el tema, pero estoy un poco lejos de conocimiento acerca de pros y contras, que sería interesante algo así como un mini comparativo para ver en cual conviene invertir un par de horas :)
Las aplicaciones web todavia sigen el paradigma de pagina web mientras que las single page apps siempre son solo una pagina y asemejan bastante a las desktop apps.
Facebook es una web app
Gmail es una single page app
La pregunta es bastante broad. Que queres hacer? Mi opinion es que ignores Spry y Extjs por completo y aprendas Backbone.js
Backbone es bastante low level, solo te da la estructura y te da un framework para implementar el MVC pattern y tambien incluye Underscore.js como dependencia - esta ultima es una poderosa libreria con un montón de functional constructs (map, reduce, filter). Extjs - al parecer tambien spry - te dan widgets y un montón de cosas preconfiguradas (design by configuration), lo cual siento que es una limitación.
Dame una idea de que es lo que queres hacer. No caería mal crear un pequeño tutorial que sirva de introducción al mundo profesional de client side apps.
-
sabes cual es el problema con este tema jaime? que programar es como hacer música. esta como que Jim Morrison le dijera a kurt cobain que su música no está "correcta". podes usar instrumentos variados, pero la verdad, al final se reduce a tu afinidad por alguno en particular. lo mismo es para programar. vos disfrutas barebones stuff, yo disfruto convention over configuration. there is no RIGHT answer. es asunto de gustos y de qué tipo de proyecto es el que queres hacer.
-
sabes cual es el problema con este tema jaime? que programar es como hacer música. esta como que Jim Morrison le dijera a kurt cobain que su música no está "correcta". podes usar instrumentos variados, pero la verdad, al final se reduce a tu afinidad por alguno en particular. lo mismo es para programar. vos disfrutas barebones stuff, yo disfruto convention over configuration. there is no RIGHT answer. es asunto de gustos y de qué tipo de proyecto es el que queres hacer.
same here.
-
sabes cual es el problema con este tema jaime? que programar es como hacer música. esta como que Jim Morrison le dijera a kurt cobain que su música no está "correcta". podes usar instrumentos variados, pero la verdad, al final se reduce a tu afinidad por alguno en particular. lo mismo es para programar. vos disfrutas barebones stuff, yo disfruto convention over configuration. there is no RIGHT answer. es asunto de gustos y de qué tipo de proyecto es el que queres hacer.
g00mba, yo no veo ningún problema con el tema. Siguiendo tu analogia, te doy la razón, el programar es como la musica, algunos cantan reggaeton y otros crean sinfonías. Humildemente estoy lejos, pero yo aspiro a crear sinfonias.
-
g00mba, yo no veo ningún problema con el tema.
problem as in" the root of the discrepancy in the situation" not as in "wuts ur mothafukin problem"
-
g00mba, yo no veo ningún problema con el tema. Siguiendo tu analogia, te doy la razón, el programar es como la musica, algunos cantan reggaeton y otros crean sinfonías. Humildemente estoy lejos, pero yo aspiro a crear sinfonias.
Puedes tratar con Symfony (http://www.symfony-project.org/) ;) fksjad fhjkdf kfjfas
-
Puedes tratar con Symfony (http://www.symfony-project.org/) ;) fksjad fhjkdf kfjfas
Ya me imaginaba que alguien saldría con un pun xD
problem as in" the root of the discrepancy in the situation" not as in "wuts ur mothafukin problem"
Por un momento pense que tomaste como ataque personal mi comentario sobre no usar spry. Si me preguntan mi opinion sobre ciertas practicas, se las voy a decir al menos con un poquito de anestesia. Enfasis en opinion.
-
Por un momento pense que tomaste como ataque personal mi comentario sobre no usar spry. Si me preguntan mi opinion sobre ciertas practicas, se las voy a decir con un poquito de anestesia. Enfasis en opinion.
lol yo NO uso spry para nada, porque no hago RIA's. solo que lo que tuve oportunidad de ver de Spry me resultó ideal para una webapp. enfoque en lo estético, controles sobre datos sencillos pero efectivos, fuerte integración con DW. una opcion muy conveniente.
-
spry fue una idea buenisima, pero lamentablemente se estanco u.u sin embargo aun asi yo no cambio a mi DW n.n digan lo que digan...
-
Hasta unos 7 comentarios antes que estos, QUE MAGISTRAL CATEDRA!!! dieron los GM de SVC, lastima que se empiezan a inchar, pero todo lo que han publicado me parece excelente para el conocimiento, que recios señores!!!
-
tiene todo lo estándard de un framework moderno como el manejo de data set, widgets para presentación de los datos, etc. pero la ventaja que le veo es la misma que tiene dreamweaver: está elegantemente implementado, y estéticamente, te queda un muy buen código por lo general, limpio y sencillo, osea tiene un nivel de abstracción de funciones bastante alto, incluso para peticiones json.
tiene ventaja en el sector profesional primero por ser el por defecto de dreamweaver (eso creo que influencia mas a los diseñadores/fans de adobe que a los programadores de hueso colorado que les gusta con pala y piocha) pero habiendolo usado un par de veces, es MUY intuitivo y la integracion con DW es impecable, es realmente divertido sencillo y rápido hacer ondas con spry. con la integración a pata en otros IDE no puedo hablar, pero cuando menos ha de ser igual de buena que jquery si no es que mejor.
ademas, siguiendo en el tema de las RIA *creo* que es más directa la transición de una webapp con spry a un standalone desktop app con adobe air.
lol yo NO uso spry para nada, porque no hago RIA's. solo que lo que tuve oportunidad de ver de Spry me resultó ideal para una webapp. enfoque en lo estético, controles sobre datos sencillos pero efectivos, fuerte integración con DW. una opcion muy conveniente.
El primer quote da la impresión que tenes experiencia usandolo, ahi radica mi confusión.
spry fue una idea buenisima, pero lamentablemente se estanco u.u sin embargo aun asi yo no cambio a mi DW n.n digan lo que digan...
DW era de mis favoritos, especialmente el Dreamweaver 4 (o la siguiente version - en los tiempos de Macromedia). Algo que recuerdo bastante, y no se sigue aun sigue en pie, era el concepto de Master page y detail pages. La facilidad de WYSIWYG, arrastrar cosas y seguir wizards para agregar funcionalidad fue algo que extrañe cuando decidi hacer la transición de diseñador a programador.
La verdadera iluminación viene cuando uno decide salir de su zona de comfort y se avienta ha explorar tierras extranjeras.
-
DW era de mis favoritos, especialmente el Dreamweaver 4 (o la siguiente version - en los tiempos de Macromedia). Algo que recuerdo bastante, y no se sigue la misma terminologia, era el concepto de Master page y detail pages. La facilidad de WYSIWYG, arrastrar cosas y seguir wizards para agregar funcionalidad fue algo que extrañe cuando decidi hacer la transición de diseñador a programador.
Me surge una inquietud.
Yo siempre tuve la idea de que el DW te generaba monton de codigo basura anti buenas practicas...eso fue cierto? es cierto actualmente? O me aleje del DW solo por rumores infundados??
-
Me surge una inquietud.
Yo siempre tuve la idea de que el DW te generaba monton de codigo basura anti buenas practicas...eso fue cierto? es cierto actualmente? O me aleje del DW solo por rumores infundados??
Cuando lo use si generaba un montón de basura, me acuerdo que creaba varias funciones MM_something y agregaba estilos inline en la edición de HTML. Quizas @salvadoresc nos ilustra mas al respecto.
Como dato curioso, hace poquito mas de un año yo estaba decidiendo a que dedicarme y explore la opción de crear RIAs con Adobe Flex. Baje el Flash builder, hice un par de apps, vi la monstruosidad de código que el entorno creaba, me tope con el desastre que es MXML, dije "f*ck this cr*p" y decidi mejor aprender Ruby on Rails.
-
en efecto se siguen usando las master pages... yo lo uso desde la version MX
yo en lo personal casi no las uso... prefiero usar librerias cuando son elementos que se repiten... pero se puede, hay algunas cosas mas logicamente pero en escencia es lo mismo... y yo aunque uso mucho DW procuro no depender de su vista diseno mas que para localizar elementos o previsualizar...
eso fue cierto? es cierto actualmente? O me aleje del DW solo por rumores infundados??
desconozco si antes de la version que use fue cierto... desde que yo hago uso de el no tengo problemas...
incluso hoy que han estado mencionando sobre DW, me voy a animar a ver si armo un tuto sencillon para que vean lo de la paginacion y otras hierbas se puede hacer bastante facil con el... :thumbsup:
Cuando lo use si generaba un montón de basura, me acuerdo que creaba varias funciones MM_something y agregaba estilos inline. Quizas @salvadoresc nos ilustra mas al respecto.
ahhh pero esas son cuando usabas behaviors, ondas como un rollover o validacion de formularios estaban hechas a puro js =p, si en efecto aun existen pero ya no se acostumbran usar, PRECISAMENTE para reemplazarlos es que nacio SPRY!!! y sino te gustan igual podes implementar las alternativas que preferis como jquery, en la version cs5.5 viene muy integrado con jquery-mobile :wub: ademas de que adquirieron phonegap...
-
El primer quote da la impresión que tenes experiencia usandolo, ahi radica mi confución.
el que no haga en la actualidad RIAS no significa que no tenga experiencia usando spry. de hecho es por esa experiencia que digo que puede ser bueno para RIAS.
Me surge una inquietud.
Yo siempre tuve la idea de que el DW te generaba monton de codigo basura anti buenas practicas...eso fue cierto? es cierto actualmente? O me aleje del DW solo por rumores infundados??
si lo usas como que es frontpage, awebos, crea codigo hasta por joder, pero si lo agarras como un IDE normal, es una gran onda. pero aclaro, no es mi ide favorito, solo digo que es muy conveniente. mi favorito se va para aptana+notepad++ o gedit con plugins en linux
-
ahhh pero esas son cuando usabas behaviors, ondas como un rollover o validacion de formularios estaban hechas a puro js =p, si en efecto aun existen pero ya no se acostumbran usar, PRECISAMENTE para reemplazarlos es que nacio SPRY!!! y sino te gustan igual podes implementar las alternativas que preferis como jquery, en la version cs5.5 viene muy integrado con jquery-mobile :wub: ademas de que adquirieron phonegap...
Los behaviors exactamente, había uno de preload all images, muy útil cuando hacías menus. Un punto que tiene a favor Adobe es que saben como integrar todo. Fireworks te permitia crear menus y animaciones, los cuales podias exportar como HTML e imagenes en slices. Luego desde Dreamweaver podias importarlo extremadamente facil.
Para la gente que recién comienza a crear sitios/aplicaciones web, dreamweaver es excelente. Solo tengan en cuenta que no van a crear el proximo Facebook o productos a nivel de 37Signals con el código generado por DW.
incluso hoy que han estado mencionando sobre DW, me voy a animar a ver si armo un tuto sencillon para que vean lo de la paginacion y otras hierbas se puede hacer bastante facil con el... :thumbsup:
Animate con el tutorial, tengo curiosidad sobre el código generado. Creo que se apegaria bastante al tema de "Paginación con PHP (http://www.svcommunity.org/forum/scripts/paginacion-con-php/)" que se desvio hace bastante desde que aprendimos que "El ajax es algo visual, bonito pero no hay que ser maje". :rofl:
-
Fireworks te permitia crear menus y animaciones, los cuales podias exportar como HTML e imagenes en slices.
en la actualidad... fireworks permite incluso exportar divs y css <3 pero eso es harina de otro costal XD no sigo por que se haria otro tema mas XD lol....
con el tema de behaviors en efecto habian varios buenos, pero el problema radicaba que cuando usabas uno, te ponian casi todos... entonces eso es a lo que la gente consideraba "basura" ademas que como eran JS a secas nada de jquery ni otro similar... y desde la version MX hasta la fecha jamas los mejoraron u optimizaron =p hasta que pusieron la alternativa de usar spry... pero aun quedaron ahi los behaviors....