Qual è lo scopo della funzione entity_metadata_wrapper () e perché dovrei usarla?


23

Sembra che stia sviluppando componenti aggiuntivi per molti moduli che utilizzano Entity API al momento e la entity_metadata_wrapper()funzione continua a spuntare.

La pagina dei documenti dice questo a riguardo:

Restituisce un wrapper di proprietà per i dati forniti.

Se un'entità viene spostata, il wrapper può essere utilizzato per recuperare ulteriori wrapper per le proprietà dell'entità.

Ignorando l'ortografia meravigliosamente freudiana della parola "entità", non capisco davvero quale sia lo scopo di questi wrapper.

Capisco che la funzione essenzialmente restituisce una EntityDrupalWrapperclasse:

Il wrapper semplifica l'applicazione dei callback getter e setter delle proprietà dell'entità

Ma quello che non riesco a capire è come semplifichi le cose.

Ad esempio, per aggiornare la proprietà status di un nodo potrei usare questo codice:

$node = node_load($nid);
$node->status = 1;
node_save($node);

È abbastanza pulito. A quanto ho capito (ma potrebbe essere sbagliato) l'utilizzo del codice equivalente entity_metadata_wrapper()sarebbe più dettagliato di così.

Non sono sicuro che sia semplicemente l'uso del termine "wrapper" che mi fa inciampare qui, ma ho anche cercato il codice nel modulo Entity e non sono molto più vicino a capirlo.

Qualcuno è in grado di spiegare quali sono i vantaggi dell'utilizzo di questa funzione e forse fornire un semplice esempio di codice per un caso d'uso comune?


Ciò può aggiungere una comprensione più profonda all'API e agli involucri dell'entità. È un discorso di Fago, il ragazzo dell'Entità. wolfgangziegler.net/drupalcon-denver
Ken,

Grazie, sembra davvero utile dalla mossa iniziale. Ci darò un'occhiata quando avrò del tempo
Clive

Quel "video è stato rimosso da blip" ma le diapositive continuano a essere scaricate.
artfulrobot

Risposte:


23

Sì, cambiare lo stato di un nodo è banale, in quanto si tratta di una proprietà hardcoded.

I campi d'altra parte, sono molto più complicati. Sono nidificati a tre livelli di profondità, mentre c'è field_get_items () per farli nella lingua corretta, non esiste una tale funzione per impostare i valori dei campi. Quindi, devi sempre controllare se un campo è traducibile o meno e devi sapere quale proprietà contiene esattamente i valori che stai cercando / vuoi impostare.

Due esempi che mostrano cosa può fare il wrapper di entità:

  • La seguente riga aggiunge l'elemento commerciale all'ordine, occupandosi della lingua e della proprietà effettiva che contiene l'id di riferimento, tratto dalla seguente risposta /drupal//a/23513/31

    $order_wrapper->commerce_line_items[] = $line_item;
  • Allo stesso modo, essere in grado di accedere direttamente a un valore di un campo, senza dover controllare la lingua o il delta, anche essere in grado di accedere direttamente alle entità di riferimento, prese da /drupal//a/ 33010/31

    $subnode = entity_metadata_wrapper('node', $node)->field_subnode->value();
    $default = $subnode->title;

Il wrapper entità è la forza trainante di moduli flessibili e potenti come l' API di ricerca e le Regole in quanto consente loro di farsi strada attraverso più livelli di riferimenti, in modo da poter ad esempio accedere a un campo del prodotto che un utente ha acquistato in un ordine con qualcosa come [commerce-order:commerce-line-items:0:commerce-product:some-field](potrebbe non essere corretto, ma qualcosa del genere) o aggiungere il sommario del corpo di un nodo di riferimento all'indice di ricerca.

Detto questo, non sono necessariamente appassionato dell'API effettiva del wrapper, sono enormi array interni e che anche le proprietà semplici sono di nuovo classi wrapper. Spero che il sistema di entità migliorata (e, si spera, in campo) in Drupal 8 eliminerà la necessità di un tale wrapper grazie ad entità classificate.


Fantastico, sapevo che mi sarei perso qualcosa. Penso che sia stata la descrizione di EntityDrupalWrapperciò che ha causato la confusione; quando menzionava "proprietà" non mi rendevo conto che i campi fossero coinvolti, pensavo solo che significasse letteralmente che la classe si prendesse cura delle proprietà (nid, status, ecc.). Grazie per averlo chiarito, sapere che il modulo Rules lo utilizza per il selettore di dati ha molto più senso
Clive

@Berdir "Non sono necessariamente appassionato dell'API reale del wrapper ..." Ho gli stessi sentimenti di te. Fai qualcosa per combattere questo? Usi field_view_value () per visualizzare i valori? Come consiglieresti di impostare i valori nei callback personalizzati per un flusso di lavoro o una dashboard personalizzati?
Charlie Schliesser,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.