Semplice / CRUD riutilizzabili in PHP (NO quadro per grandi classi)

Question

Sto lavorando su un CMS PHP come progetto e sto cercando di scoprire che cosa è il modo più conveniente di trattare con la funzionalità CRUD in PHP.

Il CMS è programmato completamente in PHP procedurale (senza OOP - So che molti di voi non saranno d'accordo con questo ...) ed è stato progettato tenendo tutto il più semplice e leggero possibile, così come la creazione di funzioni altamente riutilizzabili e frammenti di codice.

Il CMS consente a più moduli da installare / attivato sulla base esigenze. Questi moduli descrivono diversi tipi di contenuti così io probabilmente finirà per avere qualcosa di simile pagine, notizie, blog solo per citarne alcuni.

Per ciascuno di questi tipi di contenuto che dovrà creare le operazioni CRUD e ora sto cercando di trovare il modo più conveniente per raggiungere questo obiettivo.

Un requisito è che il modulo per ciascuno di questi tipi di contenuto è contenuto in un singolo file esterno (sia per inserimento e modifica) e se c'è qualche modo per integrare convalida dell'input lato server che sarebbe un plus.

Answer 1

Per le operazioni CRUD vuoi dire solo le query (noioso) di database?

Si potrebbe altrettanto facilmente configurare il database in modo che, fatta eccezione per un paio di campi comuni tra i tipi di contenuto, tutti i dati per un particolare tipo di contenuto viene memorizzato come un array associativo serializzato in un campo di testo.

In questo modo è necessario solo 1 set di query per CRUD qualsiasi tipo di contenuto particolare dal momento che i dati passati alle funzioni CRUD è solo ciecamente serializzato.

Per esempio, diciamo che dichiariamo che titolo del contenuto, data di creazione / aggiornamento, tag e breve descrizione sono considerati dati comuni. Da lì abbiamo un blog e un tipo di contenuto della pagina.

Vorrei possibilmente creare una tabella di database in quanto tale:

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`)
)

(Vai avanti e assumere creeremo le tabelle di riferimento per content_type)

E mentre il blog potrebbe richiedere i dati come "pingbacks" e la pagina potrebbe richiedere altro che il corpo, basta memorizzare l'output di qualcosa come l'esempio di seguito per un blog:

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

Gli aggiornamenti sono facili, ogni volta che si afferra i dati dal database si unserialize i dati per la modifica in una forma selezionata in base al tipo di contenuto. Visualizzazione lavori allo stesso modo, basta afferrare un modello in base al tipo di contenuto e inviarlo l'array di dati deserializzato. Il modello non ha mai bisogno di preoccuparsi di come i dati vengono memorizzati, solo che si ottiene un $ dati [ 'pingbacks'].

Per quanto riguarda i moduli, il mio suggerimento è quello di rompere il vostro anti patto OOP e trovare una libreria generazione modulo. Se è possibile estrarre dal quadro, utilizzando Zend_Form con Zend_Config e Zend_Validate dal Zend Framework (tutto Zend_Config ammonta a in questa situazione è una comoda interfaccia per caricare e XML traverse e file INI) rende la vita veramente bello. Si possono avere i file XML definiscono il modulo per ogni tipo di contenuto, e tutto quello che vorrei fare è solo il rendering del modulo nella pagina (afferrando la XML in base al largo di tipo di contenuto), afferrando i dati filtrati, eliminando i "campi comuni" come nome, creato / Disponibilità aggiornata, quindi la serializzazione ciò che resta nel database. Non è richiesta alcuna conoscenza dello schema per un particolare tipo di contenuto (a meno che non si desidera essere rigorosi).

Anche se come un personal parte altamente li suggerirei di guardare in afferrando Zend_Form (con Zend_Validate e Zend_Config), nonché utilizzando Dottrina come un livello di astrazione ORM / database. Si potrebbe scoprire che almeno Dottrina renderà la vostra vita molto più facile quando si tratta di operazioni in esecuzione sul database.

Answer 2

  

Anche se come un personal parte altamente li suggerirei di guardare in afferrando Zend_Form (con Zend_Validate e Zend_Config) così come usando Doctrine come un livello di astrazione ORM / database. Si potrebbe scoprire che almeno Dottrina renderà la vostra vita molto più facile quando si tratta di operazioni in esecuzione sul database.

Sono d'accordo con dcousineau. Perché rotolare il proprio quando è già fatto? Vorrei anche dare un'occhiata alla Zend DB , e se avete bisogno un PHP4 e 5 soluzione PHP ADOdb .

ho iniziato un progetto accademico di recente e aveva lo stesso desiderio come voi; alla fine sono andato con PHP ADODB.

Answer 3

Suggerisco www.ajaxcrud.com - è facile da usare, leggero, e si ottiene in servizio in pochi secondi.

Answer 4

Si può provare questo: http://xcrud.com , davvero disponibile