Re: Documento LaTeX con estrazione dati da DB MySQL

#55879
robitex
Amministratore del forum
    Up
    0
    Down
    ::

    Indubbiamente. E’ il motivo per cui sin dall’inizio mi sono buttato su un DB MySQL per la gestione del Museo, non solo per una questione di visibilità sul web, ma soprattutto di carattere gestionale. Si presta uno strumento? Bene, un clic e la scheda d’uscita è stampata così come il cartellino “strumento assente” e il foglio con la lista del contenuto di un eventuale imballaggio…

    Sono alle prese con un profondo aggiornamento dei documenti poiché 3 mesi fa ho trasferito il Museo in una nuova ala della scuola, più ampia e luminosa; si sono aggiunte 2 vetrine, 40 strumenti in più (sfioro quota 300) e circa una 60-ina hanno cambiato vetrina rispetto a prima. Nel frattempo alcuni sono stati restaurati presso un centro specializzato, con novità di datazione e di costruttore, inoltre ho dovuto riorganizzare le voci riguardanti le caratterisitche di conservazione. Ebbene, tutto ciò è già aggiornato nel web, ma nei documenti word no.
    Di qui l’idea di inserire i database anche nei file di spiegazione sfruttando LaTex… Altrimenti il lavoro di aggionamento dei file è spaventosamente oneroso!

    Dopo esser diventato matto a rimettere Apache, PHP, MySQL sul nuovo computer con SO W7 64 bit (un delirio!!!), finalmente tutto funziona. La cartella /data con i DB è in un’altra partizione del disco (non si sa mai), ma il percorso mi è noto…

    Non ho alcun problema a scrivere quel che ti serve per avere un quadro informatico della situazione. Ho capia del DB sia sul mio PC che sul server di scuola. Ma posso tranquillamente lasciar perdere il colleegamento al server e lavorare sul mio PC. Al database accedo via SQL-Yog oltre che dalle pagine dinamiche phtml del sito, che chiaramentee ho tutto in copia sul PC…

    Ok.
    Per le mie conoscenze inizierei così:
    Filosofia: piccolo, semplice ma funzionante!
    0- eseguo esclusivamente operazioni di lettura dei dati;
    1- il sistema di creazione delle schede è indipendente dal resto e non si occupa di altro;
    2- LaTeX non si deve occupare di scaricare dati (niente LuaLaTeX), ma solo di comporli tipograficamente.

    Allora occorre:
    fase del linguaggio
    1- scelgo un linguaggio di scripting (sono i più semplici) per cui sono disponibili le librerie di accesso al db MySQL;

    fase del primo test
    2- scrivo un primo script che funziona da console che:
    2.0- installazione linguaggio e libreria, poi lo script dovrà:
    2.1- prende come argomento per esempio il numero identificativo di uno strumento,
    2.2- chiede all’utente username e password,
    2.3- si connette al db ed esegue la query,
    2.4- con i dati trovati costruisce il file sorgente LaTeX minimo,
    2.5- lo compila.

    fase LaTeX
    3.1- scrivo un documento LaTeX modello per ogni tipo di scheda
    3.2- eventualmente, realizzo delle classi di documento vere e proprie

    fase di messa in produzione
    4.1- perfeziono lo script per lavorare con i nuovi modelli in LaTeX
    4.2- implemento delle opzioni più flessibili, per esempio per generare TUTTE le schede in una volta, oppure quelle di un subset di strumenti

    fase evoluzione
    5- sostituzione dello script con un sistema ad interfaccia grafica

    Il pregio di questo procedimento è che ogni fase richiede un set minimo di conoscenze specifiche:
    * Panni dell’admin: conoscenze SQL di query semplici
    * Panni del programmatore: programmazione semplice con linguaggi di scripting
    * Panni del TeX user: conoscenza di base dei pacchetti utili per ottenere la composizione desiderata

    Inoltre ciascuno strumento (MySQL, linguaggio di scripting, LaTeX) viene usato per quello che è, mentre lo strumento di centro (il linguaggio di scripting) può successivamente cambiare per soluzioni più potenti, senza che sia necessario modificare gli altri due.

    Ma quale linguaggio di scripting usare per iniziare?
    Se penso alla fase 5 (con eventuale uso del framework Django http://www.djangoproject.com/ ) mi rivolgerei a Python.
    Se penso invece alla semplicità del codice penso senz’altro a Lua (anche Python è semplice ma Lua lo è di più).

    Da quel che so, queste due sono le due alternative (io inizierei con Lua anche a costo di reimplementare il codice in Python alla fase 5).

    Ora tutta un’altra questione:
    Siccome sto scrivendo un articolo per ArSTeXnica (la rivista del GuIT) esattamente su questi argomenti, ti invito se vuoi, a scrivermi via e-mail (che trovi sul mio blog) per collaborare come co-autore in base alla tua esperienza.
    La scadenza di consegna dell’articolo dovrebbe essere tra poco, per l’uscita sul numero di aprile, ma siccome ormai si profila inesorabile per i miei impegni lo slittamento ad ottobre (seconda uscita annuale e meeting quindi), il tempo disponibile aumenterà.
    Ciao

    Go to top