elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: ¿Eres nuevo? ¿Tienes dudas acerca del funcionamiento de la comunidad? Lee las Reglas Generales


+  Foro de elhacker.net
|-+  Programación
| |-+  Desarrollo Web
| | |-+  PHP (Moderador: #!drvy)
| | | |-+  MINIFRAMEWORK - que les parece la lógica?
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: MINIFRAMEWORK - que les parece la lógica?  (Leído 1,729 veces)
Karman


Desconectado Desconectado

Mensajes: 673



Ver Perfil WWW
MINIFRAMEWORK - que les parece la lógica?
« en: 22 Mayo 2009, 05:41 am »

Buenas, estoy desarrollando un miniframework con el cual estoy armando páginas para varios clientes con distintas bases de datos y configuraciones de servidor... (dos puntos que me han quebrantado hasta hoy), la idea de este post es exponer como lo estoy desarrolando para ver si se puede mejorar y obviamente facilitar mi vida..  :P

La idea actual es la siguiente, está totalmente programado en objetos y tiene un solo archivo direccionador (index.php)

Hay una clase base X(base), que es la index.php crea, esta clase se encarga de inicializar la base de datos (objeto), obtener información de la versión del software y otras configuraciones generales (en DB), inicializar sesiones(objeto), obtener datos de usuarios(objeto), (si sesiones le dice que hay alguno) y obtener parámetros enviados...

Si todo ok... index.php llama a "X->visualizar", función que se encarga de crear un objeto Módulo que se crea en base a los parámetros enviados... cada módulo está en DB y tiene su grupo de variables de módulo y dos especiales que son Archivos y Secciones...

El método principal del Objeto módulo tiene únicamente dos respuestas... Falso si no existe el módulo o el usuario no tiene permisos, o el resultado del modulo en si (aclaro que trabajo con Smarty ), el módulo (dependiendo de las variables del mismo) crea dos subclases (secciones y archivos), dichas clases son dependientes del módulo, otorgando o restringiendo permisos dependiendo del módulo y usuario (un módulo no puede borrar un archivo de otro módulo o un usuario con pocos permisos no puede eliminar una sección de un usuario con más permisos, etc...), osea quedaría esta estructura (mas o menos)

Citar
       index.php
              |
         sistema
       /      |      \
   DB  sesiones  usuarios
       \      |       /
          modulo
         /     |     \
  archivos |  secciones (o categorías)
         \     |     /
       modulo en si (noticias, descargas, etc...)

ustedes que piensan? como se podría mejorar?

S2


En línea

Nakp
casi es
Ex-Staff
*
Desconectado Desconectado

Mensajes: 6.336

he vuelto :)


Ver Perfil WWW
Re: MINIFRAMEWORK - que les parece la lógica?
« Respuesta #1 en: 22 Mayo 2009, 06:59 am »

que tal algo como mvc


En línea

Ojo por ojo, y el mundo acabará ciego.
Karman


Desconectado Desconectado

Mensajes: 673



Ver Perfil WWW
Re: MINIFRAMEWORK - que les parece la lógica?
« Respuesta #2 en: 22 Mayo 2009, 13:53 pm »

Es lo que utilizo... (aunque no recordaba el nombre...) por eso aclaré que trabajo con Smarty... en este caso mi controlador es index.php...

S2
En línea

^Cloud^

Desconectado Desconectado

Mensajes: 64


La tierra es plana.


Ver Perfil
Re: MINIFRAMEWORK - que les parece la lógica?
« Respuesta #3 en: 25 Mayo 2009, 12:54 pm »

Si quieres que tu framework funcione con distintas bases de datos deberías implementarlo como modo factoría, de esta forma podrás usar el concepto de driver para interconectar con bases de datos distintas.

Para ser un framework OO no veo claro el gráfico que pones... no parece que tenga relación con ningún modelo OO que viera. Si quieres hacerlo mejor instálate Dia o cualquier otro programa gratuito que te permita hacer modelos UML.

Intenta abstraerte más de lo que es el producto final. Un modelo de desarrollo tiene que tener suficiente capacidad de abstracción como para que se pueda utilizar en varios casos diferentes. Con esto quiero decir que los usuarios son sólo entidades existentes en el sistema que podrían tener permisos de una lista de control (ACL) y/o roles.

Si planteas tu sistema como un sistema modular, los módulo deberían ser una extensión de lo que ya existe y deberian abstraerse de los tipos de datos. Yo haría una interface para implementar a posterior los modulos que necesitase. Si planteas tu sistema con dos tipos de datos definidos vas a cometer un error de base que luego te puede contar solucionar.  Toma cualquier contenido que exista como una entidad, una entidad puede tener atributos y propiedades que son los que le dan las características a cada contenido. Si defines los contenidos (cualquier contenido) como si fuera una entidad para tu framework, podrás ampliarlos, modificarlos y crear tantos tipos de contenidos como necesites.

Falta la capa de presentación.

Vas por buen camino.

Un saludo,
En línea

Ahora resulta que imagino mi pasado
y llevo en esta clínica cuarenta años.
Nunca jamás he pisado la calle
y el electroshock ha sido mi padre
Karman


Desconectado Desconectado

Mensajes: 673



Ver Perfil WWW
Re: MINIFRAMEWORK - que les parece la lógica?
« Respuesta #4 en: 25 Mayo 2009, 20:18 pm »

Si quieres que tu framework funcione con distintas bases de datos deberías implementarlo como modo factoría, de esta forma podrás usar el concepto de driver para interconectar con bases de datos distintas.

si, en realidad utilizo php adodb, por lo que no tengo tanto que preocuparme por las bases de datos... solo por algunas sentencias no compatibles..

Para ser un framework OO no veo claro el gráfico que pones... no parece que tenga relación con ningún modelo OO que viera. Si quieres hacerlo mejor instálate Dia o cualquier otro programa gratuito que te permita hacer modelos UML.

voy a probar...

Intenta abstraerte más de lo que es el producto final. Un modelo de desarrollo tiene que tener suficiente capacidad de abstracción como para que se pueda utilizar en varios casos diferentes. Con esto quiero decir que los usuarios son sólo entidades existentes en el sistema que podrían tener permisos de una lista de control (ACL) y/o roles.

esa es la idea, por eso lo estoy tratando de hacer lo más genérico y simple posible el sistema de comunicación cosa que permita lograr grandes cambios en el sistema con pocas modificaciones...

Si planteas tu sistema como un sistema modular, los módulo deberían ser una extensión de lo que ya existe y deberian abstraerse de los tipos de datos. Yo haría una interface para implementar a posterior los modulos que necesitase.

si, la cosa es así, existe un objeto módulo que es creado por el sistema enviándole los parámetros del entorno, este objeto "se crea" de acuerdo a estos parámetros y va llamando a funciones "propias del módulo en si", algo así como:

Citar
objeto: noticia                         modulo:noticia.php
this->crear(...)                        funcion noticia_crear($zthis,$args)...

con la salvedad que "crear" es un argumento enviado del entorno... de esta forma en mi función noticia_crear tengo...

Citar
$zthis (objeto base)
$zthis->BD (base de datos con chequeo interno de privilegios)
$zthis->user (información pertinente al usuario actual)
$zthis->sesion (información de sesiones)
$zthis->files [opcional] (objeto que me permite trabajar con archivos, algo así como un gestor)
$zthis->sections [opcional] (objeto que permite categorización de contenido)

el sistema también contempla la opción de instalar nuevos módulos "on runtime", de esta forma lo único que debe ser instalado "manualmente" es el corazón...

Si planteas tu sistema con dos tipos de datos definidos vas a cometer un error de base que luego te puede contar solucionar.  Toma cualquier contenido que exista como una entidad, una entidad puede tener atributos y propiedades que son los que le dan las características a cada contenido. Si defines los contenidos (cualquier contenido) como si fuera una entidad para tu framework, podrás ampliarlos, modificarlos y crear tantos tipos de contenidos como necesites.

si, por eso es que por ejemplo con el tema de los archivos de los módulos (algo que utilizo mucho) el objeto "Files" es el que se encarga de (sin importar el tipo de archivo) almacenarlo donde corresponda (física y lógicamente en la DB) y devolver un identificador único de archivo, luego este identificador es doblemente almacenado con los atributos propios del tipo de archivo (archivo físico o referencia a archivo externo, imagen, sonido, etc..., etc...)

S2
En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines