[Python] migrazione da msaccess a python

Gio 30 Ago 2007 16:36:57 CEST

Il giorno 30/ago/07, alle ore 16:18, Daniele Varrazzo ha scritto:

>
>
> On Thu, 30 Aug 2007 15:41:15 +0200, Y3s <y3s a katamail.com> wrote:
>>
>> Il giorno 30/ago/07, alle ore 15:17, Daniele Varrazzo ha scritto:
>>
>>>
>>>
>>> On Thu, 30 Aug 2007 13:32:09 +0200, Y3s <y3s a katamail.com> wrote:
>>>>
>>>> Il giorno 30/ago/07, alle ore 13:03, Marco ha scritto:
>>>>
>>>>> Ciao sto anche io facendo un lavoro del genere per la mia azienda
>>>>> ma non è affatto facile.
>>>>> Per quanto access sia una schifezza, come dicono tanti,  permette
>>>>> personalizzazioni molto veloci a livello di query o report.
>>>>> Python al contrario ti permetterà sicuramente una maggiore  e una
>>>>> migliore gestione a livello di linguaggio e di sicurezza dei dati,
>>>>> indipendentemente se ti basi su mysql o altri.
>>>>> Se però ti chiedono una qry al volo o un report  non ci metterei
>>>>> senz'altro i 10 min che ci mettevi prima a crearlo dal  nulla.
>>>>
>>>> Non sono per niente d'accordo, anzi in python (avendo strutturato
>>>> bene il tutto) è ancora più semplice. Apri il file (file di testo,
>>>> che puoi aprire in situazioni di emergenza con notepad), scrivi la
>>>> query, la associ al pulsante, menu o quello che è ed è fatto. Per i
>>>> report, al momento in effetti strumenti comodi non ce ne sono ma
>>>> idem, se hai creato un'infrastruttura ben fatta (ad esempio dei
>>>> template per reportlab), non ci vorranno 10 minuti, ma in 15 hai
>>>> fatto...ed è un lavoro molto più pulito e stabile direi!
>>>
>>> Tu come li fai i template in reportlab?
>>>
>>
>> Per "template" intendevo un "modello". In genere le tipologie di
>> report che si usano in un'applicazione sono poche. Una volta che hai
>> coperto in modo per te soddisfacente i casi che ti interessano, è
>> rapido e veloce modificare la classe, la funzione, o qualunque cosa
>> usi per generare l'output per adattarla al nuovo report.
>
> Ok, quindi devi comunque scrivere codice per avere un template. Questo
> rende i template non disponibili a chi non sa programmare.

Si. Però dal mio punto di vista questo non è un reale problema visto  
che nella mia (limitata, d'accordo, ma condivisa da diversi colleghi)  
esperienza, ci si rivolge *sempre e comunque* allo sviluppatore, in  
ogni caso, anche se l'utente finale (o l'eventuale concessionario) ha  
gli strumenti per personalizzarsi qualcosa. Sarà che il livello di  
informatizzazione qui al sud è molto basso, mentre quello di  
scansafaticaggine/paraculaggine è MOOOOLTO alto, ma *tutti* quelli  
che conosco che fanno questo mestiere hanno esperienze analoghe.  
Comunque oggettivamente questo è un problema, ok.

>
>>> Io ho avuto successo solo usando una versione patchottata di un
>>> parser RML
>>> "bootleg" che trovai abbandonato da qualche parte nel web (per avere
>>> RML2PDF devi comprare il "ReportLab Enterprise Publishing and
>>> Reporting
>>> Server"... e il nome dice tutto su quanto te lo vogliono far
>>> pagare), e
>>> anche allora quello che ho avuto è stato un linguaggio per fare *i
>>> report*, non *i template*: questi ultimi me li sono fatti con
>>> Cheetah che
>>> genera RML che genera PDF - un altro strato di roba da imparare.
>>> Alla fine
>>> va, ma è veramente un hack che non me la sentirei di consigliare a
>>> cuor
>>> leggero.
>>>
>>> Hai una soluzione più pulita di questa? Sarei felice di  
>>> conoscerla. Se
>>> no... direi che promettere a qualcuno che farà report "non in 10
>>> minuti ma
>>> in 15 sì" mi sembra un po' grossa.
>>>
>>
>> Al momento no, ma ci sto lavorando. Purtroppo il tempo è sempre poco.
>> C'è openreport (o comunuque si chiami, non ricordo, comunque quello
>> che usa tinyERP) che più o meno dovrebbe fare quello che fai tu, ma
>> in modo un po'più integrato.
>
> E' *quello* il bootleg di rml2pdf che ho usato :) ed è quello che ho
> dovuto integrare con un sistema di templating mio. Per la cronaca, la
> homepage è andata, il progetto ritirato da freshmeat e se ne possono
> trovare le macerie solo nella cache di google.
>

Intendi questa?
http://www.openreport.org/

>> Comunque, si parlava di "query al volo o report", quindi davo per
>> scontato che il grosso del lavoro sia già stato fatto. In tal caso,
>> non ci vuole molto ad adattare un report che già hai per creare
>> qualcosa di nuovo che, ripeto, nel 90% dei casi sarà molto simile
>> come struttura a uno che già hai. Inoltre, ho specificato che *avendo
>> strutturato bene l'applicazione* e *avendo creato un'infrastruttura
>> adeguata* la modifica al volo è un'operazione semplice e rapida,
>> certo partendo da zero il tempo necessario è maggiore...almeno
>> all'inizio, visto che molto del codice che vai a scrivere la prima
>> volta, lo riutilizzerai quasi sicuramente le volte successive...
>
> Hai detto che mettendoci N mesi di lavoro, un template di scrive in 15
> minuti. Con queste premesse sì, e aggiungo anche *avendo creato _bene_
> l'infrastruttura*, ovvero avendo usato delle capacità di progettista e
> sviuppatore al di sopra di quello che serve per progettare (zero) e
> implementare (poco) un singolo template. Anche io posso andare  
> sulla luna
> in 3 giorni, *avendomi la NASA costruito un missile adeguato in 10  
> anni*.

Il paragone non calza molto, visto che programmare è un'attività che  
non dovrebbe essere improvvisata. Allo stesso modo in cui io non mi  
improvviso ingegnere aerospaziale.
Sai meglio di me che per avere un prodotto decente e funzionante, il  
tempo di lavoro ci vuole, e un minimo di progettazione idem. Se stai  
ragionando dal punto di vista dell'utente finale, allora hai  
perfettamente ragione, meglio continuare ad usare access (che, visto  
come tool per l'utente finale e non per lo sviluppatore non è poi  
così male, intendiamoci!). Se invece stiamo parlando di uno  
sviluppatore che vuole creare personalizzazioni in modo rapido per un  
cliente di un software completo, allora continuo a pensarla in quel  
modo!

>>> Access è ottimale per una certa classe di applicazioni: se (e solo
>>> se) si
>>> è ossequiosi verso il suo paradigma, consente di fare applicativi -
>>> male -
>>> ma velocemente. In Python le cose si possono fare bene, si è liberi
>>> sul
>>> paradigma di accesso ai dati, si possono fare anche certe cose
>>> velocemente... ma non le stesse che si fanno con Access altrettanto
>>> velocemente.
>>>
>>
>> Se l'obiettivo è avere un'applicazione che funziona in poco tempo, se
>> non si è interessati alla qualità del codice, se non ci si preoccupa
>> troppo della manutenzione e dell'espandibilità, se si vuole correre
>> il rischio che con la nuova versione dell'applicativo il tuo
>> programma non funzioni più, allora si, Access è un ottimo strumento.
>> Troppi se per i miei gusti, ma...
>> Io continuo a pensare che una volta che ti sei costruito un insieme
>> di moduli adatti alle tue esigenze, sviluppare in python non è molto
>> più lento che farlo con access o altro. Il grosso del tempo lo perdi
>> solo una volta. Ovviamente è una mia opinione, eh!
>
> Ovviamente ci sono molti "se" anche per me, per questo non tocco  
> Access
> neanche con un bastone (dopo averci sviluppato per un paio di anni  
> e quindi
> conoscendolo piuttosto bene). Però se ci sono persone che ritengono di
> aver bisogno solo di quelle (ovviamente per una soluzione ad hoc  
> per un
> problema personale, non per creare un package da ridistribuire),  
> non lo si
> batte solo a parole.
>

Se stiamo parlando di un software di produttività personale, alla  
stregua degli altri componenti del pacchetto office, allora sono  
d'accordo. Ma purtroppo access è spesso concepito come uno strumento  
*di sviluppo*, e a questo punto un VERO ambiente di sviluppo non si  
batte. IMHO.

--
Antonio Valente