Share
In questa serie, stiamo parlando di come possiamo costruire applicazioni web usando WordPress. E anche se questa non è una serie tecnica in cui vedremo il codice, noi siamo che copre argomenti come quadri, fondazioni, modelli di progettazione, architetture e così via.
Se non hai letto il primo post della serie, lo consiglio; tuttavia, ai fini di questo post, possiamo riassumere il post precedente come segue:
In breve, il software può essere costruito su framework, il software può estendere le basi.
In poche parole, abbiamo differenziato tra framework e fondazioni - due termini che sono spesso usati in modo intercambiabile nel software nonostante il fatto che non siano la stessa cosa. WordPress è un fondamento perché è un'applicazione a sé stante. Non è un quadro.
A tal fine, quando si tratta di creare applicazioni Web su WordPress, abbiamo bisogno di ripensare l'architettura o di ri-considerare i nostri modelli concettuali su come vengono costruite le applicazioni.
Al livello più alto possibile, le applicazioni web sono normalmente strutturate con le seguenti tre componenti:
In generale, il livello di presentazione è ciò che l'utente vede e ciò con cui l'utente interagisce. Include tutti gli stili, il codice lato client e il markup necessari per mettere qualcosa di fronte all'utente.
Quando l'utente fa clic su qualcosa, o la pagina esegue il rendering delle informazioni recuperate dal database, interagisce con il livello applicazione.
L'Application Layer è responsabile del coordinamento delle informazioni dal browser e / o dall'azione dell'utente nel database. A volte, ciò consiste nella scrittura di informazioni nel database, ad esempio informazioni da un campo modulo, alla lettura di informazioni dal database, come il recupero delle informazioni dell'account di un utente.
Molto simile al Presentation Layer è costituito da diversi componenti - come stili, JavaScript, markup e così via - l'Application Layer può consistere in una varietà di componenti diversi come i sistemi necessari per leggere e scrivere dati nel database, sanificare le informazioni , la convalida delle informazioni e l'applicazione di alcune regole uniche per il problema in questione.
Infine, il Database Layer è il luogo in cui vengono archiviati i dati. Questo può consistere nel file system, può consistere in un database MySQL o può consistere in una soluzione di terze parti come un archivio dati "nel cloud" come Amazon S3 o qualcosa del genere.
Il punto principale da cui partire è che nel software, abbiamo sempre a che fare con un certo livello di astrazione. Ad esempio, parliamo dell'archivio dati o del livello database, ma non siamo realmente specifici. Lo stesso vale per l'Application Layer e il Presentation Layer.
Ovviamente, non stiamo cercando di fornire risposte a queste domande in questo momento, ma il punto è che tutte le applicazioni web sono costituite da componenti simili, ma i dettagli di ogni componente variano da progetto a progetto.
Come un'applicazione Web, WordPress è un perfetto esempio di come varie tecnologie si uniscono per formare un'applicazione web:
Quindi questa è l'architettura di WordPress, ma per quanto riguarda i progetti che vogliamo costruire in cima all'applicazione? Come seguono la stessa architettura?
Bene, ricorda che WordPress è un fondamento - non un framework - quindi per impostazione predefinita siamo soggetti all'architettura di WordPress. Questo fa non significa che non possiamo portare nelle nostre librerie, in alcuni casi, ma influenza il modo in cui le nostre applicazioni e i nostri progetti sono costruiti.
Parleremo di più sulle librerie, l'estensibilità e altro in un po ', ma prima è importante notare che in un giorno in cui MVC (e MVVM e altre varianti del modello, Visualizza, Qualunque) paradigma sono tutti la rabbia, WordPress fa non seguire questa convenzione.
Ci sono argomenti a favore e contro perché questa potrebbe essere una cosa buona o cattiva, ma non è questo lo scopo di questo post. Invece, vale semplicemente la pena notare che WordPress utilizza un pattern basato sugli eventi, piuttosto che il pannello di controllo della vista del modello.
E a tal fine, vale la pena capire come funziona il modello basato sugli eventi in modo che tu abbia una chiara comprensione di come funzionano gli hook di WordPress e come puoi cambiare pensando a MVC oa qualunque altro paradigma sei abituato a usare, a come WordPress gestisce le sue informazioni.
Prima di dare un'occhiata a un esempio di un'applicazione guidata dagli eventi, rivisitiamo cosa significa seguire il paradigma MVC.
L'intero modello MVC si presenta così:
Ora, le applicazioni event-driven possono avere alcuni degli stessi componenti, ovvero possono avere viste e modelli o viste e oggetti dati, ma non necessariamente un controller che coordina le informazioni dal front-end al back-end.
Invece, la programmazione basata sugli eventi funziona partendo dal presupposto che "qualcosa come è successo". Da qui il nome per Azioni nel gergo WordPress (ovviamente, abbiamo anche dei filtri, ma li coprirò per un momento).
WordPress fornisce hook che sono letteralmente punti in esecuzione in cui possiamo introdurre le nostre funzionalità in modo tale che WordPress riconosca che "quando quest'evento succede, ho bisogno di sparare queste funzioni" dove queste funzioni sono definiti come qualsiasi cosa abbiamo fornito.
La verità è che i filtri funzionano allo stesso modo, ma il loro scopo è diverso. In breve, i filtri sono azioni pensate per manipolare i dati (come accodamento, prepending, rimozione o aggiornamento del contenuto) in qualche modo prima di tornare all'esecuzione dell'applicazione.
Che aspetto ha??
Niente di terribilmente complicato, giusto?
Il punto di questo articolo è principalmente quello di indurci a pensare in termini di programmazione guidata dagli eventi e come coordinare i nostri sforzi di creare applicazioni Web specificamente su WordPress.
Vale a dire che è importante per noi pensare in termini di eventi o il fatto che "qualcosa è successo" in modo da sapere quando inserire in modo appropriato le nostre azioni. Ne parleremo un po 'più in dettaglio nel prossimo articolo, ma il punto principale che voglio che voi ragazzi porterete via da questo particolare articolo è che solo qualcosa non è MVC (o qualunque sia il prossimo paradigma popolare è ) non significa che non è adatto allo sviluppo di applicazioni.
Ogni modello e architettura ci offre vantaggi e svantaggi che possono contribuire al successo della creazione di un'applicazione web.
Di seguito, analizzeremo in che modo gli hook svolgono un ruolo fondamentale nella creazione di applicazioni Web su WordPress, quindi inizieremo a esaminare alcune delle funzionalità offerte da WordPress. questo lo rende un'opzione così solida per alcuni tipi (leggi: no tutti tipi) di applicazioni Web.
Accentsconagua