/ ABM reutilizable simple en PHP (NO marco para grandes clases)

Question

Estoy trabajando en un CMS PHP como proyecto y estoy tratando de averiguar cuál es la forma más conveniente de tratar con la funcionalidad CRUD en PHP.

El CMS está programado completamente en PHP procedimental (sin programación orientada a objetos - Sé que muchos de ustedes no estarán de acuerdo con esto ...) y fue diseñado teniendo todo lo más simple y ligero como sea posible, así como la creación de funciones altamente reutilizables y fragmentos de código.

El CMS permite que varios módulos que se instalarán / activado en función de las necesidades. Estos módulos se describen diferentes tipos de contenido, así que probablemente acabará teniendo algo así como páginas, noticias, blogs sólo para nombrar unos pocos.

Para cada uno de estos tipos de contenido que tendrá que crear las operaciones CRUD y ahora estoy tratando de encontrar la manera más conveniente para lograr esto.

Un requisito sería que la forma de cada uno de estos tipos de contenido está contenido en un único archivo externo (tanto para la inserción y edición) y si hay alguna manera de integrar la validación de entrada del lado del servidor que sería un plus.

Answer 1

Por operaciones CRUD ¿quiere decir sólo las consultas (aburrido) de base de datos?

Se podría fácilmente la configuración de la base de datos de manera que a excepción de unos pocos campos comunes entre los tipos de contenido, todos los datos para un determinado tipo de contenido se almacena como una matriz asociativa serializado en un campo de texto.

De esta manera sólo necesita 1 juego de consultas a crud cualquier tipo de contenido particular, ya que los datos pasan a las funciones CRUD es a ciegas en serie.

Por ejemplo, decimos declaramos que el contenido del título, fecha de creación / actualización, etiquetas, y una breve descripción se consideran los datos comunes. A partir de ahí tenemos un blog y un tipo de contenido de la página.

Me posiblemente crear una tabla de base de datos como por ejemplo:

CREATE TABLE `content` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `name` VARCHAR  NOT NULL,
  `short_description` TEXT  NOT NULL,
  `tags` TEXT ,
  `data` TEXT ,
  `content_type` INT  NOT NULL,
  `created_at` DATETIME  NOT NULL,
  `updated_at` DATETIME  NOT NULL,
  PRIMARY KEY (`id`)
)

(Ir adelante y asumir vamos a crear las tablas de referencia para content_type)

Y mientras que el blog podría requerir datos como "pingbacks" y la página podría requerir nada más que el cuerpo, que acaba de almacenar la salida de algo así como el siguiente ejemplo para un blog:

$data = serialize(array(
    "body" => "Lorem ipsum",
    "pingbacks" => array()
));

Las actualizaciones son fáciles, cada vez que agarra los datos de la base de datos que unserialize los datos para la edición en una forma seleccionada en función del tipo de contenido. Viendo las obras de la misma manera, sólo agarrar una plantilla basada en el tipo de contenido y enviarlo la matriz de datos decodificado. La plantilla no tiene que preocuparse de cómo se almacenan los datos, sólo que se pone un $ data [ ''] Pingbacks.

En cuanto a sus formas, mi sugerencia es que romper su pacto contra la programación orientada a objetos y encontrar una biblioteca de formularios generación. Si se puede extraer de la estructura, utilizando Zend_Form con Zend_Config y Zend_Validate de la Zend (todo Zend_Config asciende a en esta situación es una interfaz conveniente para cargar y XML transversal y archivos INI) hace la vida muy agradable. Usted puede tener sus archivos XML definen la forma para cada tipo de contenido, y lo único que haría es simplemente reproducir el formulario en su página (agarrando el XML con sede fuera de tipo de contenido), tomando los datos filtrados, la eliminación de los "campos comunes" como nombre, fechas creado / modificado, a continuación, la serialización de lo que queda en la base de datos. No se requiere ningún conocimiento del esquema para un tipo particular de contenido (a menos que desee ser estrictos).

Aunque como personales a un lado yo sugeriría usted mira en el acaparamiento de Zend_Form (con Zend_Validate y Zend_Config), así como el uso de Doctrina como una capa de abstracción de ORM / base de datos. Usted puede encontrar que al menos Doctrina le hará la vida mucho más fácil cuando se trata de operaciones que se ejecutan en la base de datos.

Answer 2

  

Aunque como personales a un lado yo sugeriría usted mira en el acaparamiento de Zend_Form (con Zend_Validate y Zend_Config), así como el uso de la doctrina como una capa de abstracción de ORM / base de datos. Usted puede encontrar que al menos Doctrina le hará la vida mucho más fácil cuando se trata de operaciones que se ejecutan en la base de datos.

Estoy de acuerdo con dcousineau. ¿Por qué rodar su propia cuando ya está hecho? También me gustaría echar un vistazo a Zend DB , y si es necesario un PHP4 y 5 solución PHP ADOdb .

Me comenzado un proyecto académico recientemente y tenía el mismo deseo que usted; finalmente fui con PHP Adodb.

Answer 3

Sugiero www.ajaxcrud.com - es fácil de usar, ligero y le permite ponerse en funcionamiento en cuestión de segundos.

Answer 4

Puede intentar esto: http://xcrud.com , muy servicial