Web2py - Core

Opzioni della riga di comando

Abbiamo imparato come avviare il server web2py utilizzando il widget GUI nel capitolo precedente.

Questo widget può essere ignorato avviando il server da command line richiesta.

python web2py.py -a 'la tua password' -i 127.0.0.1 -p 8000

Ogni volta che il server web2py si avvia, crea un file "parameters_8000.py"dove tutte le password sono archiviate in un formato hash.

Per motivi di sicurezza aggiuntivi, è possibile utilizzare la seguente riga di comando:

python web2py.py -a '<recycle>' -i 127.0.0.1 -p 8000

Per lo scenario precedente, web2py riutilizza le password con hash memorizzate in "parameters_8000.py".

Nel caso, se il file "parameters_8000.py"viene cancellato accidentalmente o per altri motivi, l'interfaccia amministrativa basata sul web è disabilitata in web2py.

Mappatura / invio URL

Il funzionamento di web2py si basa su model-view-controller, che mappa l'URL in una forma specifica - http://127.0.0.1:8000/a/d/f.html

Instrada fino alla funzione “f()” menzionato nel responsabile del trattamento d.pyè sotto l'applicazione denominata "a". Se il controller non è presente nell'applicazione, web2py utilizza un controller predefinito denominato“default.py”.

Se la funzione, come indicato nell'URL, non è presente, la funzione predefinita chiamata init()si usa. Il funzionamento dell'URL è mostrato schematicamente nell'immagine sottostante.

L'estensione .htmlè facoltativo per l'URL. L'estensione determina l'estensione diViewche restituisce l'output della funzione definita nel controller. Lo stesso contenuto viene offerto in più formati, ovvero html, xml, json, rss ecc.

La richiesta viene passata, in base alle funzioni, che accettano gli argomenti e forniscono l'output appropriato all'utente. È il controller, che interagisce con il modello e la vista dell'applicazione per fornire l'output secondo le necessità dell'utente.

web2py - Flusso di lavoro

Il flusso di lavoro di web2py è discusso di seguito:

• Il server web gestisce ogni richiesta HTTP simultaneamente nel proprio thread.

• L'intestazione della richiesta HTTP viene analizzata e passata al dispatcher.

• Il Dispatcher gestisce le richieste dell'applicazione e mappa il file PATH_INFOnell'URL della chiamata di funzione. Ogni chiamata di funzione è rappresentata nell'URL.

• Tutte le richieste di file inclusi nella cartella statica vengono gestite direttamente e file di grandi dimensioni vengono inviati al client.

• Le richieste per qualsiasi cosa tranne un file statico vengono mappate in un'azione.

• Se l'intestazione della richiesta contiene un cookie di sessione per l'app, l'oggetto sessione viene recuperato; oppure viene creato un ID di sessione.

• Se l'azione restituisce un valore come stringa, questo viene restituito al client.

• Se l'azione restituisce un iterabile, viene utilizzata per eseguire il ciclo e lo streaming dei dati al client.

Modelli condizionali

Nel capitolo precedente abbiamo visto la funzionalità di Controllers. web2py utilizza modelli, visualizzazioni e controller in ciascuna delle sue applicazioni. Pertanto, è anche necessario comprendere la funzionalità diModel.

A differenza di qualsiasi altra applicazione MVC, i modelli in web2py sono trattati come condizionali. I modelli nelle sottocartelle vengono eseguiti, in base all'utilizzo del relativo controller. Questo può essere dimostrato con il seguente esempio:

Considera l'URL - http://127.0.0.1:8000/a/d/f.html

In questo caso, ‘a’ è il nome dell'applicazione, ‘d’ è il nome del controller e f()è la funzione associata al controller. L'elenco dei modelli che verranno eseguiti è il seguente:

applications/a/models/*.py
applications/a/models/d/*.py
applications/a/models/d/f/*.py

Biblioteche

web2py include librerie, che sono esposte a tutte le applicazioni come oggetti. Questi oggetti sono definiti all'interno dei file core nella directory denominata "gluon".

Molti dei moduli come il modello DAL non hanno dipendenze e possono essere implementati al di fuori del framework di web2py. Mantiene anche gli unit test che sono considerati buone pratiche.

Applicazioni

Le applicazioni web2py sono mostrate di seguito in forma schematica.

Il Applications sviluppati in web2py sono composti dalle seguenti parti:

• Models - Rappresenta dati e tabelle di database.

• Controllers - Descrive la logica e il flusso di lavoro dell'applicazione.

• Views - Aiuta a rendere la visualizzazione dei dati.

• Languages - descrivere come tradurre le stringhe nell'applicazione in varie lingue supportate.

• Static files - Non richiede elaborazione (ad esempio immagini, fogli di stile CSS ecc.).

• ABOUT e README - Dettagli del progetto.

• Errors - Memorizza i rapporti di errore generati dall'applicazione.

• Sessions - Memorizza le informazioni relative a ogni particolare utente.

• Databases - memorizzare database SQLite e informazioni aggiuntive sulla tabella.

• Cache - Memorizza gli elementi dell'applicazione memorizzati nella cache.

• Modules - I moduli sono altri moduli Python opzionali.

• Private - I file inclusi sono accessibili dai controller ma non direttamente dallo sviluppatore.

• Uploads - I file sono accessibili dai modelli ma non direttamente dallo sviluppatore.

API

In web2py, models, controllers e views vengono eseguiti in un ambiente in cui determinati oggetti vengono importati per gli sviluppatori.

Global Objects - richiesta, risposta, sessione, cache.

Helpers- web2py include una classe helper, che può essere utilizzata per creare HTML programmaticamente. Corrisponde ai tag HTML, definiti come“HTML helpers”.

Ad esempio, A, B, FIELDSET, FORM, ecc.

Sessione

Una sessione può essere definita come un'archiviazione di informazioni lato server, che viene mantenuta per tutta l'interazione dell'utente attraverso l'applicazione web.

La sessione in web2py è l'istanza della classe di archiviazione.

Ad esempio, una variabile può essere memorizzata nella sessione come

session.myvariable = "hello"

Questo valore può essere recuperato come

a = session.myvariable

Il valore della variabile può essere recuperato purché il codice venga eseguito nella stessa sessione dallo stesso utente.

Uno dei metodi importanti in web2py per la sessione è “forget” -

session.forget(response);

Indica a web2py di non salvare la sessione.

Esecuzione di attività in background

Una richiesta HTTP arriva al server web, che gestisce ogni richiesta nel proprio thread, in parallelo. L'attività, che è attiva, si svolge in primo piano mentre le altre vengono mantenute in background. La gestione delle attività in background è anche una delle caratteristiche principali di web2py.

Le attività che richiedono molto tempo sono preferibilmente mantenute in background. Alcuni dei meccanismi sono elencati di seguito, che gestiscono le attività in background:

• CRON

• Queues

• Scheduler

CRON

In web2py, CRONdà la possibilità di eseguire l'attività entro gli intervalli di tempo specificati. Ogni applicazione include un file CRON, che ne definisce le funzionalità.

Scheduler

Lo scheduler integrato aiuta nell'esecuzione delle attività in background impostando la priorità. Fornisce un meccanismo per creare, programmare e modificare le attività.

Gli eventi pianificati sono elencati nei modelli con il nome del file “scheduler.py”.

Creazione di un'applicazione

Abbiamo avuto una panoramica sulla creazione di modelli e controller in web2py. Qui ci concentreremo sulla creazione dell'applicazione denominata“Contacts”. L'applicazione deve mantenere un elenco di aziende e un elenco di persone che lavorano in tali aziende.

Creazione del modello

Qui, l'identificazione delle tabelle per il dizionario dei dati è il modello. Il modello per l'applicazione dei contatti verrà creato sotto il "models"Cartelle. Il file è archiviato inmodels/db_contacts.py.

# in file: models/db_custom.py
db.define_table('company', Field('name', notnull = True, unique = True), format = '%(name)s')
db.define_table(
   'contact',
   Field('name', notnull = True),
   Field('company', 'reference company'),
   Field('picture', 'upload'),
   Field('email', requires = IS_EMAIL()),
   Field('phone_number', requires = IS_MATCH('[\d\-\(\) ]+')),
   Field('address'),
   format = '%(name)s'
)

db.define_table(
   'log',
   Field('body', 'text', notnull = True),
   Field('posted_on', 'datetime'),
   Field('contact', 'reference contact')
)

Una volta creato il file sopra, è possibile accedere alle tabelle con l'aiuto di URL http://127.0.0.1:8000/contacts/appadmin

Creazione del controller

Il Controller includerà alcune funzioni per elencare, modificare ed eliminare i contatti.

# in file: controllers/default.py
def index():return locals()
def companies():companies = db(db.company).select(orderby = db.company.name)
return locals()

def contacts():company = db.company(request.args(0)) or redirect(URL('companies'))
contacts = db(db.contact.company == company.id).select(orderby = db.contact.name)
return locals()

@auth.requires_login()
def company_create():form = crud.create(db.company, next = 'companies')
return locals()

@auth.requires_login()
def company_edit():company = db.company(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.company, company, next='companies')
return locals()

@auth.requires_login()
def contact_create():db.contact.company.default = request.args(0)
form = crud.create(db.contact, next = 'companies')
return locals()

@auth.requires_login()
def contact_edit():contact = db.contact(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.contact, contact, next = 'companies')
return locals()

def user():return dict(form = auth())

La creazione del view insieme al suo output sarà discusso nel prossimo capitolo.