Estoy viendo que muchas dependen de otras Ejm: Memory necesita a Cache, Gdata necesita a http.
¿Hay que eliminar a lo bruto quitando las carpetas y ver que pasa? o Hay una manera elegante de hacerlo.

Saludos.
| ||||
Filtrando librerias que se van a usar unicamente. Hay alguna manera de saber o de poder "filtrar" los modulos que no utilizo para dejar en lo más mínimo posible de peso a la libreria con componentes que no utilizo.? 25 mb solo para hacer Un crud con sistema de gestion de usuarios basado en Roles me parece excesivo. (no uso Gdata, Oauth, Currency etc...) Estoy viendo que muchas dependen de otras Ejm: Memory necesita a Cache, Gdata necesita a http. ¿Hay que eliminar a lo bruto quitando las carpetas y ver que pasa? o Hay una manera elegante de hacerlo. ![]() Saludos.
__________________ Drupal Argentina |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. Puff, en definitiva creo que no me conviene tocar nada ![]() Gracias por el link, en algun momento lo habia visto, pero pense que estaba la manera fácil(para vagos :P)
__________________ Drupal Argentina |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. No mi estimado, No es muy desacoplado que digamos ![]() Pero viendolo por lado amable tiene sus ventajas, prefiero un modulo dependiente de varios que varios módulos con su dependencia adentro(repitiendo lo mismo). Asi ya es una mole, no me imagino de otra forma. Una cuestión más no voy a negar y es que es bastante mega-archi-super-completo no se les escapa el mas mínimo detalle. Lo que me cuesta entender, es justificar todo eso a cambio de la performance, la velocidad de respuesta es mucho menor haciendo lo mismo que con otro framework que uso y no voy a decir su nombre que empieza con C y termina con R. Odiosa la comparación lo se :P pero es algo innegable. ![]()
__________________ Drupal Argentina |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. caray, y de verdad tienes mucha razón, siempre entendí que mucho código no significa necesariamente mas lento, he ahí el detalle... (: aquí lo interesante sería encontrar esos cuellos de botella y vender la solución a los de C & R ... ![]() buena broma, si, finalmente todo se justifica por su propio peso... aunque no siempre será así, ¿que importa? suerte! ![]()
__________________ Y U NO RTFM? щ(ºдºщ) No atiendo por MP nada que no sea personal. |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. tengo entendido que la extensión de auto load de ZF es una de las mejores (por no decir la mejor), así tengas muchas librerías siempre se cargará lo que se necesite cargar, es una de las razones por las que sensio labs decidió utilizarla para la nueva versión de symfony 2, yo no me preocuparía mucho por el tamaño de los ficheros, más bien por la cantidad de recursos que utilice el CRUD, symfony 1.4 es pesado en MB, pero su rendimiento es excelente a pesar de ser uno de los FW más lentos y eso que tiene otra extensión de auto load diferente de la de zend.
__________________ ¡Por favor!: usa el highlight para mostrar código El que busca, encuentra... |
| |||
Respuesta: Filtrando librerias que se van a usar unicamente. Cita: Buen punto que es lo que se supone que debo de entender por desacoplado. Que es lo que entendes por desacoplado?
__________________ Saludos! Mty-NL.. |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. Independiente, autónomo, quitar, extraer. Es lo que entiendo, a menos que tenga otro significado. O me lo quieran explicar, que estoy dispuesto a aprender que esa es mi meta. Cita: Acá si me perdi... :(pero su rendimiento es excelente a pesar de ser uno de los FW más lentos y eso que tiene otra extensión de auto load diferente de la de zend. PD: Por favor no quiero que empiece la tipica guerra de cual es mejor o peor, aclaro que soy novato en Zend - hace unos días que empecze a estudiarlo -. aun me cuesta entender algunos conceptos(no tienes un camino - tienes 100 para hacer lo mismo) Si es que se va a empezar con eso doy por finalizada mi participación en este thread. lo que me seria muy util es decirme como hago para "desacoplar" los modulos que me son de utilidad, no voy a usar Gdata, no voy a usar Memory, Ldap, Oauth, PDF, Soap y otros mas. Según la guía de dependencias, están las dependencias duras y las soft(aca te aclaran que no son necesarias pero que las demas podrían funcionar de manera errática) O me recomiendan cargar con 25 mb de archivos innecesarios. Saludos ;)
__________________ Drupal Argentina Última edición por NUCKLEAR; 18/12/2010 a las 23:09 |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. Creo que te estas confundiendo NUCKLEAR, te dejo la referencia Loose coupling, Zend es el mas desacoplado, que el Dispatcher no cumple con tus requisitos implementas Zend_Controller_Dispatcher_Interface e integras el tuyo, que el Router se queda corto implementas Zend_Controller_Router_Interface y lo integras y asi podes seguir un rato largo. Lo que vos queres hacer es eliminar componentes, para eso necesitas la lista de dependencias, paciencia y muchas pruebas, si el tamaño de Zend es un problema para un proyecto X seguramente Zend no sea la solucion adeacuada para el proyecto, mi recomendación es que inviertas ese tiempo y energia en comprender como funciona internamente Zend. Saludos. |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. Cita: Es lo que me temía, los informáticos le damos un significado distinto a todo :P Gracias por aclararme este punto.
Iniciado por masterpuppet ![]() Creo que te estas confundiendo NUCKLEAR, te dejo la referencia Loose coupling, Zend es el mas desacoplado, que el Dispatcher no cumple con tus requisitos implementas Zend_Controller_Dispatcher_Interface e integras el tuyo, que el Router se queda corto implementas Zend_Controller_Router_Interface y lo integras y asi podes seguir un rato largo. Lo que vos queres hacer es eliminar componentes, para eso necesitas la lista de dependencias, paciencia y muchas pruebas, si el tamaño de Zend es un problema para un proyecto X seguramente Zend no sea la solucion adeacuada para el proyecto, mi recomendación es que inviertas ese tiempo y energia en comprender como funciona internamente Zend. Saludos. Con respecto a lo segundo, no es problema el tamaño, simplemente soy un fanático de la optimización, para mi mientras mas pequeño mejor. Menos código es más optimo/eficiente(aunque no siempre sea así). Y si tienes razón son nimiedades comparado con el camino que queda por recorrer. Saludos ;)
__________________ Drupal Argentina |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. Cita: Hay una parte del manual que tiene una lista con optimizaciones, supongo que ya le habrás echado un ojo, sino te recomiendo que lo mires, hay algo que es real, Zend es mas pesado, crea un proyecto, no le agregues nada y al ejecutarlo vas a cargar casi 100 ficheros, la media por request debe estar en 150+ y si le agregas Doctrine te vas a arriba de 200, lo bueno, tiene un precio y esta en cada uno decidir si lo vale o no.
Iniciado por NUCKLEAR ![]() ... Con respecto a lo segundo, no es problema el tamaño, simplemente soy un fanático de la optimización, para mi mientras mas pequeño mejor. Menos código es más optimo/eficiente(aunque no siempre sea así). Y si tienes razón son nimiedades comparado con el camino que queda por recorrer. Saludos ;) Si te gusta la optmizacion te dejo el ZFDebug. Saludos. |
| |||
Respuesta: Filtrando librerias que se van a usar unicamente. Cita: Bueno menos mal es el mismo termino.Creo que te estas confundiendo NUCKLEAR, te dejo la referencia Loose coupling Cita: Nuklear aqui hay algo importante todos los frameworks esta desacoplados en mayor o menor grado ya que todos implementan patornes de diseño, implementan clases basadas en responsabilidades y colaboracion y es por eso que es normal que exista un minimo de clases requeridas para el funcionamiento correcto del framework y dependecia para algunas clases. Como comenta MasterPuppet mejor invierte tiempo para determinar que clases depende de otras para saber de que archivos puedes precindir a un que lo mas adecuado siempre es no tener que mover nada Lo que vos queres hacer es eliminar componentes, para eso necesitas la lista de dependencias, paciencia y muchas pruebas, si el tamaño de Zend es un problema para un proyecto X seguramente Zend no sea la solucion adeacuada para el proyecto, mi recomendación es que inviertas ese tiempo y energia en comprender como funciona internamente Zend.
__________________ Saludos! Mty-NL.. Última edición por HerSAn; 19/12/2010 a las 14:16 |
| |||
Respuesta: Filtrando librerias que se van a usar unicamente. Desde el mismo sitio de ZF puedes descargar una versión mínima del framework (http://framework.zend.com/download/latest), pero en mi humilde opinión, parecer carece de sentido por: * El espacio en disco es barato * Solo ocupa espacio en RAM cuando las invocas * Dar un vistazo al resto de los elementos de la biblioteca cada cierto tiempo ayuda: a Aprender Patrones de Diseño; mejora la forma en que uno desarrolla; y en algún momento podrías usarlas |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. Cita: No es una versión mínima del FW, la diferencia entre full y min es que el full trae "extras"(demo, externals, resources, etc....,) pero la librería es la misma y creo que el planteamiento de NUCKLEAR es valido, es logico querer tener lo minimo necesario.
Iniciado por ahenriquez ![]() Desde el mismo sitio de ZF puedes descargar una versión mínima del framework (http://framework.zend.com/download/latest), pero en mi humilde opinión, parecer carece de sentido por: * El espacio en disco es barato * Solo ocupa espacio en RAM cuando las invocas * Dar un vistazo al resto de los elementos de la biblioteca cada cierto tiempo ayuda: a Aprender Patrones de Diseño; mejora la forma en que uno desarrolla; y en algún momento podrías usarlas |
| ||||
Respuesta: Filtrando librerias que se van a usar unicamente. @nucklear si no invocas el componente, no lo carga. El archivo existe fisicamente, pero no se carga. Sino queres usar Zend_Server_Soap no lo levantes, y no lo vas a usar. Lo mismo para el resto de los componentes. de hecho sino queres usar el MVC, podes no usarlo.
__________________ blog |