Creo que vale la pena hacer un resumen en portada con el intercambio que estamos teniendo, ya que he visto en muchos proyectos y a muchos desarrolladores cometer los mismos errores, por consiguiente creo les puede ser útil.
En mi post anterior recibí el siguiente comentario de uno de los responsables del proyecto con lo siguente:
enrique_place dijo...Estimado Deivinson Tejeda:
Gracias por tus comentarios, te respondo por puntos:
> Hola enrique bueno hay cosas que
> tomo para mejorar el framework y
> otras que desde mi modesto punto
> de vista(mas no malcriades) no
> vienen al caso o simplemente no
> pueden ser criticas.
Bien, está aclarado en mi post que "me tomo el atrevimiento de hacer la siguiente revisión rápida", pero de todas formas no comparto tu opinión (ahora te lo aclaro).
> Critas que NO Acepto
> 1->Nomenclatura CamelCase solo
> lo utilizamos para las class,
> nadie dice q eso se debe
> utilizar tal y como comentas.
Es un estandar en la mayoría (por no decir todos) los lenguajes POO, muchos desarrolladores siguen usando el estándar viejo porque así inició PHP con la práctica estructurada y todas sus funciones usan esa nomenclatura, pero no se debe seguir cuando se habla de objetos.
Por ejemplo, se sabe que Sun define todos los estándares de Java y a nadie se le ocurre no seguirlos, en nuestro caso están empezando a existir fuertes "sugerencias" de parte de Zend ("nuestra Sun") para seguir el criterio "camelcase", porque justamente, lo usan la mayoría de los lenguajes POO (nuevamente, por no decir todos).
Por consiguiente es de sentido común hacerlo así.
Aquí te dejo un enlace de Zend hacia los estándares de codificación: presentación.
De la misma forma, está en la documentación de Zend, pero esto no tiene nada que ver por el framework, es en sí porque la programación que hacen dentro y fuera es siguiendo prácticas generalizadas de POO.
Lo que ustedes están haciendo es seguir las "malas prácticas" de toda la vida que se han realizado en PHP (y lamentablemente es muy común verlo en nuestro rubro).
> 2-> Chasert a pesar que el utf-8
> es el mas utilizado no quiere
> decir que todos se van a regir
> por ese nuestro framework esta
No es correcto, UTF-8 sustituye a ISO como una evolución hacia un sistema que resuelve los problemas del sistema anterior (justamente, los caracteres especiales).
Leer UTF-8
"Por supuesto, la ventaja más notable de cualquier Formato de Transformación Unicode sobre codificaciones heredadas es que este puede codificar cualquier carácter."
UTF-8 sustituye a ISO. Si usan todo UTF-8, pueden escribir cualquier carácter directamente y funcionará sin tener que hacer nada especial.
La única contra es que PHP5 aún no es compatible con UTF-8 a nivel de funciones, es decir, hay muchas funcines que devolverán ISO, pero para la mayoría de los casos es transparente (o a lo sumo usas funciones de encode y decode).
El 90% del desarrollo de PHP6 es migrar todas las funciones para que sean 100% compatibles con UTF-8.
En resumen a "grueso modo" se puede decir que "ISO casi desaparece a partir de PHP6".
Otro artículo de este blog sobre el tema
> pensado para una comunidad
> hispana esto quiere decir que
> existen caracteres especiales
> por ende el mas idonio para para
> eso es ISO-8859-1 de paso el
Falso, existe UTF-8 para cada uno de los idiomas existentes. Si te fijas, cuando creas una base de datos también te preguntará y le puedes decir "utf8_spanish"
> framework no te obliga a
> utilizarlo si el usuario que
> decide utilizar el framework le
> gusta mas utf-8 u otro charset
> lo puede cambiar sin problema...
La idea es que cuando se use un determinado tipo de charset, se use en todas las capas de forma uniforme, de lo contrario puedes tener problemas de "roturas" de caracteres.
Se debe grabar en utf-8, colocar en el cabezal html utf-8, y crear la base de datos en utf-8 (no así las tablas ni los campos, así queda todo estándar según la base).
> Pero sin duda que tus criticas
> caen bien claro con las
> aclaraciones pertinentes...
Las aclaraciones son erróneas, espero que se comprenda.
A lo cual posteriormente anexo:
enrique_place dijo...Adjunto anexo a la discusión, que me parece aporta y complementa:
Post: "¿La empresa cuenta con framework propio?"
Algunos puntos interesantes que comenta el autor:
- "A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas"
- "El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda."
- "En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente"
Con esto no quiero decir que esté de acuerdo o no con el desarrollo de un framework (como en este caso es Kumbia), sino todos los puntos que hay que tener en cuenta, tanto "en contra" como "a favor" a la hora de hacer un proyecto como este, que de por sí es una carrera que se hace "de atrás" y "perdiendo".
Hola enrique bueno hay cosas que tomo para mejorar el framework y otras que desde mi modesto punto de vista(mas no malcriades) no vienen al caso o simplemente no pueden ser criticas.
Criticas que Acepto.
1->Clases con Atributos públicos iremos corrigiendo esto paulatinamente.
2->Métodos Extensos...
Critas que NO Acepto
1->Nomenclatura CamelCase solo lo utilizamos para las class, nadie dice q eso se debe utilizar tal y como comentas. Al momento de crearse el framework se decidio tomar para nombres de metodos la notacion small-case
2-> Chasert a pesar que el utf-8 es el mas utilizado no quiere decir que todos se van a regir por ese nuestro framework esta pensado para una comunidad hispana esto quiere decir que existen caracteres especiales por ende el mas idonio para para eso es ISO-8859-1 de paso el framework no te obliga a utilizarlo si el usuario que decide utilizar el framework le gusta mas utf-8 u otro charset lo puede cambiar sin problema...
Pero sin duda que tus criticas caen bien claro con las aclaraciones pertinentes...
25/6/08 10:51 AM