Il giorno 30/ago/07, alle ore 16:18, Daniele Varrazzo ha scritto:
On Thu, 30 Aug 2007 15:41:15 +0200, Y3s <[EMAIL PROTECTED]> wrote:
Il giorno 30/ago/07, alle ore 15:17, Daniele Varrazzo ha scritto:
On Thu, 30 Aug 2007 13:32:09 +0200, Y3s <[EMAIL PROTECTED]> 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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
