Cita:
Iniciado por basa 
hola unreal4u, gracias por el aporte!
de nada :P
Cita:
Iniciado por basa De todas formas no estoy de acuerdo en que sin la opción de autoload, los programas queden más ordenados. Precisamente, yo personalmente es una de las ventajas que le veo: el que la inserción de los ficheros necesarios sea completamente transparente, dándote una gran flexibilidad, además de la mejora incríble que supone para el mantenimiento del código.
Totalmente de acuerdo: como idea es muy buena. No tener que preocuparte de qué archivo vaya o no a incluir me parece una idea fantástica :D
Cita:
Iniciado por basa Siguiendo la convención del paradigma de orientación a objetos fielmente de un fichero una clase, al final el problema es que te haces con un montón increíble de includes que abren una vía muy grande a los errores.
Es más, en mi aplicación como en la mayoría, yo no tengo ni idea en un principio de las acciones a las que se va a llamar, estas se instancian dinámicamente según lo que pida el usuario.
Y es ahí donde entramos en la problemática. Yo he programado un montón de CMS tanto desde cero como ocupando algunos pre-hechos (mostrario de productos, ventas online, noticias, galería de imágenes, etc) y aunque en un principio me llamó la atención el autoload, finalmente lo deseché.
Por qué? Prefiero hacer un sistema mucho más modular y de esa manera cargaré sólo los módulos que me interesan, pero eso require bastante experiencia. Sólo por dar con un ejemplo, el otro día me tocó incorporarle características nuevas a un sw que había hecho en PHP hace 3 años y en muchos lugares me dije: "Yo hice ESO? Oh dios mío, qué aberración". Después de unos lijeros cambios por aquí y por allá, la aplicación que antes generaba la página en 1.7 segundos ocupando 15MB de RAM ahora lo hace en 0.6 ocupando 6.3MB (con APC y algunos ajustes en MySQL finalmente quedó en 0.3 ocupando 3.3MB), y los cambios fueron bastante simples: en vez de cargar todo; separé, hice un nuevo archivo que verificara qué página se estaba mirando; y de acuerdo a eso iba cargando los distintos módulos. De 1.7 segundos a 0.3 segundos la diferencia sí se nota.
En un principio puede parecer difícil, pero una vez que definas bien la estructura de tu sistema no será necesario depender de autoload, que por lo demás es un poco más lento que un include_once.
Ahora ocupo la filosofía de que si voi a necesitar algo, recién ahí lo cargo. Ejemplo: si un usuario quiere subir una imagen, recién cuando verifico que el mismo ha subido la imagen, que es una imagen válida y que se necesita crear un thumbnail, cargo mi class que genera el thumbnail y recién ahí la genero. Antes no. De esa forma, si la creación del thumbnail no se aplica, simplemente se omite ese paso.
La única excepción a esta regla es la class que se conecta a la DB y que me permite realizar consultas: en el 99% de las páginas se ocupa, por lo tanto, prefiero cargarlo siempre y tenerlo listo para las demás. Si alguna página no necesita de acceso a la base de datos, bueno, mala suerte, hay 99 otras páginas que sí lo necesitan.
Al final, lo que se hace, es; mediante un solo include al principio de index.php; generar un ambiente de trabajo, que verifica permisos, verifica módulos a cargar, establece variables, deja a disposición ciertas funciones que podrían o no llegar a ocuparse, y un largo etc.
Después tengo en un archivo aparte lo que es el HTML en sí: el header y el footer están separados, y especialmente el header puede recibir un montón de parámetros que se establecen antes: el título de la página, si cargar o no cargar ciertos CSS, .js, si hay algo que hacer en el onload del body, etc. Si existe algún menú lateral, éste se cargará (una sola vez) en el header.
Cita:
Iniciado por basa El autoload, te permite la posibilidad de cargar sólo aquellos ficheros que se necesitan en el momento, mientras que sin él, tendría que cargar todos los ficheros se vayan o no a utilizar (siempre buscando el mayor rendimiento posible con el APC). Incluso siguiendo el principio de sólo cargar aquellos ficheros que una clase pueda necesitar, seguramente vaya a necesitar cargar dos veces el mismo fichero (esto es, tener que escribir en más de un sitio el mismo código).
Idealmente, nunca será necesario cargar un mismo archivo dos veces. Todo depende del orden que se tenga.
Cita:
Iniciado por basa Que pasa si cambio de nombre a uno de los ficheros en un punto en el que la aplicación ya ha crecido bastante?
Sólo una vez me ha pasado eso xD Fue cuando me pidieron si podía llevar el sitio de MySQL a PostGreSQL. El único problema es que la class que se llamaba db.class.php había que renombrarla a mysql.class.php para mayor claridad. Afortunadamente, sólo se incluía una sola vez en un solo archivo, así que no fue tan grave.
Cita:
Iniciado por basa Que pasa además cuando quiera meter un nuevo módulo. Tendré que modificar el motor de la aplicación para que importe los nuevos ficheros
Siempre hay que dejar las puertas abiertas a nuevos desarrollos, y se pueden dar dos situaciones diferentes:
1.- Dejo una plantilla: por ejemplo, en cierta aplicación, cuando se desarrolla un nuevo módulo, tengo una plantilla con todo lo necesario para empezar:
Código PHP:
Ver original<?php
include('includes/sesiones.php');
$titulo = 'No funcionando todavía';
include('includes/header.php'); ?>
<h1 class="titulo-pagina">Título descriptivo de la página</h1>
<p class="descripcion-pagina">Pequeño texto que muestra información más extendida de qué hace la página. (Opcional, no tiene que ser más de dos líneas!)</p>
<?php mensajes(1,'Módulo en desarrollo!'); ?>
<!-- Inicio HTML -->
Contenido de la página
<!-- Fin HTML -->
<?php
DibujaVacio(25);
include('includes/footer.php');
?>
2.- Creo toda una base para la incorporación de nuevos módulos, es bastante más complicado pero permite una carga 100% modular
siempre y cuando se sigan las reglas establecidas por el software.
Cita:
Iniciado por basa Esto se solucionará creo yo, cuando se implemente el concepto de paquetes, lo cual espero no tarde en llegar, donde solo necesitarías importar un paquete (puediendo contener este un montón de clases)y entonces sí, el APC será algo aprovechable, pero de momento prefiero la flexibilidad que te da el autoload de ficheros creo...
Además, a nivel de rendimiento y optimización se pueden hacer muchas más cosas... caché de salida, compresión gzip, optimización de las llamadas a bases de datos etc... y sobre todo, hace poco leía un artículo en el que decían que el mayor cuello de botella se genera en el cliente en un proporción del 80%, con lo que la optimización del lado del cliente es quizás lo más importante.
Frente al primer párrafo: sí, será super interesante.
Segundo párrafo: sí, a nivel de optimización se pueden hacer muchísimas cosas... pero depende de uno implementarlas xDD
El contenido gzippeado de la página no se va a realizar JAMÁS a menos que uno mismo lo habilite, ya sea por Apache [personalmente mi método preferido] o bien por ob_start('ob_gzhandler'), después el ob_length (para establecer la cabecera Content-Length si no se quiere que el cliente reciba los datos de forma "chunked" [no sé cuál es la traducción de ese término, debería ser "por pedazos" o algo así]) y finalmente el ob_end_flush().
De todas formas, tal como dije más arriba, el cliente sí se va a dar cuenta que la página carga lento si se demora más de 2 segundos en
generarse (AKA lo que PHP se demora en procesarla), y eso es responsabilidad única y exclusivamente nuestra.
Ah bueno, como último punto: con el esquema de arriba se aprovecha plenamente APC, ya que va a tener en su caché todo el opcode de los includes :D
Saludos !!
