Il Sat, 23 Aug 2014 14:02:14 +0200, MaX ha scritto: > Del tipo... quante tabelle deve avere il db? > quali nomi gli diamo ad ogniuna? > quandi campi e caratteristiche avrá ogniuna?
Questo lo puoi fare com mysql-workbench, per esempio. Puoi anche creare lo schema UML del DB e definire le constraint e le foreign keys. > Quante intefacce (schermate) deve avere il programma? Questo lo fai con Glade o QtDesigner. Il secondo non lo conosco molto, ma in Glade puoi definire le callback per ogni area attiva, e ti genera un XML. Tramite libglade lo puoi usare da Python, C/C++, e probabilmente anche PHP e Ruby. > ad ogni schermata quali campi di quali tabelle mettiamo? Questo non ha molto senso. Molto raramente hai una corrispondenza 1:1 tra quello che devi mostrare a schermo e come lo salvi in DB. Qui è compito del programmatore definire i model che interfacciano appunto lo storage con le view. > a quel punto la tool crea tutto il codice per interfaccia a caratteri > tipo ncurses per intenderci, in un linguaggio da stabilire, aggiungendo > delle opzioni standard, tipo stampa, esportazione dati, menu, ecc. Il punto è che non esistono "opzioni standard". :) A meno che non fai una banale rubrica, un gestionale avrà la sua forza nel modo in cui salva e gestisce i dati. > Praticamente Unix è come un Lego... offre un sacco di mattonici da > abbinare a propria scelta. Usiamoli al posto delle stermiante librerie > che quasi tutti i linguaggi di programmazioni offrono, cosí non dobbiamo > reinventare la ruota ogni volta. Praticamente tutte le librerie dei linguaggi sotto Linux sono wrapper attorno alle librerie standard. Le eccezioni sono quegli ambienti che cercano di astrarre tutto (Java, Mono, Gambas per dirne tre) che vorrebbero essere multipiattaforma. Basta ignorarli. :) > Se devo creare un report di stampa alivello professionale, è melgio > partire da zero con le librerie, o creare un file di testo per latex e > farglielo processare? Per alcune cose è meglio usare reportlab da python, per esempio. Per altre magari generare HTML e trasformarlo in pdf con wkhtml2pdf, o generare markdown e trasformarlo in epub, pdf e html in modo da averlo leggibile ovunque. Insomma, dipende. :) > Alla fine avremmo ottenuto in poche settimane di lavoro, un gestionale > con interfaccia a caratteri perfettamente funzionale. Dipende dal gestionale, ma in poche settimane, volendo, puoi farlo anche in PHP. Prendi Bootstrap+Backbone o AngularJs per il frontend, Symfony o un altro framework per il backend, ecc. E sarebbe anche multipiattaforma (magari con IE>9 :P) > bho... per il momento non mi viene in mente altro. Io credo che tu stia cercando di sostituire un buon programmatore con un pessimo tool. :) Non offenderti. Capisco che non sei un programmatore, ma un tool come quello che proponi avrebbe limitazioni troppo strette per andare oltre la classica agenda telefonica o il programmino per prendere note o fare un todo. O comunque "attirerebbe" schiere di script kiddies e verrebbe ignorato dai senior. Gli strumenti ci sono, e sono anche abbastanza potenti. Il problema è la "spinta" di cui un team avrebbe bisogno per mettersi a sviluppare una cosa del genere. E soprattutto un team di senior che sappiano quello che fanno. Se nessuno paga per avere un gestionale che giri su Linux, nessuno si metterà a farlo. Quando fai un gestionale, per quanto scrivi nella licenza "senza nessuna garanzia", se uno te lo paga o comunque lo usa per metterci la contabilità, si aspetta che le garanzie ci siano, e se succede qualcosa ti trovi in tribunale, alla faccia della GPL. Scusami, confesso che la mia era una domanda trabocchetto. ;) Bye. -- Per REVOCARE l'iscrizione alla lista, inviare un email a [email protected] con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a [email protected] To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
