Entità in Drupal 7

Cosa sono le entità Drupal in Drupal 7? Comprendo che Drupal Commerce ha costruito i Prodotti come entità. Ora so che esiste un'API Entity di base e un componente aggiuntivo per l'API Entity.

Quest'anno ho alcuni progetti in cui vorrei usare Drupal 7, NoSQL e possibilmente l'API Entity se lo richiede, ma ho problemi a vedere dove sarebbe necessario.

Supponendo che stavi costruendo un sito di elenchi di lavoro - un lavoro non è necessariamente come il contenuto del nodo, potresti / vorresti trasformarlo in un'entità?

Inoltre, puoi ancora avere la possibilità di parlare con i moduli con l'Entità e come si fa? Ad esempio, un'entità Job Posting viene aliasata con Pathauto ed esposta in Views così come appare in Sitemap XML.

Un'entità è una struttura di dati definita da hook_entity_info () e può essere fieldable, il che significa che è possibile aggiungere campi ad essi.

In Drupal 7 Core, nodi, utenti, commenti, vocabolari e termini sono entità.

In Contrib, ce ne sono molti altri, ad esempio messaggi privati ​​e commercio come una dozzina di essi;)

Tuttavia, penso che le offerte di lavoro vadano perfettamente bene come nodi :) Le entità non hanno automaticamente l'integrazione di Pathauto (token), visualizzazioni, ecc.

Le entità sono un meta livello sopra nodi, utenti, ecc.

Fondamentalmente se guardi D6, ci sono molti moduli duplicati e funzionalità in questi tipi di cose. Ad esempio ci sono moduli per collegare i campi cck agli utenti e ai termini della tassonomia.

In D7 è stata presa la decisione di trattarli allo stesso modo, dal punto di vista architettonico, quindi se si dispone di un modulo che fa qualcosa alle entità, dovrebbe funzionare per nodi, termini e utenti.

Nelle versioni precedenti di Drupal, un modulo come Commerce avrebbe avuto due opzioni, per costruire un tipo di nodo personalizzato o per uscire completamente dai sistemi interni di Drupal e definire il proprio tipo di cose. Con le entità, è possibile descrivere un Prodotto come un tipo di cosa, distinto dai tipi esistenti, ma sfruttando ancora funzionalità come i campi nella loro composizione.

Supponendo che stavi costruendo un sito di elenchi di lavoro - un lavoro non è necessariamente come il contenuto del nodo, potresti / vorresti trasformarlo in un'entità?

Potresti. Penso che dovresti stare attento a rendere le entità delle cose troppo in fretta. Spesso i tipi di nodo personalizzati fanno comunque ciò che desideri. Un lavoro elenca un diverso tipo di cosa a un nodo o è un nodo con alcune proprietà speciali?

Ho iniziato a usare entità in alcuni dei miei progetti per cose che non erano veramente "contente". Li usiamo per cose in cui non ci interessa davvero quando è stato pubblicato o chi era l'autore.

I veri vantaggi della definizione di entità sono se stai sviluppando i tuoi moduli personalizzati. Ottieni una bella struttura del tavolo e un sacco di bontà Drupal (Fieldability, integrazione di Views, ...) gratuitamente. Non è più necessario creare strutture di tabella personalizzate o adeguare un tipo di nodo alle proprie esigenze. Inoltre, mi piace quanto siano leggere, quindi le entità in termini di prestazioni dovrebbero essere migliori. Se hai fatto domande in D6 con nodi capirai cosa intendo.

Nodi, utenti, tassonomie sono esempi di entità Drupal. La caratteristica principale di un'entità è che può essere assegnata ad altre entità: un utente è associato a un nodo e una tassonomia può essere assegnata a nodi e utenti.

Se ciò che descrivi come lavoro può essere assegnato a un utente o a un nodo, lo farei diventare un'entità. Se quello che puoi "lavorare" è solo un tipo di contenuto, allora non lo farei diventare un'entità.

Se vuoi dirlo in poche parole, puoi dire che l'entità è solo un dato di cui Drupal è a conoscenza e che può essere archiviato ovunque.