wiki:UI

Version 7 (modified by fero, 3 years ago) (diff)

Implementazione nuovo blocco

La logica dell'interfaccia web è presa da SANET  http://sanet.sourceforge.net by Laboratori Guglielmo Marconi.

L'interfaccia si basa su una struttura a schede e a blocchi. È versatile e personalizzabile per utente.

La struttura di default è definita nel parametro settings.RESOURCE_PAGE_BLOCKS

Visione generale

Dall'URL alla vista

Passi principali:

  • si accede ad un URL che è _sempre_ riferito ad una risorsa. Le risorse principali le trovate nel dizionario types_model_d in des/models.py
  • la risorsa si identifica facilmente dato che nell'url sono sempre presenti i parametri <resource_type> e <resource_id>
  • interviene il Middleware (file middleware.py)  https://docs.djangoproject.com/en/dev/topics/http/middleware/ che SETTA un attributo request.resource all'istanza cui la pagina si riferisce. L'oggetto request è quello che arriva alle viste  https://docs.djangoproject.com/en/1.3/topics/http/views/ (v. parametro request)
  • Poi viene chiamata la vista opportuna a seconda degli url specificati praticamente in urls.py , rest/urls.py, rest/views/urls.py

Come si crea la pagina

  • Di base prima si scarica tutto l'html
  • Poi viene richiesta via AJAX la configurazione (default_settings.RESOURCE_PAGE_BLOCKS)
  • Poi vengono prodotte le varie sezioni ed eventuali blocchi
  • Ogni blocco richiama il proprio contenuto e dispone di una parte python (vista), una rappresentazione xml (template) e una parte javascript (logica client). La parte javascript ancora non l'ho vista ma per la parte python c'è una API rappresentata dalla classe AbstractBlock che è in rest/views/blocks/__init__.py
  • Bisognerebbe creare una API per BlockWithList un blocco che include una lista di elementi. Intanto vi ho lasciato per esercizio di provare ad implementare i blocchi gas_list e supplier_list

NOTA: nella API dei blocchi secondo me tutte le funzioni che si basano su resource_type e resource_id dovrebbero essere sostituite dal parametro resource

NOTA2: per ora la classe URN in lib/urns.py non è da usare che aggiunge confusione. Vedremo poi se reintegrarla

Specifiche

Struttura dell'URL

È fondamentale definire un pattern coerente per la struttura dell'URL.

Ogni pagina e ogni parte di pagina è riferita ad una risorsa. Tenere presente che, qualora necessario, si potrebbero creare anche risorse fittizie per soddisfare questo requisito. Pertanto, se ogni pagina è riferita ad una risorsa, sembra coerente che ogni URL sia formato a partire da <tipo di risorsa>/<id della risorsa>. Tuttavia un progetto Django è composto di varie applicazioni e sembra corretto che ogni applicazione abbia il suo namespace per definire il proprio URL pattern.

In conclusione un buon pattern per l'URL sembrerebbe essere /<nome applicazione>/<tipo di risorsa>/<id della risorsa>/<bind della vista>

Il tutto ovviamente è preceduto da quanto configurato in settings.URL_PREFIX

Parametri delle viste

Le viste prendono come parametro l'oggetto request e quasi sempre resource_type e resource_id. Evitare di usare questi ultimi 2 parametri, ma preferire derivare gli attributi da request.resource quando necessario.

Implementare un nuovo blocco

Come facciamo ad implementare un blocco che ipotizziamo si chiami gas_list?

  1. Implementare il blocco rest/views/blocks/gas_list.py
    • ridefinire i dettagli in __init__
    • impostare il tipo di risorse per cui il blocco è valido in is_valid()
    • reimplementare get_response restituendo eventualmente un template apposito. Nel nostro caso implemento il generico blocks/resource_list.xml da usare anche per la visualizzazione di altre liste di risorse
  2. Implementare il template blocks/resource_list.xml
  3. Implementare la logica lato client /static/nui/blocks/gas_list.js

Abbiamo aggiunto un blocco che visualizza la lista dei GAS afferenti ad una risorsa.

NOTA: affinché funzioni tutti modelli per cui è possibile visualizzare questo blocco devono implementare la property gas_list NOTA: rifarò io le fixture dei GAS collegati al DES. Comunque dovrebbe funzionare l'importanzione ho messo un controllo nella save()

TODO: spostare in un generico resource_list.js

TODO: integrare le azioni e i form

Utenti

Permessi

A tutti è concessa la lettura, mentre la scrittura è limitata. È quindi abbastanza semplice verificare i permessi: tutte le informazioni appariranno comunque nelle pagine, mentre le azioni di scrittura non saranno permesse e neanche visibili. Questo è realizzabile perché l'azione di scrittura viene visualizzata come conseguenza della visualizzazione della risorsa da scrivere.

Agganciare il modello DES al Site framework di Django significa poter gestire in futuro un'installazione multi-DES. E quindi applicare la policy dei permessi anche all'oggetto DES che non è globale.

Le ricerche possono essere effettuate a 2 livelli: DES, locale alla pagina di riferimento. E in prospettiva anche a livello multi-DES se presenti più di un DES.

NOTA: agganciati GAS e Supplier al DES

Profilazione

La profilazione in SANET è stata aggiunta dopo ed è stata incastrata alla meglio. Mi piacerebbe che in GASISTA FELICE fosse un elemento fondante proprio per sviluppare al meglio la soggettività evidenziata nell'analisi.

Innanzi tutto è necessario predisporre non un'unica interfaccia grafica di default, ma un'interfaccia custom per ruolo: come già accennato su BozzaGrafica.

Poi mantenere la possibilità (adattando quanto già previsto in SANET) di definire una propria interfaccia sulla base delle esigenze dell'utente specifico.