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 : Ripensiamo l'architettura

by
Difficulty:IntermediateLength:MediumLanguages:
This post is part of a series called Using WordPress for Web Application Development.
WordPress for Web App Development: An Introduction
WordPress for Web App Development: The Conceptual Model

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

In questa serie , l'argomento che stiamo trattando rigurda l'utilizzo di WordPress per la costruzione di un'applicazione web. Ed anche se questa non è una serie con connotazioni tecniche , in cui ci troveremo di fronte a del codice; tuttavia copriremo argomenti come frameworks , fondazioni, design patterns , architetture e cosi via.

Se non avete letto il primo articolo di questa serie , vi raccomando di farlo ; altrimenti, ai fini di questo post , posso riassumervelo come segue :

In breve, un software può essere costruito utilizzando un framework (partendo da 0 ) oppure può essere l'estensione di una base (ampliando le funzionalità di un software già esistente).

In poche parole , si distingue tra framework e foundation (base) , due termini che spesso vengono usati indifferentemente nel software, nonostante il fatto che essi non siano la stessa cosa WordPress è una base perchè è un'applicazione a se stante. Non è un framework.

A questo punto , quando arriva il momento di costruire un'applicazione web su WordPress, è necessario ripensare l'architettura o riconsiderare il nostro modello concettuale su come sono costruite le applicazioni.


La Struttura di un'applicazione web

Al più alto livello possibile, le applicazioni web sono strutturate con i seguenti tre componenti :

  1. Il Livello Database
  2. Il Livello Applicazione
  3. Il Livello di Presentazione

Generalmente , il Livello di presentazione è ciò che gli utenti vedono e ciò con cui interagiscono. Ciò include , gli stili , il codice lato client ed il markup necessario per mettere qualcosa di fronte all'utente.

Quando un utente clicca su qualcosa , o la pagina visualizza delle informazioni estratte da un database, sta interagendo con il Livello Applicazione.

Il Livello Applicazione è responsabile del coordinamento delle informazioni che vanno dal browser e/o dall'utente a seguito di un azione verso il database. A volte , questo consiste nello scrivere informazioni sul database, come un dato proveniente da un campo si una form, leggere un dato proveniente dal database, come estrarre le informazioni relative l'account dell'utente.

Proprio come il livello di presentazione è costituito da vari componenti , come gli stili, JavaScript, il markup, e cosi via, il livello applicazione può essere costituito da una varietà di diversi componenti come i sistemi necessari per leggere e scrivere dati al database, informazioni igienizzanti , la convalida delle informazioni, e far rispettare alcune regole che sono uniche per il problema in questione.

Alla fine , il livello Database è dove le informazioni vengono immagazzinate. Questo può consistere un un file system, un database MySql oppure potrebbe essere una soluzione di una terza parte come una datastore sul "cloud" come Amazon S3 o qualcosa di simile.

Sono tutti Astratti

il nodo principale di questo, sta nel fatto che nel software, abbiamo sempre a che fare con un certo livello di astrazione. Per esempio, parliamo di immagazzinamento dei dati o di livello database, ma non siamo realmente specifici Lo stesso vale con il livello Applicazione ed il Presentation Layer.

  • Stiamo parlando di database relazionali con tabelle multiple o parliamo di storage in cloud?
  • Che tipo di livello di accesso ai dati stiamo collegando all'appllication layer per parlare con il database?
  • Qual'è il framework ed il linguaggio che utilizzeremo nel front-end? Vanilla JavaScript, jQuery, Knockout.js? Cosa in merito ai preprocessori CSS - saranno LESS o Sass?

Ovviamente, non cercheremo di dare una risposta a queste domande adesso, ma il punto è questo, tutte le applicazioni web hanno componenti simili, ma nel dettaglio questi variano da progetto a progetto.


Le componenti di WordPress

E' lui stesso un'applicazione web , WordPress è un esempio perfetto di come diverse tecnologie si uniscono per dare forma ad un'applicazione web.

  1. Il livello Database è un database MySQL;
  2. il Livello Applicazione, che qualcuno potrebbe già considerare di per se WordPress, è scritto in PHP e gestisce molte delle operazioni di base di lettura e scrittura sull'archivio dati, traendo gli sviluppatori un grande vantaggio dalle sue  API.
  3. Il Livello di presentazione utilizza di base il CSS (ancora per il momento), HTML (in molti temi al momento utilizzano HTML5), jQuery, e per parti della dashboard utilizza Backbone.js

Dunque, questa è l'architettura di WordPress, ma in merito al progetto che vogliamo costruire sull'applicazione? Come facciamo seguire la stessa architettura ?

Bene, ricordate che WordPress è una base, non un framework, quindi è soggetto per default all'architettura di WordPress. Ciò non significa che non si possano utilizzare delle nostre librerie, ma questo influenza il modo in cui la nostra applicazione ed il progetto vengono costruiti.

Parleremo delle librerie , della estensibilità e molto altro fra un attimo, ma prima è importante notare che in un  momento dove il paradigma MVC (e MVVM e altre varianti del Model, View, a prescindere) è di gran moda, WordPress non segue questa convenzione.

Ci sono tesi a favore e contro perchè potrebbe essere una cosa positiva o negativa, ma questo non rientra nello scopo di questo articolo. Invece, semplicemente vale la pena notare che WordPress utilizza il pattern event-driven , piuttosto che il pannello model-view-control.

E a tal fine, vale la pena capire come funziona il modello event-driven in modo da avere una chiara comprensione di come lavorano gli hooks di WordPress, e come si possa cambiare il modo di pensare e passare da MVC o qualsiasi altro paradigma siete abituati ad usare, a come WordPress gestisce le sue informazioni.


Cosa significa essere Event-Driven?

Prima di dare un'occhiata ad un esempio di applicazione event-driven, ricordiamo cosa significa seguire il paradigma MVC.

  • Innanzitutto, la vista serve da presentazione. Gli utenti vedono le informazioni ed interagiscono con l'interfaccia utente.
  • Successivamente, I controllers coordinano le informazioni verso e dal modello e la vista. Rispondono alle azioni dell'utente, e recuperano le informazioni dal modello attraverso la vista.
  • Dopo di chè , il modello rappresenta i dati nel database Questo può essere fatto innumerevoli volte, ma uno dei modi più comumi è mappare i dati nel database attraverso un modello di oggetto relazionale cosicchè il dato viene rappresentato in formato di oggetto.

L'intero modello MVC è simile a questo :

MVC
MVC

Adesso, una applicazione event-driven può avere molti degli stessi componenti, questo è quanto, possono esserci viste e modelli o viste e data objects , ma non necessariamente hanno un controller che coordina le informazione tra il front end ed il backend.

Invece, la programmazione event-driven funziona fuori della premessa che "qualcosa è accaduta." Da qui il nome per le azioni , nel gergo di WordPress (naturalmente, abbiamo anche filtri, ma mi occuperò di questi mementaneamente).

WordPress offre ganci (hooks) che sono letteralmente punti di esecuzione in cui possiamo inserire la nostra  funzionalità in modo che WordPress riconosca che "quando questo evento si verifica, ho bisogno di eseguire queste funzioni" dove queste funzioni sono definite come ciò che abbiamo fornito.

La verità è , i filtri lavorano allo stesso modo , il loro scopo è differente. In breve, i filtri sono azioni che sono pensati per la manipolazione di dati (ad esempio aggiungendo, anteponendo, rimozione o l'aggiornando il contenuto), in qualche modo, prima di tornare di nuovo alla esecuzione dell'applicazione.

Cosi a cosa assomiglia questo?

Events
Eventi

Niente di terribilmente complicato giusto?


Quindi qual'è la nostra nuova architettura?

Il punto di questo articolo è principalmente, metterci nella codizione di pensare in termini di programmazione event-driven e come coordinare in nostri sforzi nella costruzione di una web application specificamente su WordPress.

Vale a dire, questo è l'importante, pensare in termini di eventi o di fatto che "qualcosa è accaduto" in modo da sapere quando inserire le nostre azioni appropriatamente. Parleremo di questo poco più in dettaglio nel prossimo articolo, ma la cosa importante che vorrei vi rimanesse con questo particolare articolo è che solo perchè qualcosa non è MVC (o qualsiasi altro, prossimo, noto paradigma) non significa che non sia adatto per lo sviluppo di un'applicazione.

Ogni modello e l'architettura ci offre vantaggi e svantaggi ognuno dei quali può contribuire al successo della costruzione di una applicazione web.


Nel prossimo articolo ...

Nel prossimo articolo della serie, daremo uno sguardo più dettagliato a come ganci (hooks)  svolgono un ruolo fondamentale nella creazione di applicazioni web su WordPress, e poi inizieremo a guardare alcune delle strutture che WordPress offre a scatola chiusa che lo rendono una solida opzione così per alcune tipologie (leggi: non tutti i tipi) 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.