Newsgroup: it.comp.software.database
Titolo: Sviluppo applicazioni...

Salve a tutti,
qualcuno può consigliarmi l'approccio "migliore" per sviluppare rapidamente
applicazioni che si interfaccino a database già esistenti e permettano di
visualizzarne e modificarne i dati?
Gradirei anche qualche link per maggiori info.
Grazie,
Sergio B.

Sergio B. wrote:

perl/tk e dbi.
cross platform, open source, facile, completo, maturo, fiko, veloce.
http://www.dbpd.com/vault/9810/edb.html
http://dbi.perl.org/doc/index.html

Grazie mille, anche per la celerità!
Ho una piccola esperienza in Perl (sebbene non ci lavori da un po' di
tempo), ma non l'ho mai usato in questo campo! Inoltre non conosco il
package Tk, so solo che serve per le interfacce grafiche...giusto?
Pensi che il tempo necessario ad acquisire tali conoscenze e sviluppare
un'applicazione di media difficoltà sia minore del tempo che ci vorrebbe a
sviluppare tale applicazione in Java (col quale ho più esperienza)?
Grazie ancora,
A presto!
Sergio B.

 sviluppare tale applicazione in Java (col quale ho più esperienza)?
penso che java e perl siano piu o meno sullo stesso piano. entrambi sono 
linguaggi cross platform, entrambi sono usati sia per il web che per 
programmi con gui, entrambi sono (o possono essere) orientati agli oggetti.
java è a oggetti puro, perl lo è, ma se vuoi usi procedure e funzioni 
(puoi mischiare entrambe le cose).
io (per lavoro) mi sono guardato java per creare un frontend (finestre 
master-detail, liste con filtri avanzati e via dicendo), e ho trovato 
alcune classi che permettevano di gestire la cosa (jdbtable della 
borland e altri). mi sono trovato molto male, nel senso che le classi 
che ho trovato funzionano, ma sono molto limitate e devi estenderle e 
scriverti un sacco di codice per farle funzionare veramente. per un rad 
non è il massimo, e ci perdi molto tempo. se conosci già java, 
probabilmente non avrai voglia di guardarti perl, ma magari ti metti a 
ereditare e a migliorare le classi java che trovi.
in perl ho trovato il modulo dbi, che è l'equivalente delle jdbc di 
java. con perl mi sono trovato meglio che con java per la gui, perchè ho 
trovato subito molto efficienti DBI::Table (per visualizzare liste di 
valori presenti sul database e per monitorare tabelle) e TableMatrix per 
creare finestre molto complesse (in pratica puoi fare una specie di 
excel con poche righe di codice).
inoltre perl è famoso per le sua capacità di parser, cosa che per un 
frontend è (secondo me) essenziale. tiri su i dati dal db, due regexp e 
crei un report in html che fa paura.
mi sono dilungato anche troppo. se vuoic he continuo dimmelo, ma secondo 
me fai prima a cercare qualcosa su DBI::Table su google e a provare 
qualche esempio con tablematrix.

Non ti sei dilungato affatto, inoltre mi fa sempre piacere intrattenere
discussioni del genere :-)
Conosco Java SE abbastanza bene e purtroppo ne riconosco i "limiti" in tale
campo: non ho usato classi esterne poichè non voglio report particolari
(sebbene sia tentato dal provare la libreria JFreeReport) ma piuttosto la
classe Swing JTable ed il problema non è tanto la visualizzazione della
tabella ma la modifica o il semplice utilizzo dei dati così forniti; lì sì
che bisogna scrivere un bel po' di codice, cosa che non mi dispiace, di
regola, ma in questo periodo ho molto da fare...
Il Perl, dunque, mi aiuterà a velocizzare?
Provo a fare qualche ricerca sul web e magari ti faccio sapere.
Grazie molte per l'aiuto,
a presto, spero,
Sergio B.

 : 

http://www.python.org
http://pythoncard.sourceforge.net
http://boa-constructor.sourceforge.net
All'interno di Python c'è l'interfaccia a Tk, ma oltre al fatto che le
Tk sono poco reattive e bruttarelle, hai detto velocemente :)
In python ogni DB ha un modulo conforme a una specifica, quindi devi
cercare il modulo per il tuo DB.
	nicholas

 ha scritto nel messaggio
news:pSlab.81092$hE5.2...@news1.tin.it...


 java č a oggetti puro, perl lo č
Java e Perl nemmeno si avvicinano ad essere a oggetti puri: python e' molto piů
vicino, ma non sono sicuro sia a oggetti puri (sono quasi certo del contrario a
dire il vero).
L'unico linguaggio OO puro che conosco e' Ruby.
Quello che (credo...) intendi dire e' che Java e' object based, mentre
Perl no, il che e' abbastanza ininfluente ai fini dello sviluppo rapido.
	nicholas

 Tk sono poco reattive e bruttarelle
http://www.cs.man.ac.uk/~fellowsd/tcl/option-tutorial.html
http://www.satisoft.com/tcltk/icons/libraries.html
http://tcl.projectforum.com/tk/9

 Perl no, il che e' abbastanza ininfluente ai fini dello sviluppo rapido.
se parliamo di sviluppo rapido (rad) allora l'oo non è certo quello che 
cerchiamo. niente eventi, ide impossibilitata dal gestire correttamente 
gerarchie di classi gui, componenti pesanti e difficili da gestire per 
chi si approccia per la prima volta, (e la lista continua...)

 : 

Ok, puoi cambiare le icone e cosi' via (naturalmente), ma non sono
i widget nativi.
Con wxPython usi Gtk sotto Unix, Win32 sotto Windows, e credo
recentemente sia stato portato il tutto su Mac.
Fai le interfacce che vuoi mantenendo il look and feel del desktop che
usi, senza contare che non hanno bisogno di 'aggiunte' per avere widget
ad alto livello.
Poi ognuno usa quel che vuole.
	nicholas

 L'unico linguaggio OO puro che conosco e' Ruby.
Aggiungerei Smalltalk.
Martino.

 chi si approccia per la prima volta, (e la lista continua...)
Se parliamo di sviluppo rapido l'OO e' pressoche' fondamentale: se poi
parliamo di toolkit grafici non sono a conoscenza di GUI non OO, Qt,
Win32, wx, Gtk+, COCOA e Fox sicuramente lo sono, quelle che uso io
(Gtk+ e Wx) sono sicuramente event driven, e i componenti sono
indubbiamente piu' difficili da gestire in un linguaggio procedurale
(quando e' possibile: il concetto stesso di GUI si presta poco al
paradigma, per questo Qt e Wx non sono utilizzabili da C, per esempio).
Quello che dici sulle IDE francamente non l'ho capito: Visual Basic e'
object based, Delphi/Kylix sono Object Pascal... piu' di cosě...
	nicholas

 object based, Delphi/Kylix sono Object Pascal... piu' di così...
dicevi oo "puro" no? quindi gli eventi non ci sono. un clicked su un 
pulsante non esiste. devi implementare un listener e interfacciarti con 
quello. molto piu complicato di un vb, dove piazzi un pulsante su una 
form e inizi a scrivere codice nel clicked (ma questo lo sai sicuramente 
anche tu, è inutile che lo riscrivo :). quindi un oo "puro" non è 
l'ideale. molto meglio un oo "sporco", dove hai eventi, procedure, 
funzioni e tutto il resto, no?
inoltre per un tool di sviluppo è impossibile gestire gerarchie di 
classi grafiche: se hai ad esempio una classe_panel_1 con un pulsante, 
la erediti, crei una classe_panel_2, e ci aggiungi una textbox, la ide 
farà molta fatica a rendersi conto di quello che hai creato e come 
gestirlo. generare codice java per l'ide è quindi molto complesso, e 
infatti spesso sbaglia. questo problema ovviamente non cel'hai se usi 
notepad per programmare, ma a quel punto perdi tutte le funzionalità che 
ti da un'ide e perdi produttività e tempo.
penso che stiamo dicendo la stessa cosa, ma non ci capiamo.

 ti da un'ide e perdi produttività e tempo.
Che c'entra con il paradigma ? La creazione visuale in se presenta delle
forzature, ma se usi un tool RAD significa che sei disposto ad
accettarle: se provi Glade, che genera sostanzialmente C, vedi le
schifezze ... il punto e' che a te e' trasparente, quindi puoi
preoccuparti solamente della logica, e addirittura un tool puo'
permettersi di dirti dove andare a ficcare il tuo codice (UGH !).
Sono scelte, ad esempio io non uso RAD perche' non mi piace il codice
che generano per Python (che e' multiparadigma), come non mi e' mai
piaciuto VB, e non ho mai avuto lo stimolo per provare Kylix ^^
	nicholas

 ti da un'ide e perdi produttività e tempo.
Il codice generato dagli IDE è quasi sempre complesso e illeggibile.
Ma se scelgo una tale soluzione...ne accetto le conseguenze!
Comunque...la discussione è andata un po' OT :-)
Saluti,
Sergio B.

 In Java tutto è un oggetto
Nope, un intero e' un tipo primario, ad esempio.
	nicholas

 Nope, un intero e' un tipo primario, ad esempio.
Escludevo i tipi primitivi, ovviamente.
La loro esistenza, d'altronde, non inficia il carattere OO di Java.
Sergio B.

  In Java tutto è un oggetto
Mmm scusa ma ti devo contraddire, una delle cose che ho imparato
studiando Java a suo tempo e` che non e` vero che tutto e` un oggetto.
E` specificato nella Java Language Specification che i tipi di dato
int, float, char ecc ecc (quelli predefiniti insomma) non sono oggetti
infatti esistono un'infinita` di metodi (parseXX e compagnia bella)
per trasformare gli Integer in int e viceversa.
Altri linguaggi come C# (e come sara` Tiger, Java 1.5) implementano
un meccanismo di boxing e unboxing che permette di sopperire a questo problema.
Linguaggi come Ruby e Python invece possono essere considerati totalmente
ad oggetti perche` appunto qualsiasi cosa (anche la cifra 1 in Python e`
un oggetto) e` un oggetto. In Python e` possibile ottenere cose di questo
tipo:
In [1]: 1.
1.__abs__           1.__invert__        1.__repr__
1.__add__           1.__long__          1.__rfloordiv__
1.__and__           1.__lshift__        1.__rlshift__
1.__class__         1.__mod__           1.__rmod__
1.__cmp__           1.__mul__           1.__rmul__
1.__coerce__        1.__neg__           1.__ror__
1.__delattr__       1.__new__           1.__rpow__
1.__div__           1.__nonzero__       1.__rrshift__
1.__divmod__        1.__oct__           1.__rshift__
1.__doc__           1.__or__            1.__rsub__
1.__float__         1.__pos__           1.__rtruediv__
1.__floordiv__      1.__pow__           1.__rxor__
1.__getattribute__  1.__radd__          1.__setattr__
1.__getnewargs__    1.__rand__          1.__str__
1.__hash__          1.__rdiv__          1.__sub__
1.__hex__           1.__rdivmod__       1.__truediv__
1.__init__          1.__reduce__        1.__xor__
1.__int__           1.__reduce_ex__
- Questa che vedi sopra e` la lista di tutti i metodi dell'oggetto
 
In [1]: type(1)
Out[1]: <type 'int'>
- Il suo tipo
 
In [2]: type(type(1))
Out[2]: <type 'type'>
- Il tipo del suo tipo
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
rhy...@NOSPAMmyself.com

 int, float, char ecc ecc (quelli predefiniti insomma) non sono oggetti
Come già detto nel post appena precedente, l'esistenza dei tipi primitivi
non pregiudica il carattere OO di Java; non conosco Python, ma da quanto mi
hai scritto e da quanto ho letto in giro è come se ti dicessi che Python non
è OO poichè ti permette di scrivere codice dove ti capita prima (come accade
in Perl, ad esempio).
Per definire OO un linguaggio guarderei più alla mentalità e alla tecnica di
programmazione di tale linguaggio, più che alle sottigliezze o al modo
pratico in cui è reso il concetto di OO.
Non so se mi spiego.
Stiamo rasentando discussioni da puristi dell'OO ed esperti di linguaggi,
quale io non sono :-)
Saluti,
Sergio B.

 quale io non sono :-)
Siamo in due :)


 : 

Si parlava di OO puro, appunto.