Ver Mensaje Individual
  #26 (permalink)  
Antiguo 10/10/2013, 07:54
AlanChavez
 
Fecha de Ingreso: junio-2010
Ubicación: Charlotte, NC
Mensajes: 611
Antigüedad: 13 años, 10 meses
Puntos: 95
Respuesta: tengo una duda, se debe cerrar la etiqueta <?php en algunos manuales dice

Cita:
Iniciado por dashtrash Ver Mensaje
Y qué tiene que ver el protocolo FTP o los IDEs con la arquitectura de aplicaciones?


Serie de cosas que no vienen al caso.


Cosas que tampoco vienen al caso, y sigue sin tener nada que ver con arquitectura de aplicaciones.


Vaya, esto si tiene que ver con arquitectura de aplicaciones.El uso de ob_start, sobre todo para control de caracteres en blanco , y ni digo ya para hacer buffering de páginas completas, es una práctica horrenda, y que
de por sí, indica una mala arquitectura.Sí, ya sé que muchos frameworks lo hacen.


No tiene nada que ver con lo que se dice.


Sigo sin saber qué tiene que ver tu IDE, o si usas FTP o no, con la arquitectura de aplicaciones.A menos, claro, que confundas arquitectura de aplicaciones, con entorno de desarrollo, que es básicamente lo que está pasando aqui.

Y, exactamente, cuál es el problema de que lo que tú solucionas debido a un cierto entorno de desarrollo, se solucione usando características propias del lenguaje?
Muchisimos IDEs viejos insertan una linea o un espacio en blanco al final del archivo (Algunas versiones de Dreamweaver lo hacían).

Ese espacio en blanco, produce los errores "Headers already sent".

La misma documentación de PHP recomienda no cerrar el tag de PHP porque es redundante:

http://php.net/basic-syntax.instruction-separation

Si no sabes ingles, te interpreto lo mas importante:

Cerrar el tag de PHP al final de un bloque de código es completamente opcional, y en algunos casos omitirlo te beneficia cuando utilizas "include()" o "require()" porque no encontraras espacios en blancos al final de los archivos.

ob_start mala practica?

ob_start puede aumentar la carga de tu sitio si utilizas compresión GZIP.

O como explicas la siguiente instrucción?
ob_start("ob_gzhandler");

La única desventaja que le veo a output buffering es que los headers se mantienen en el servidor en lugar de ser enviados inmediatamente, lo cual puede crear un overhead en la memoria.

El otro "problema" es simplemente ignorar que tan grande es tu buffer, y cualquier excepción o error va a hacer que pierdas toda la información que esta en tu buffer.

Otro "problema" de output buffering es que algunos programadores utilizan flush(); en el momento incorrecto. Si vas a mezclar codigo de PHP con HTML, entonces lo recomendable es poner el metodo flush() despues del tag </head> de HTML, de esta manera los navegadores pueden empezar a descargas los recursos de tu pagina en paralelo mientras tu backend sigue trabajando. Asi que no me vengas a decir que ob_start es mala practica.

Zend utiliza output buffering casi para todo, y los errores "headers already sent" no suceden si sigues las buenas practicas de programación, la cual una de ellas es NO CERRAR EL TAG DE PHP.

Aqui esta mira, por si no me crees:
http://framework.zend.com/manual/1.1...ormatting.html

THE CLOSING ?> PHP TAG IS NEVER PERMITTED.

Mas claro ni el agua.

Última edición por AlanChavez; 10/10/2013 a las 08:07