Ciao a tutti.
Stavolta cerco un suggerimento "progettuale".
Vorrei provare a fare un "prototipo" in genropy di una idea che ho
(riguarda riclassificazione bilanci, budget, forecast ed altre amenità
del genere).
In pratica, l'idea è di lavorare su "schemi", che l'utente può
liberamente configurare e relazionare tra loro.
Ora, io un modello dati l'ho in mente, ma non ho idea se poi sia
rappresentabile con strumenti "gui", sia che siano standard, sia che
siano da realizzare appositamente.
L'idea, un po' semplificata, sarebbe quella di avere:
1) un'anagrafica schema (gli schemi disponibili);
2) un set di righe e colonne per ciascuna anagrafica;
3) una tabella "istanza dello schema"
4) una tabella dati che faccia corrispondere il valore desiderato (o più
avanti a formule di calcolo) al relativo schema/riga/colonna.
(evidentemente questa è una tabella potenzialmente "pesante", in termini
di record)
Ora:
1) è banale.
2) è potenzialmente semplice: una o due tabelle in relazione con la
tabella anagrafiche mi consentono di definire lo schema.
Potrebbe essere una tabella, correlata all'anagrafica, con due campi uno
per individuare la riga, uno per individuare la colonna, e quindi
metterei in relazione direttamente la cella, OPPURE due tabelle, uno per
le "righe", uno per le "colonne". Ci devo pensare...
3) è di nuovo banale, associo l'anagrafica a una determinata istanza
(potrebbe essere un mese, un anno, una cosa del genere...)
4) sarebbe comunque un model semplice, mette insieme i vari pezzi di cui
sopra per individuare il valore di una cella di una specifica istanza di
uno schema.
Il model quindi l'ho già abbastanza individuato, il problema è però
gestirlo dal punto di vista dell'interfaccia utente!
I widget che "conosco" (parola grossa... diciamo "che ho visto
funzionare") ragionano giustamente sui record delle tabelle, io invece
dovrei costruire una "tabella" incrociando righe e colonne "arbitrarie"
(o, meglio, decise dall'utente e non dal progettista).
Vi pare fattibile una cosa del genere?
Eventuali suggerimenti in merito?
Potrei anche pensare di cambiare il model dove necessario, ma questo
model avrebbe delle implicazioni su successive elaborazioni e features
che vorrei provare a implementare, quindi non vorrei stravolgerlo
troppo, ma qui sto già andando anche troppo oltre...
Che ne pensate?
ciao,
m.
