[Python] scrivere app python con layout grafico in html5?
Giovanni Porcari
giovanni.porcari a softwell.it
Gio 25 Giu 2015 22:10:09 CEST
> Il giorno 25/giu/2015, alle ore 21:34, Gian Mario Tagliaretti <g.tagliaretti a gmail.com> ha scritto:
>
> Il 25 giugno 2015 19:11, Giovanni Porcari
> <giovanni.porcari a softwell.it> ha scritto:
>
>> Prima di tutto ti ringrazio per il tempo che hai speso per darmi questi esempi.
>
> Ma figurati, grazie a te.
>
>> Devo dire che sono più che altro impressionanti per la mole di dati presentata
>> allo stesso tempo. Immagino che gli utenti usino monitor molto grandi ;)
>
> E' vero, la mole di dati è davvero tanta, abbiamo un cliente in
> sud-africa che sta facendo attività di project control per un progetto
> di sviluppo in Botswana che durerà da 5 a 8 anni, non ti dico la mole
> di dati contenuti nella schedula delle attività e la complessità del
> calcolo del forecast, in particolare del forecast average (tra early e
> late) che noi lasciamo graduare all'utente.
>
>> Però ho utenti che lavorano quotidianamente su web application molto complesse.
>
> Immagino, ero in effetti curioso di capire se pensi che la seconda
> applicazione (TMS, non quella con interfaccia spreadsheet per
> intenderci) sia fattibile con le tecnologie attuali.
>
> Attualmente distribuiamo le nostre applicazioni tramite Citrix XenApp
> creando una sorta di EffettoApplicazioneWebDeiPoveri, ai clienti in
> genere non dispiace, chiaramente ci leghiamo non a una bensì a due
> vendor, Microsoft e Citrix, se uno dei due CEO impazzisce o se perdono
> una causa miliardaria sui brevetti e vanno in chapter 11, andiamo da
> culo anche noi. (Il tutto è un po' esagerato ma in fondo è un po'
> così)
>
>> Giusto per darti un esempio, una società di autotrasporti con depositi nel nord Ialia
>> ha un pannello di gestione (planning) dove in tempo reale arrivano le richieste
>> visualizzate in una prima griglia per linea di trasporto dove sono mostrati il numero
>> delle richieste, i metricubi e i quintali prer ogni linea. Cliccando su una riga di questa prima grid
>> nella grid alla sua destra si presentano le richieste di trasporto di quella riga con i dati relativi
>> (peso, tipo merce luogo di partenza, luogo di arrivo ecc).
>
> Impressionante anche la vostra applicazione, davvero complimenti, è
> scritta con genropy?
Si certo :P
Genropy nasce per fare cose complesse e devo dire che mi sta dando moltissime soddisfazioni.
>
>> Nella parte sottostante c’è una griglia dei viaggi allocati nel giorno corrente
>> e nei giorni seguenti sempre in funzione della linea selezionata nella prima riga.
>> Per ogni viaggio oltre ai dati del mezzo ( Telonato, con sponde, portata ecc) ci sono
>> i dati dell’autista (con relativi permessi per merci pericolose) il totale di peso e volume
>> già allocato sul viaggio e cliccando sul viaggio nella griglia a fianco si vedono
>> le righe di borderò già allocate. L’operatore dragga dalla griglia superiore una o più
>> righe sul viaggio desiderato e tutto si aggiorna in tempo reale su ogni utente collegato.
>> Il tutto è estremamente dinamico e gli operatori sono assolutamente felici della facilità
>> con cui allocano i trasporti e hanno tutto sotto mano in una sola videata.
>>
>> https://www.dropbox.com/s/y8ccwegmkxh1w3a/planning.png?dl=0
>>
>> Abbiamo moltissime applicazioni di analoga complessità e quindi mi piaceva l’idea di confrontarmi
>> con chi deve gestire realtà complesse per capire i limiti del nostro strumento.
>
> La mia prima preoccupazione nel riscrivere TMS, sarebbe capire se le
> celle delle griglie sono editabili o se sono solamente read only, per
> noi è indispensabile l'editing della cella nella maggior parte
> dell'applicazione, ad esempio in quella dove viene fatta la pesatura
> relativa delle attività dello scheduling.
>
> Anche l'inserimento dei dati da parte dei contractor esterni dovrebbe
> prevedere l'editing di una porzione di celle, quelle grigio scuro nel
> terzo screenshot di TMS [4], al momento esportiamo uno spreadsheet
> bloccato in ogni parte con solo le celle di inserimento del progress
> editabili, un esempio è questo [1]. (Lo spreadsheet ricalcola
> immediatamente il progress all'inserimento dell'avanzamento nelle
> celle grigio scuro, in modo che il contractor sia consapevole del
> proprio avanzamento ad ogni cut-off date)
>
Le nostre griglie possono tranquillamente essere editabili e con una sofisticata gestione
dei controlli. Se hai 5 minuti da buttare datti un occhio allo screencast
del migration tool (https://vimeo.com/131523423).
Potrai notare che l’editing delle celle delle grid e estremamente agevole
e è possibile mettere nelle celle sia delle formule risolte lato client
che lato server. Un foglio elettronico magari meno raffinato di excel
a comunque decisamente potente.
> Nella roadmap 2015/2016 del prodotto abbiamo inserito di avere questa
> parte di data collection via web, pensando di utilizzare per l'appunto
> sencha/ext.js che lo permette (con parecchio sforzo a dire il vero).
>
> Ci sarebbero un bel po' di altri dettagli naturalmente, ma non volevo
> trasformare la lista python in un "desktop vs web app", piuttosto
> andiamo fuori a pranzo un giorno e ne parliamo, con tutto quello che
> ci sarebbe da dire, fino a notte inoltrata :)
Volentieri. Mi piacerebbe capire che limiti avremmo con Genropy
perchè per ora devo dire che siamo riusciti a fare tutto quello
che volevamo e con uno sforzo davvero modesto. Confrontarsi con
te potrebbe essere un’ottima occasione per misurare la validità
di Genropy in contesti di grande complessità.
>
> L'altra applicazione (Spider) credo che non abbia nessuna speranza,
> nemmeno con uno sforzo titanico come ha scritto Carlos, lo UI
> spreadsheet like è irriproducibile in una web-app.
>
Ehm… mi piacerebbe raccogliere il guanto della sfida :P
> [1] https://dl.dropboxusercontent.com/u/969502/C3_DATA.xlsx
>
> ciao a tutti e scusate lo stratosferico OT
Penso che parlare di applicazioni web scritte in python non sia più OT
che parlare di roulette :D:D:D
Ciao e grazie
G.
Maggiori informazioni sulla lista
Python