Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Creative Coding
Code

Usare Wordpress per lo sviluppo di applicazioni Web : Il Modello Concettuale

by
Length:MediumLanguages:
This post is part of a series called Using WordPress for Web Application Development.
WordPress for Web App Development: Rethinking Architecture
WordPress for Web App Development: Events, Actions, and Filters

Italian (Italiano) translation by Piergiorgio Sansone (you can also view the original English article)

La gente incomincia a realizzare il potenziale di "WordPress" come una base per un'applicazione piuttosto che solo come un sistema di gestione dei contenuti o una piattaforma di blogging, questa serie si sta concentrando su quanto WordPress può essere usato per tali progetti.

Una delle cose più importanti da notare è che WordPress non vuole essere la soluzione definitiva per la costruzione di applicazioni web. In effetti , non penso che qualsiasi foundation (base) o framework vogliano essere la soluzione definitiva.

Invece , abbiamo un numero di scelte differenti , ogniuna delle quali si presta a situazioni migliori rispetto ad altre , e WordPress non è differente. Attraverso questa serie, continueremo ad occuparci di come sia possibile costruire un'applicazione web con WordPress, e quali altre situazioni siano a loro volta megliori di una base. Tuttavia, dobbiamo continuare la nostra discussione su come lavora WordPress per poter cominciare a parlare su come costruire applicazioni sopra di esso.

Nell'articolo precedente, abbiamo parlato di come molti framework affrano un approccio MVC per lo sviluppo , ma abbiamo anche visto il modello event-driven di WordPress. In questo post, vedremo in profondità il paradigma event-driven che WordPress impiega e perchè è importante.

La verità è che molte persone hanno familiarità con questo paradigma, mentre non ne hanno con la naming conventions. Alla fine di questo articolo, capiremo chiaramente che cos'è la programmazione event-driven, come funziona e come viene implementata in WordPress, e di cosa avremo bisogno per pensarci quando proveniamo da altri modelli come l' MVC.


La Programmazione Event-Driven

Nel precedente post, abbiamo riassunto la programmazione event-driven con la seguente idea :

Invece, la programmazione event-driven funziona fuori della premessa che "qualcosa è accaduto" Da qui il nome di azioni nel gergo WordPress (naturalmente, abbiamo anche i filtri, ma mi occuperò di quelli brevemente).

E questo è bene per una definizione operativa di eventi, soprattutto ad un alto livello. Tuttavia, se si vuole dare uno sguardo più approfondito a cosa assomiglia da un punto di vista pratico, cioè come WordPress lo implementa, allora probabilmente la cosa migliore che si può fare è capire gli eventi.

Molto più di questo, è importante capire il ciclo di vita delle pagine di WordPress, dove avvengono gli eventi, e come da sviluppatori, possiamo aggancirci a questi per eseguire una determinata attività.


Capire gli Eventi

Come abbiamo già detto, nella programmazione event-driven, l'idea di evento è semplicemente che qualcosa è accaduto. Continuiamo a ribadirlo, ma cosa significa veramente?

Nel contesto di un singolo caricamento della pagina, ci sono una serie di cose che si verificano:

  • vengono recuperati JavaScript e fogli di stile
  • le query vengono eseguite sul database per recuperare i dati
  • Le informazioni provenienti dal database vengono visualizzate (renderizzate) nel contesto del markup
  • La pagina viene presentata all'utente
  • ...e cosi via

Tutti questi possono essere considerati gli eventi, ma ognuno di questi è costituito da una propria serie di piccoli eventi - questo è, si può ottenere  un dettaglio reale in merito a quando succede qualcosa.

Prendiamo per esempio, l'idea di renderizzare una tipica richiesta per una pagina alimentata di WordPress. Se guardate la documentazione Codex associata, vedrete che ci sono approssimativamete 50 azioni che si verificano, e questa non include nei posto o pagine specifiche azioni.

Ognuna di queste azioni può essere considerata un evento, e nel mondo della programmazione event-driven, gli eventi sono di solito esposti in modo tale che ci permettono di agganciarci a loro e manipolare le informazioni prima di essere renderizzate al cliente.

Da qui il nome ganci (hooks).

Naturalmente, in WordPress i ganci sono di due tipi : Azioni e Filtri. Sebbene questa serie non sia un solido tutorial per ogniuno di questi è importante riconoscere le differenze che hanno e come sono collegati per lavorare con WordPress.

Azioni

Le Azioni sono un tipo di gancio che significa che qualcosa è accaduto, e quando questo qualcosa accade , siamo nella condizione di registrare le nostra funzionalità in modo tale che possiamo iniettare il nostro codice (o addirittura impedire che certe cose accadano).

Come ho riassunto nella mia serie dedicata ad Azioni e Filtri :

Le Azioni sono eventi nel ciclo di vita della pagina WordPress quando certe cose si sono verificate - alcune risorse vengono caricate, alcune strutture sono disponibili, e, a seconda di quanto velocemente si è verificata l'azione, alcune cose non sono ancora state caricate.

E' importante capire le azioni disponibili in modo da sapere quand'è il momento migliore per agganiciare un dato evento,  cosi da non ridurre le performance della pagina , potenzialmente rovinare gli altri dati che provengono da valle del processo, o giu di li, che sei in grado di gestire le informazioni al momento ed al posto giusto.

Filtri

I Filtri , nell'altra mano , sono un tipo di ganci che ci consentono di ricevere alcuni pezzi d'informazione , manilpolarli e poi rilasciarli a WordPress prima che vengano renderizzati dal browser.

Per esempio , se date un occhiata al filtro the_content, noterete che se lo agganciate alla funzione in questa particolare azione, la vostra funzione vi restituirà il contenuto. Ciò significa, siete in grado di manilpolare il contenuto inserendoci informazioni, rimuovendone da esso o qualcosa di simile, prima di restituirle a WordPress per renderizzarle al browser.

Analogamente, ho riassunto i filtri nella mia serie dedicata ad  Azioni e Filtri  come segue:

I Filtri sono funzioni che WordPress passa attraverso i dati durante certi punti del ciclo di vita della pagina Principalmente sono responsabili della intercettazione , gestione e ritorno dei dati prima del rendering al browser o del salvataggio dei dati nel database dal browser.

Quindi , detto questo , le azioni ed i filtri sono entrmbi tipi di eventi che si verificano all'interno del ciclo di vita di WordPress che ci consentono di agganciarli tra loro e di inserire nostro codice per eseguili prima di averli renderizzati al browser.

In breve, il termine "gancio" è un termine generico che si riferisce ad entrambi, azioni e filtri, ogniuno dei quali servono uno scopo diverso.


Analogamente ad MVC?

Ora, una delle cose che comunemente vedo nelle persone che provengono da differenti esperienze passate come Rails, CakePHP,ASP.NET, o altri framework MVC, è  come mappano il loro modello concettuale di MVC con il modello event-driven di WordPress.

Con questo, voglio dire cercano di trovare delle analogie con i modelli , le viste ed i controllers nel paradigma event-driven. Per esempio , molti provano a fare come segue :

  • "Se le viste sono pensate per la presentazione dei dati, allora sicuramente questo è ciò che i modelli sono per WordPress." Beh, sì, in una certa misura, ma i modelli sono anche influenzati da vari ganci e invocati in determinate funzioni.
  • "Se i ganci sono utilizzati per coordinare i dati il database e le viste , si comportano come i controllori" Più o meno, ma possono anche rappresentare dati specifici dalla logica simile ad un modello, e possono essere utilizzati anche semplicemente come aiutanti per formattare le informazioni che è molto più simile ad aiutanti di controllori reali.
  • "Ma se il modello, o le viste , possono essere richiamate nei controllori , o i ganci , allora dove colloca il modello?" Esattamente, puoi raccogliere tutte le similitudini che vuoi , e prendere le migliori, ma la verità e che WordPress non è un MVC.

.A tal fine , vi raccomando di cercare di evitate di pensare a WordPress nel contesto di un'altro modello. Ha il suo modello. Pensare in questi termini.

Non si tratta di adeguarsi!

In breve, giungere a WordPress da un'altro framework che utilizza un'altro modello o un altro paradigma va bene , ma non si tratta di modificare WordPress a misura in base alla vostra esperienza precedente.

Non potete adeguare un design pattern in un'altro ed aspettarvi di avere gli stessi standard qualitativi.

I software non lavorano in questo modo.

Invece, proprio come si fa con altri framework, è necessario pensare in termini di come funziona WordPress per costruire correttamente le cose su - e per - WordPress. Più avanti nella serie, vedremo perchè WordPress è una solida opzione per le applicazioni web, ma prima di questo credo sia importante capire il modello implementato da WordPress e come trarne i migliori vantaggi.


Esempi pratici di Eventi

Nel prossimo post , daremo un'occhiata ad alcuni esempi su come possiamo agganciarci ad un evento fornito da WordPress. Questo sarà molto introduttivo e molti svilupatori WordPress di grande esperienza ne già ne conosceranno molti; tuttavia fornirò una solida serie di esempi di come le azioni e filtri - e quindi gli eventi - lavoro in WordPress.

Dopo di che continueremo la nostra discussione, per quanto riguarda le caratteristiche e le strutture che WordPress offre per la creazione di applicazioni web.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.