12/01/2006, 11:48
| |||
| |||
 php OO vs php tradicional Saludos, quisiera saber si alguien me puede ayudar. Estoy investigando y tratando de obtener las ventajas y desventajas de la programación OO en php, y especialmente las ventajas y desventajas de la programacion OO vs la programacion tradicional de php. Si alguien me puede ayudar si tiene algun tipo de experiencia en esto le estaria muy agradecido. |
|
12/01/2006, 14:47
| |||
| |||
| Un ejemplo práctico se discutió en este mensaje: http://www.forosdelweb.com/f68/pregunta-sobre-faq-conexion-ejecucion-con-mysql-362635/ Ahí veras algunos argumentos en favor de la OOP .. En contra a la OOP no le veo nada .. sólo que te "obliga" a ser más estricto en el desarrollo de aplicaciones, eso tal vez para alguien que desarrolla por "hobby", o no hace desarrollos donde participa más personas en el mismo .. le pueda parecer que "hace más trabajo" para lo mismo que solventa con unas pocas funciones, y listo. Un saludo, |
|
12/01/2006, 17:22
| |||
| |||
| Mira, PHP siempre estuvo unos cuantos pasos atras en cuanto a OOP se refiere. Recien ahora estan incorporando o copiando muchas cosas de otros lenguajes como java o c que amplian las posibilidades y mejoran aquellas cosas pasadas por alto en los ultimos anios. Ahora, en cuanto a tu pregunta, el secreto de un buen desarrollo no se basa en utilizar objetos o no. Como asi tampoco en desarrollar codigo reciclable o escribir un comentario cada 2 lineas. El secreto esta en el sentido comun del programador. Hay muchas cosas que se aprenden con el tiempo, como desarrollar codigo portable, seprara las capas de una aplicacion, no escribir codigo laberinto, y saber trabajar en equipo (algo que no todos pueden). Trabajar en equipo te ensenia mucho mas que todo lo demas. La forma en que se escribe una aplicacion, refleja los conocimientos del programador. Ahora, la forma en que esa aplicacion resuelve un problema, refleja el sentido comun del mismo. Podes conocer de memoria todas las paginas del manual, pero si no tenes sentido comun nunca vas a lograr ser un buen programador. Uno no nace con sentido comun, lo adquiere con el tiempo. De nada sirve tener 200 clases perfectamente ordenadas en una aplicacion robusta y prolijamente desarrollada, si a la hora de actualizarla no podemos porque al modificar una quebramos otra, como asi tampoco sirve de nada si termina siendo un laberinto y perdemos mas tiempo modificandola que desarrollandola de nuevo. |
|
14/01/2006, 11:56
| ||||
| ||||
| Gente, escuchen lo que dice Tukzone, es alguien que sabe por experiencia, y no habla por hablar. Hola Fede! un placer leerte aunque sea por acá ;) |
|
18/01/2006, 09:21
| ||||
| ||||
| yo tengo una duda...con respecto a la optimizacion de la memoria....creo esto... si programamos OO...se crean clases con un conjunto d metodos y atributos...a la hora de crear un objeto se carga todos esos metodos en memoria...eso no es problema hasta q nuestra aplicacion sea visitada por miles d usuarios en un mismo minuto....nuestra aplicacion se tornaria lenta... por eso, mi filosofia en la web...es hacer todo mas rapido y para mi la programacion estructura es lo conveniente...ya q solo usas las lineas d codigo q necesitas... es tipico caso de programar con asp.net es recontra pesado...muchos objetos se cargan en memoria... q opinan? PD: con respecto a trabajar en equipo...tienes razon tukzone.... la logica d cada programador es muy diferente....
__________________ www.datasegura.net |
|
04/02/2006, 11:14
| ||||
| ||||
| No, no se cargan todos lo métodos en memoria, sólo los atributos. Para aligerar puedes simplemente disminuir los atributos que cargas, de esa manera cada objeto es algo muy parecido(en memoria) a lo que ocuparía una fila de un arreglo. La cosa es programar bien, no importa si lo haces con objetos o no, hacer las cosas limpias y con lógica. Siempre utilizar funciones e includes en lugar repetir y repetir código. Personalmente me encanta usar Smarty para separa presentación de procesamiento, puede llegar a parecer muy pesado, pero una vez que la aplicación es estable se activa el cache a discreción y se acelera muchisimo más. Por supues en mini-aplicaciones todo esto carece de sentido y puede consumirle más al programador de lo que debería, pero tambien hay que pensar que muchas veces las aplicaciones se vuelven grandes poco a poco y después hubieras deseado hacer todo con Smarty y objetos.
__________________ "La libertad viene en paquetes pequeños, usualmente TCP/IP" http://blog.levhita.net/ |
|
08/02/2006, 15:58
| |||
| |||
| Mi opinión es que deberiamos aprovecharnos de las características de la POO (reusabilidad, 3 capas, alta cohesión, bajo acoplamiento). Es una verdadero estilo de programación con una base conceptual muy robusta. La idea no es preocuparse de la memoria ni de un millón de usuarios al mismo tiempo ya que hoy en día contamos con tecnologías lo suficientemente avanzadas para computar datos (procesadores de 64 bits, mucha memoria RAM, etc). es mi humilde opinión... saludos  |
|
14/02/2006, 11:04
| |||
| |||
| En respuesta a lo que dijo leeja, muchas veces un programador debe decidir uno entre dos caminos, es decir, tenés razón en cuanto a que hacer muchas clases en un proyecto puede hacer lento al sitio, pero... Muchas veces es COMPLETAMENTE NECESARIO sacrificar el rendimiento de un sistema para obtener mayor rapidez de desarrollo, si Microsoft no reutilizara código NUNCA podría hacer un sistema operativo en menos de 2 años... La mejor forma de darse cuenta es con práctica, yo tengo un Framework con muchos objetos hay algunas clases que tienen más de 2000 líneas de código, ¿qué veneficio tengo? Hago un formulario con un listado y sus respectivas validaciones de datos y grabación en tan sólo 10 minutos... Ahhh, casi me olvido de mencionar que al reutilizar código podés encontrar un BUG en una llamada a conección de datos y repararlo para que TODO el sitio que libre de ese BUG. Si no reutilizás código vas a tener que modificar tantas líneas como grande sea tu sistema, una modificación, por más pequeña que sea te podría tomar todo un día de trabajo modificando script por script... |
|
14/02/2006, 15:30
| |||
| |||
| Cita: Una clase con más de 2000 lineas?? sabes lo q son los
Iniciado por gnfrs En respuesta a lo que dijo leeja, muchas veces un programador debe decidir uno entre dos caminos, es decir, tenés razón en cuanto a que hacer muchas clases en un proyecto puede hacer lento al sitio, pero... Muchas veces es COMPLETAMENTE NECESARIO sacrificar el rendimiento de un sistema para obtener mayor rapidez de desarrollo, si Microsoft no reutilizara código NUNCA podría hacer un sistema operativo en menos de 2 años... La mejor forma de darse cuenta es con práctica, yo tengo un Framework con muchos objetos hay algunas clases que tienen más de 2000 líneas de código, ¿qué veneficio tengo? Hago un formulario con un listado y sus respectivas validaciones de datos y grabación en tan sólo 10 minutos... Ahhh, casi me olvido de mencionar que al reutilizar código podés encontrar un BUG en una llamada a conección de datos y repararlo para que TODO el sitio que libre de ese BUG. Si no reutilizás código vas a tener que modificar tantas líneas como grande sea tu sistema, una modificación, por más pequeña que sea te podría tomar todo un día de trabajo modificando script por script... Código PHP: Código PHP: Código PHP: |
|
14/02/2006, 15:40
| |||
| |||
| Hace ya 2 años que vengo creando este Framework... Soy dueño de una empresa de desarrollo de software, tengo experiencia para tirar para arriba y no creo que me haga falta saber qué es un foreach o un while... Querés saber qué hace una clase como esa? Validaciones de datos de formularios, está tan completa que puedo hacer lo que sea con esa clase. Las clases de compresión de datos o cifrado que hize son un poco más chicas. Pegale una ojeada a la librería JPGraph (creo que se llamaba así) el zip con la librería completa y los ejemplos pesaba cerca de 3 MB. Saludos. PD: Obviamente que con la documentación para generar las bibliotecas con PHPDocumentator se hacen un poco más grande los archivos... Ahh me olvidaba uso PHP 4, ya que todavía PHP 5 es muy reciente y casi no hay servidores con PHP 5 para los sitios de mis clientes. |
|
18/02/2006, 08:47
| |||
| |||
| No es por dar por culo... pero los "design patterns" de Java, por ejemplo, recomiendan no escribir más de 1000 líneas por clase... Que cada uno lo interprete a su manera. Saludos |
|
18/02/2006, 08:52
| |||
| |||
| Mis clases cumplen con los requerimientos de mis sistemas. Algunas de ellas están destinadas a cumplir sólo una función, no puedo hacer 8 clases que interactúen totalmente entre sí y que cumplan la misma funcionalidad en conjunto. ¿Si no me alcanzan con 1000 líneas de código me hago verdulero o plomero? |
|
18/02/2006, 15:55
| |||
| |||
| Pues precisamente el tratamiento y validación de formularios son uno de los paquetes q siempre lleva incluido un framework, y precisamente si que se puede procesar por jerarquia de clases. Tambien puedes utilizar PEAR html_quickform ahora que quieras utilizar una clase de 2000 linias q te has currado lo veo logico despues de la panzada de picar codigo seria lo normal pero y en mi modesta opinion, dudo que tu clase no se pueda descomponer en otras y estoy seguro q te lo puedo demostrar. Por cierto quisiera pedir disculpas por el post anterior, no quisiera q se conviertiera en una disputa sino en una ayuda o en un intercambio de ideas además este tema es muy interesante. adioss |
|
20/02/2006, 06:21
| |||
| |||
| Sí, es un buen punto de vista, yo también estoy seguro que podría dividr mi clase en otras más pequeñas como en la validación de datos de ASP.NET, el problema es que estas clases deberían interactuar muchísimo entre sí, fue por ese motivo que lo hice todo en sólo una clase que por cierto llevo mucho tiempo creando esa clase y desde la primer línea de código el objeto fue cambiando mucho.... En cuanto a PEAR no sé qué tan útil puede ser, pero las clases que probé de PEAR no funcionaban del todo bien, es más, había orrores en vez de errores (uso de constantes con errores de sintaxis por ejemplo). Saludos. |
|
20/02/2006, 10:02
| |||
| |||
| yo tambein quiero entrar en POO pero parece mas complejo que el PHP tradicional  |
|
20/02/2006, 13:55
| |||
| |||
| Cita: Lo primero que tienes que "ver" es que POO no es un "lenguaje" que aprender nuevo .. sino un montón de teoría, paradigmas y demás historas que en -tal- o -cual- lenguaje se implementan de cierta forma, por ejemplo en PHP se usan las "classes" para aplicar los conceptos de la Programación Orientada a OBjetos .. Pero con esos "conceptos" claros podrías propagar en POO en Java .. o en otros lenguajes que la implementen.
Iniciado por migueilichenco yo tambein quiero entrar en POO pero parece mas complejo que el PHP tradicional Un saludo, |
|
20/02/2006, 17:33
| ||||
| ||||
| A ver... estuve siguiendo este thread cada vez que se publicaba una nueva respuesta, y hasta ahora he visto ciertas formas de opinar y actitudes con las que disiento, y me gustaría expresar por qué: Cita: Aqui tenemos un acierto y un error, al menos a mi manera de verlo. Es cierto, que al instanciar un objeto, se cargan sus datos y el signature de sus métodos, pero esto no debería ser problema, si programamos pensando en objetos, y nos damos cuenta que un objeto no debería tener más de 10 métodos para actuar sobre sus datos. La prog. estructurada no es precisamente sinónimo de eficiencia, todo por el contrario. Se ha demostrado que aplicaciones POO bien diseñadas, se ejecutan utilizando menos recursos que aplicaciones estruturadas sin pensamiento en performance.si programamos OO...se crean clases con un conjunto d metodos y atributos...a la hora de crear un objeto se carga todos esos metodos en memoria...eso no es problema hasta q nuestra aplicacion sea visitada por miles d usuarios en un mismo minuto....nuestra aplicacion se tornaria lenta... por eso, mi filosofia en la web...es hacer todo mas rapido y para mi la programacion estructura es lo conveniente...ya q solo usas las lineas d codigo q necesitas... Cita: Disculpen que disienta, pero Smarty NO SIRVE. Implementaron todo un sub-lenguaje ENCIMA del PHP, para hacer cosas que PHP ya hace, sin necesidad. Por eso de "separar" el código de presentación del código de negocio, no se dan cuenta que el "Lenguaje Smarty" es ... código?!? Entonces, que tenía de malo el código PHP de antemano? Personalmente me encanta usar Smarty para separa presentación de procesamiento, puede llegar a parecer muy pesado, pero una vez que la aplicación es estable se activa el cache a discreción y se acelera muchisimo más. Cita: Disculpa, pero CUALQUIER clase con 2000 líneas de código, es típicamente una clase mal diseñada, sobrecargada. Lo que se llama una "clase Dios", que tiene demasiadas responsabilidades y víctima segura de un buen proceso de refactorización. Cómo dicen más arriba, 1000 líneas de código también siento que son "muchas líneas" y realmente, ni me dedico a ver el código de una clase asi... busco otra o la hago de cero. Yo trato de no sobrepasarme en más de 300 o 400 líneas por clase. Si luego metemos 4 o 5 clases en un solo archivo, eso es otra cosa.La mejor forma de darse cuenta es con práctica, yo tengo un Framework con muchos objetos hay algunas clases que tienen más de 2000 líneas de código, ¿qué veneficio tengo? Hago un formulario con un listado y sus respectivas validaciones de datos y grabación en tan sólo 10 minutos... Cita: No dudo que tus clases cumplan los requerimientos de tus sistemas, pero eso de que no puedes hacer más clases de una clase de 2000 líneas, no lo creo. Y si crees que exagero, hagamos algún tipo de ejercicio, postea tu clase gigante y veamos si es o no posible refactorizarla en clases más concentradas y reutilizables.Mis clases cumplen con los requerimientos de mis sistemas. Algunas de ellas están destinadas a cumplir sólo una función, no puedo hacer 8 clases que interactúen totalmente entre sí y que cumplan la misma funcionalidad en conjunto. Cita: Solo me hago una pregunta...Sí, es un buen punto de vista, yo también estoy seguro que podría dividr mi clase en otras más pequeñas como en la validación de datos de ASP.NET, el problema es que estas clases deberían interactuar muchísimo entre sí, fue por ese motivo que lo hice todo en sólo una clase que por cierto llevo mucho tiempo creando esa clase y desde la primer línea de código el objeto fue cambiando mucho.... ¿Qué problema hay que las clases tengan que ser más e interactuar entre ellas? Eso no es precisamente, por lo que tenemos la programación orientada a objetos? Sino, lo que tenemos es funciones encapsuladas dentro de clases, pero cero diseño orientado a objetos. Bueno, básicamente esta me parece una buena discusión para que entre todos podamos desmistificar un poco el "monstruo" de la Programación Orientda a Objetos, que no es más que una evolución normal y necesaria para cualquier programador. Saludos y nos seguimos leyendo. |
|
20/02/2006, 18:28
| ||||
| ||||
| Qué tema tan apasionante, al toro por los cuernos. Pregunta de un principiante en OOP: Para una aplicación medianamente compleja hecha en programación estructurada (lo que aquí comenzaron a llamar programación tradicional), que ya tiene todas sus funciones bien delimitadas y todo en su mayoría muy bien organizado... 1) ¿toma mucho tiempo convertir todo eso en OOP? 2) ¿vale la pena transformar proyectos de uno a otro? Mi único contacto con los objetos es que luego entro a phpclasses.com (no sé si esté bien escrita la URL) y luego veo clases interesantes que no tengo que abrir para ver cómo lo hacen ni cómo trabajan, en sus especificaciones dice para qué sirve y sus limitaciones, y no me preocupo por cómo funciona. Eso es lo que llamó mi atención de la programación OOP, hacer código que sirva para algo y ocuparlo cada vez que lo necesite, sin que me importe cómo es que hacen su trabajo. Que este thread tome un buen curso, ojalá alguien pueda opinar sobre mis dos preguntas.
__________________ "Di no al Internet Explorer" -Proverbio Chino- |
|
21/02/2006, 16:15
| |||
| |||
| Cita: Por fin alguien que lo dice!!!! Mira que para decir eso hay que saber. Dejame citar eso de nuevo por favor...
Iniciado por Webstudio Disculpen que disienta, pero Smarty NO SIRVE. Implementaron todo un sub-lenguaje ENCIMA del PHP, para hacer cosas que PHP ya hace, sin necesidad. Por eso de "separar" el código de presentación del código de negocio, no se dan cuenta que el "Lenguaje Smarty" es ... código?!? Entonces, que tenía de malo el código PHP de antemano? Cita: Smarty paso a ser ridiculo ya. Como muy bien dice pablo, el "lenguaje smarty" tiene que ser interpretado por PHP y a su vez PHP tambien tiene que ser interpretado. Y otra cosa, la gente que lo utiliza, utiliza solo el 30% o 40% de lo que ofrece, lo demas lo incorporan tambien sin saber porque.
Iniciado por Webstudio Smarty NO SIRVE Con un poco de paciencia y en poco tiempo, cualquiera puede implementar un sistema similar que haga lo que uno necesita, y no un sistema que quiera hacer todo, incluso obligar a los programadores y diseniadores de una empresa aprender un "lenguaje" nuevo. |
|
21/02/2006, 16:36
| |||
| |||
| Cita: Si para crear un formulario y validarlo, te lleva 2000 lineas de codigo, no me quiero imaginar cuantas lineas de codigo tenes que escribir para enviar un mail :)2000 líneas de código, ¿qué veneficio tengo? Hago un formulario con un listado y sus respectivas validaciones de datos y grabación en tan sólo 10 minutos... Escribir una clase con 2000 lineas de codigo esta mal, no se hace, esta prohibido. Lo que si podes hacer es tener una clase madre que controle a otras y las llame en base a las necesidades de la aplicacion. Es una buena practica extender las clases, para organizar mejor una aplicacion, y para poderlas usar en otros proyectos obviamente. Una clase con 2000 lineas de codigo, dudo que se vuelva a utilizar y si se hace, muchos metodos dentro de esa clase van a estar de decorado, o sea, no se van a utilzar. Y si necesitas utlizar 1 o 2 metodos, tenes que incluir las 2000 lineas, una locura. |
|
21/02/2006, 16:52
| |||
| |||
| Otra cosa, el mayor problema que encuentro yo con aplicaciones grandes, si las clases no se organizan bien, o no se mantienen menos de 400 lineas de codigo, o el disenio esta mal estructurado o no sigue una logica, es el tema de la depuracion. Por ejemplo, si no hay una logica detras del sistema, el efecto laberinto hace casi imposible depurar una aplicacion. Te hace perder mucho tiempo y genera mas errores de los que se solucionan. |
|
21/02/2006, 17:21
| |||
| |||
| Bueno les respondo a los que critican mi clase "grandota"... En primer lugar debí aclarar esto antes pero entre las 2000 líneas de código está incluída la documentación que la utilizo como ayuda contextual, quitando todo eso calculo que se reduciría a un poco menos de la mitad (calculando a simple vista). En segundo lugar, la funcionalidad de la clase es muy compleja, hace una validación de formularios, incluyendo: * Campos requeridos * Comparación extendida de campos * Formatos predefinidos de expresiones regulares * Cantidad máxima y mínima de caracteres * Validación de campos múltiples (campos con el mismo ID pero en forma de matriz) * Validación de tablas multiples (por ejemplo para cargar estudios cursados en un asistente para currículums) * Comparación de campos por aproximación. * Validación de fechas. * Validación de distintos tipos de formatos (coma flotante, enteros, etc) Bueno la lista sigue no recuerdo bien todo. Para enviarte el código de la clase tendría que enviarte también las clases base de las cuales hereda esta clase de validación. En segundo lugar, esta clase se integró a mi Framework hace tiempo, cuando era más pequeña, fue creciendo a medida que pasó el tiempo y ya me es complicado reestructurarla porque no quiero perder compatibilidad con los sistemas que ya la están utilizando, ya que un framework muy bien armado no me serviría de nada si "deja de funcionar un sitio" cada vez que actualizo el mismo. Yo sé que esa clase es muy larga y difícil de leer, pero lamentablemente son demasiadas cosas que tiene que validar y a diferencia de .NET (hay un objeto por tipo de validación) esta me es muy cómoda a la hora de reutilizar código, con unas simples llamadas a funciones puedo hacer el objeto muy flexible. Igualmente creo que en un futuro voy a estudiar la forma de reestructurarla sin perder compatibilidad. A medida que las aplicaciones se van haciendo cada vez más robustas y grandes los objetos que la componen van creciendo también, esto es inevitable (Ingeniería de Software - Roger S. Pressman). Saludos. PD: En respuesta a Tukzone, depurar un BUG no me hace perder mucho tiempo con un depurador para PHP. Con apretar varias veces F10 me alcanza. |
|
21/02/2006, 17:54
| |||
| |||
| Cita: A que llamas bug? a un punto y coma que falta en una linea? Creo que aca estamos hablando mas de patrones de disenio y estructuras. Cuando una estructura esta mal diseniada, o tenes que desmantelar una clase que contiene 2000 lineas de codigo, te puedo asegurar que la tecla F10 no te sirve de nada. Con apretar varias veces F10 me alcanza |
|
21/02/2006, 19:55
| ||||
| ||||
| Bueno, bueno Creo que soy uno de los menos indicados para dar mi opinión pero no todos somos sabiondos o nacimos sabiendo. Ya son casi 3 años y medio lo que llevo con PHP y me considero que todavía ando por el piso pues todos los días el Internet avanza mucho y PHP también, inclusive estuve leyendo algo sobre el futuro PHP6. Cita: Tukzone: No se que experiencia tengas con Smarty pero creo que no es tan malo como dices. Yo antes era de los que les encataba ligar código PHP con HTML y eso no era fácil a la hora de cambiar un plantilla o de decir por ejemplo "a yo no quiero que el scroll de noticias este me salga en la segunda fila de la tabla ubicada al lado derecho sino en la primera de la tabla ubicada a la izquierda" entonces comenzaban los problemas de cambiar código de aquí para allá y no solo HTML sino mover completamente el código PHP. Smarty me ayuda muchísimo a la hora de crear las plantillas por la forma en que hace su trabajo ya que el mismo viene siendo como un patrón de diseño "Model View Controler (MVC)". Creo que el mismo está muy bien pensado y que además de facilitar la parte de templates trae muchas funciones predefinidas (plugins & modificadores) los cuales me garantizan mucha funcionalidad en los templates. Por ejemplo si quisiera simplemente truncar el contenido de un resultado de 1000 caracteres y dejarlo en 100 solo tendria que poner en mi plantilla:
Iniciado por Tukzone Smarty paso a ser ridiculo ya. Como muy bien dice pablo, el "lenguaje smarty" tiene que ser interpretado por PHP y a su vez PHP tambien tiene que ser interpretado. Y otra cosa, la gente que lo utiliza, utiliza solo el 30% o 40% de lo que ofrece, lo demas lo incorporan tambien sin saber porque. Con un poco de paciencia y en poco tiempo, cualquiera puede implementar un sistema similar que haga lo que uno necesita, y no un sistema que quiera hacer todo, incluso obligar a los programadores y diseniadores de una empresa aprender un "lenguaje" nuevo. Código PHP: Yo por mi parte ya me salí un poco de Smarty ya que me estoy enfocando a PRADO un framework para PHP muy potente y al parecer con buen futuro así que si hay alguien que me pueda ayudarme les estaría muy agradecido. Salu2
__________________ Ing. Reynier Pérez Mira |
|
21/02/2006, 22:18
| ||||
| ||||
| Hola Gnfrs, primero y antes que nada, quiero dejar en claro que nadie está criticando por criticar, ni te está atacando ni nada. Aquí tan solo estamos opinando de lo que cada uno conoce, desde el punto en que lo conoce. Yo no he visto tu clase ( o jerarquía de clases, porque primero decís 2000 líneas de código, ahora decís que tiene menos de la mitad, etc. ) pero siempre te puedo asegurar que una clase es refactorizable. Es por ello que te decía que no había problema en que publicaras tu clase, y las clases de las cual deriva.. y hagamos un ejercicio. No como demostración de "quién diseña mejor" o no, sino para mostrar una refactorización y todos aprendamos en el camino. Y sobre Smarty, quiero comentar un par de cosas. Yo utilicé Smarty, en varios proyectos estuve obligado a mantener "código Smarty", y sinceramente, no veo motivos para aprenderlo porque lo mismo se puede hacer con PHP. La gente se defiende con "es lento, pero activás la caché y listo". Smarty no es la unica que puede ofrecer "caché", por lo cual, sigue siendo lentitud innecesaria. Solo cargar smarty, el motor de parseo, etc, ralentiza los scripts en 0,5 milisegundos. En un ambiente con medio millón de pageviews al día, es MUCHO tiempo. Realmente estimo que hayan escrito un plugin para dreamweaver para que puedan usar Smarty, pero realmente, yo trabajo con diseñadores que no usan Dreamweaver, que trabajan con otros paquetes pero que van directamente al código. Y si tengo que enseñarles a hacer un {$elemento|truncate:1000}, directamente les enseño a hacer <?=substr($elemento, 0, 1000)?>. Es básicamente la misma cantidad de código, y de paso ya sabe PHP. Así como no quería usar Smarty en otros proyectos, colaboré en la creación de NokTemplate, con ideas y tips para optimizar la clase, de manera que pueda ofrecer la velocidad que ofrece, sin el overhead de un nuevo pseudo-lenguaje. Cuando Tukzone habla sobre Smarty, no dice "no usen plantillas", y muchísimo menos dice "Metan código PHP en el HTML". NO NO NO NO NO! Solo exclama que hay opciones mejores. Smarty per se no es MVC y por separar lógica de presentación con lógica de negocios, no te garantiza una buena implementación de MVC. Ahora, si hablamos de PRADO, esto es un tema totalmente diferente. |
|
21/02/2006, 22:59
| ||||
| ||||
| Yo de nuevo por acá Hola Webstudio: Mi idea no fue contradecir a nadie y menos se me ocurriría hacerlo contigo o con Cluster que son mis idolos de FDW. Yo solo trate de explicar algunas ventajas que me ofrece Smarty ya que no me he metido mucho en otros motores como Savant y nokTemplate. Solo tengo un problemita y es que no me puedo descargar la clase nokTemplate al menos donde la encontre en esta direccion: http://jpw.com.ar/descargas.php si alguien me la pudiera enviar por correo les estaría muy agradecido a ver si aprendo algun otro sistema de plantillas que no sea Smarty, aunque como comente antes estoy comenzando con PRADO y esto no usa Smarty ni nokTemplate, creo  . Cita: Webstudio, muy interesante la propuesta que haces a Gnfrs de poner sus clases, así todos aprendemos un poco más de lo que ya sabemos y porque no ayudamos a mejorar el framework que esta creando el mismo. Yo por mi parte como comienzo con PRADO y este es totalmente OO entonces debo meterme un poco más en la misma con PHP, así que pronto me tendrán dando cabezasos por acá por FDW, mi principal tutor y quien me ha dado gran parte del conocimiento que poseo hoy de PHP gracias a personas como Webstudio, josemi, Cluster y otros que me han ido ayudando.
Iniciado por Webstudio Hola Gnfrs, primero y antes que nada, quiero dejar en claro que nadie está criticando por criticar, ni te está atacando ni nada. Aquí tan solo estamos opinando de lo que cada uno conoce, desde el punto en que lo conoce. Yo no he visto tu clase ( o jerarquía de clases, porque primero decís 2000 líneas de código, ahora decís que tiene menos de la mitad, etc. ) pero siempre te puedo asegurar que una clase es refactorizable. Es por ello que te decía que no había problema en que publicaras tu clase, y las clases de las cual deriva.. y hagamos un ejercicio. No como demostración de "quién diseña mejor" o no, sino para mostrar una refactorización y todos aprendamos en el camino. Salu2
__________________ Ing. Reynier Pérez Mira |
|
22/02/2006, 01:42
| ||||
| ||||
| Reynier, acá no me gustaría promover ningún tipo de divismo ni nada por el estilo. Si tenés una opinión justificable, acá se le puede contradecir a Por eso, no tomes nunca la palabra de nadie como "final", porque todos tarde o temprano, dormimos mal, o nos levantamos del lado equivocado de la cama, o quizás en una cama que no conocemos, y tenemos un mal dia y opinamos cualquier cosa. Por suerte, varias veces me han tenido que cerrar la boca aquí en el foro, uno de ellos es ahora mi buen amigo Nok. Te paso el link directo para ver si te las puedes bajar a las NokTemplates: http://jpw.com.ar/index.php?lugar=do...e-1.2-beta.zip Respecto a PRADO, lo estuve revisando no hace mucho, y me dejó un muy buen sabor de boca. Ahora estoy muy metido dentro del código de Drupal, porque estamos haciendo un CMS en mi trabajo que debe cumplir con algunas características de Drupal (alta modularidad, taxonomías, MUCHA seguridad), pero en cuánto pueda, mañana o pasado, vuelvo a bajarme el código de PRADO, porque lo que vi, me gustó, sobre todo su sistema de componentes bsado en un buen motor de templates (eso es loque yo llamo realmente, separación de las capas de presentación). |
|
22/02/2006, 06:38
| |||
| |||
| Cita: Más bien "NokTemplate" y sistemas similares lo que hacen de "bueno" es que se dedican al fondo del problema: són sólo "gestores de plantillas" .. nada de psudo-lenguajes y procesos extra añadidos que para algunos será mejor y para otros peor.Reyner Además otros como Savant, NOKTemplate no hacen lo mismo? Si más no recuerdo en ZonaPHP leí un articulo sobre el uso de NOKTemplate y decían que era muy bueno porque estaba en español. Yo soy de la filosofía de cada cosa a lo suyo .. si uso PHP y me interesa tener mis "plantillas" aparte como para darselas a un diseñador para que las "adorne" .. prefiero programar en "PHP" y que la "plantilla" sea extremadamente básica: nada de lenguaje por medio. Entiendo que Smarty incorpora gracias a su psudo-lenguaje muchas funcionalidades que con código PHP te costará algo más hacerlo. Por ejemplo en "NokTemplate" que me acuerde me costaba bastante manejar "bloques" en plantillas que se repiten a base de bucles .. Con "Smarty" y su própio lenguaje como se diseño para eso, se optimizó ese proceso .. pero bueno, en "PHP" también te podrías crear alguna función? o algún método nuevo para NokTemplate o rediseño de alguno de estos para facilitar algunas taréas. El caso es ver que fuera a temas de "usabiliad" del sitema que se use en sí .. hay que ver claro que implementar un "lenguaje" en otro "lenguaje" hay un proceso por médio inevitable extra. Un saludo, |
Este tema le ha gustado a 1 personas 
