Web app vs Desktop

[Rik]

Per riprendere un mio post (http://www.lazaruspascal.it/index.php?topic=3.msg7#msg7),
ed ancor piu` un discorso iniziato sul forum inglese di Lazarus,
segnalo un articolo importante dal titolo: "Why is your desktop app not a web app?"
language free visto che piu` che altro riguarda un paradigma, un sistema di progettare in partenza una applicazione.

L'autore ha chiesto a vari progettisti di ditte importanti tipo la Saab e addirittura all'UNESCO, perche' lavorano su progetti desktop invece di creare una applicazione web (sott'inteso RIA). Qui potete leggere le risposte.
http://java.dzone.com/why-desktop-not-webapp

Non sono un fanatico di nessuno dei 2 mondi, ma siccome ne vedo invece un sacco per i quali se non e` un'applicazione web e` cacca, con tale articolo, specie per chi lavora solo con Lazarus e` un ottimo spunto per prendere a calci nei denti tali oltranzisti-web-religiosi!

E` veramente una scelta complicatissima oggigiorno dover iniziare una nuova applicazione di medie o grandi dimensioni e scegliere il sistema giusto di realizzarla. Non esiste un sistema garantito ed unico da usare sempre. Dipende dal target e persino dal tipo di dati o di scopo. Immaginatevi ad esempio che casino fare un gestionale di vendita al banco da 500.000 righe di codice, che gestisca registratori di cassa, lasers, badges, scanners, immagini, usando dei framework ajax, Flash o Silverlight. SI PUO` ANCHE FARE, ma necessita un web server, codice lato server di interfacciamento, roudtrips dei dati client->server->client per le cose piu` banali, ecc. Altre situazioni sono meno semplici da valutare. A volte il gioco vale la candela, altre volte no. Fatto sta che e` garantito che il paradigma "Tutto web based" e` sbagliato al 100%.

[xinyiman]

Caro Rik sono pienamente daccordo con te! 
Lettura interessante!

[Rik]

Aggiungo anche una cosetta che e` spesso taciuta da chi lavora con uno dei mille framework o toolkit ajax, o ancora piu` in generale con linguaggi non tipizzati (javascript in primis lato client, seguito da lato server con php, python, ecc.): il casino che viene fuori quando si supera la dimensione X.

Personalmente uso quotidianamente Eclipse per i progetti web. Sto studiando Dojo per il quale l'unico IDE decente (in grado cioe` di aiutare un pochino, se non altro col code completion) e` Netbeans. Quindi so di cosa parlo.

Sto valutando di rifare un gestionale gia` esistente, attualmente di oltre 100.000 righe di codice VB (quindi di alto livello) in Dojo che e` il toolkit migliore per realizzare grandi applicazioni Ajax (a differenza ad esempio di un piu` noto jQuery).

Faccio un passo indietro per spiegare meglio a chi non e` avvezzo alle robe web di cosa sto parlando: una applicazione RIA e` una applicazione che ha al 99,99% una parte server che risponde alle domande ed una parte client che sta nel browser (punto essenziale per essere Rich Internet Application). La parte client puo` essere Flash, Applet java, Silverlight, OPPURE Ajax, termine che di per se' non indica un mezzo preciso, bensi` un qualsiasi sistema basato su javascript (non a caso significa Asynchronous JavaScript and XML... anche se oggi piu` che XML viene usato json per il dialogo client/server).
Perche' Ajax e non gli altri sistemi? Perche' se non altro Ajax non e` proprietario e non lascia a piedi nessuno se la ditta chiude. Inoltre, anzi SOPRATTUTTO a differenza degli altri NON NECESSITA INSTALLARE NULLA sul computer, cosa invece che non si puo` dire di Flash, Java, Silverlight.

Per questo motivo, per me il RIA preferenziale va fatto in Ajax, senno` si va in una via di mezzo che non sa di una mazza... e come stare con 1 piede in 2 staffe.

E torno al punto: programmare lato client in JS.

Problema tipico: non esiste un compilatore per cui gli errori li tira fuori il browser o gli strumenti tipo Firebug. A nulla aiuta un ottimo toolkit come Dojo, e ancora MOLTO meno uno piu` scarno come jQuery che non e` strutturato per grandi progetti.

Succede cosi` che quando spunta un errore, l'unica cosa che aiuta e` l'errore stesso nel browser/firebug. Non c'e` un sistema per cui prima di andare in esecuzione il compilatore dice: "Ciccio! Che minkia ci sta a fare quella variabile non dichiarata da nessuna parte? Non e` che hai sbagliato a digitare?". Ogni cosa e` come se in Lazarus si programmasse usando il late bound e basta, dove il compilatore non sa una mazza di niente e sta zitto perche' qualsiasi cosa si scriva puo` essere ok, valutabile solo a runtime.

Alcuni errori vanno cosi` ricercati col lanternino perche' diventano come errori di logica piu` che di sintassi, anche laddove magari sono invece solo di sintassi.

Non solo c'e` il problema della tipizzazione assente e quindi non c'e` modo di valutare se si e` sbagliato il tipo, ma non c'e` una mazza di nulla... e` come programmare in gwbasic.... e neanche.
Capirete che fare un'applicazione di 100.000 righe cosi`, diventa leggermente complicato con tutte le accortezze del caso ed con tutti i buoni ide del mondo (che poi sono solo 2 Eclipse e Netbeans... per Dojo ora c'e` solo Netbeans che non ha neanche un plugin apposito, bensi` e` adattabile perche' scansiona tutto e crea un code sense approssimativo) !

Quindi, oltre ai discorsi tecnici che si possono fare ad applicazione CONCLUSA, c'e` anche da fare discorsi tecnici A MONTE DELLA REALIZZAZIONE!

Sicuramente non usando Ajax ma prodotti proprietari come Flash e Silverlight le cose sono piu` semplici... ma ne vale la pena mettersi sotto le grinfie di ditte che ogni 5 minuti cambiano idea?!!!
Ho un amico che in VB6 ha fatto un CRM di MEZZO MILIONE di righe di codice. Non l'aveva ancora finito che m$ ha ritirato VB6 uscendosene con una cagata di VB.net completamente diverso, per cui una conversione da VB6 a VB.net e` praticamente complessa come trasformare l'applicazione in Java.
Con Adobe le cose non vanno meglio. Ad esempio su Linux mette e toglie il supporto una volta al giorno! Si puo` fare un'applicazione multipiattaforma importante in Flash con tali premesse? Certo, tecnicamente si`, ma ne vale la pena? E` come mettersi un cappio al collo sperando che nessuno inciampi nella corda.

Sicuramente fare RIA con C# e` infinitamente piu` semplice e professionale, ma quanto ci si puo` fidare di una azienda che ha gia` dimostrato di mandare a cagare i programmatori con VB6 fregandosene altamente persino delle petizioni? Io di m$ non mi fido piu` e l'ho abbandonata completamente. Non lavoro neanche piu` con Windows, solo Linux. Windows lo considero solo come output per i clienti, ma non per lavoro mio.

Un altro modo di fare RIA e` con la piattaforma Google. A dimostrazione di quanto dicevo sopra, quelli di Google si sono resi conto che anche per fare cagatine di applicazioni tipo Gmail, e` un macello lavorare direttamente in JS, per cui hanno realizzato un compilatore di Java che trasformare in JS, cosi` programmano in Java che e` un linguaggio tipizzato con IDE da paura e strumenti super collaudati, e solo in finale esce il JS.

Pure Oracle (ex Sun, ovvero i nuovi proprietari di Java), con JavaFx, per il poco che conosco JavaFx mi pare stia prendendo questa strada.

MORALE: Web si, ma con dovute cautele. Deve proprio essere INDISPENSABILE e soprattutto si deve partire con la consapevolezza giusta di cosa serve fare e quanto grande diventa l'applicazione per non sbagliare strumenti.
Ma soprattutto sottolineo il fatto che purtropo, ad oggi, di open, non esiste una mazza di nulla che permetta di fare qualcosa di grande a livello di app web RIA. Non si puo` fare un mostro in JS programmando con VIM o Notepad perche' ci vuole un millennio a fare cio` che in altro modo si fa in una settimana. E la manutenzione poi diventa da suicidio!

Per cui attualmente, anch'io sono in un limbo decisionale come non lo sono mai stato in 40 anni di carriera informatica. O uno si butta su prodotti commerciali fregandosene del futuro e vada come vada si mette il cappio al collo, oppure ci si trova in un mare di abbrocciaggine che molti vedono come Geek a differenza mio che la vedo come cagate transitorie buttate li' o giocattoli tirati all'estremo (tipo Ciao Piaggio truccato che fa 180 perdendo bulloni per strada).

La soluzione migliore che ho trovato per fare grandi applicazioni (intendo robe che in Lazarus potrebbero venire fuori come 300.000 righe di codice), e` la seguente:

1) Client desktop. Non per questioni di velocita` di cui un gestionale se ne frega (sebbene JS sia veramente penoso e la modifica del DOM del browser idem), quanto per POSSIBILITA`. Pensate ad esempio a ridimensionare un'immagine. Immaginate un software che in una scheda debba memorizzare 10 immagini. Il cliente ha fatto le foto come solito a massima risoluzione e sono da 2MB l'una. Totale 20 MB. Con un prodotto Ajax che gira nel browser, si dovrebbero uploadare 20MB e lato server ridimensionarle per un totale di 2 o anche meno. Capite l'illogicita` della cosa? Immaginate un ufficio con 20 dipendenti che fanno una cosa simile ed immaginate lentezza e traffico di upload: tutti a trasmettere 20 mega che si accodano a 400K della adsl in up! Da suicidio! Si paralizza tutto. Con un client desktop invece non ci vuole nulla ridimensionare in locale e non costa risorse ad un serve centrale che si affosserebbe. Lo fa il cliente senza disturbare nessuno e uppa solo 1 MB di immagini ridimensionate a 100K (da usare ad esempio per un e-commerce, quindi a video).
Accettando di programmare desktop ci si trova con linguaggi come Lazarus o Java SE+Swing che sono come programmare con VB: la parte piu` rognosa che e` l'interfaccia si crea visualmente invece che tramite codice e gli eventi si raggiungono con un click.
Inoltre si hanno linguaggi tipizzati, con compilatore serio che avvisa di mille problemi in anticipo, non quando un bel giorno esplode tutto o nel DB e` finita una caterva di spazzatura dovuta ad una variabile errata.

2) WEB service: a differenza di un cli/serv classico, diventa importante creare un sistema tipo web service (o API). Perche`? Perche' questo permette di scindere ottimamente le risposte dai dati e dalla business logic. In questo modo si puo` creare un client in Lazarus o in Java SE, ma con poca fatica anche uno molto specifico per un iPhone, senza compromessi web come invece avverrebbe cercando di fare di tutta un'erba un fascio, ovvero facendo tutto come pagina web RIA, usando Ajax o Flash o altro. Un utente di iPhone vede bene la differenza tra una vera app ed una paginetta web piccola. Tanto piu` se invece che una roba online deve essere qualcosa che funziona anche offline dentro l'iPhone o nella tablet.
Se si vogliono fare cose molto professionali, non esiste un sistema per fare la cosa 1 volta solo per tutto (anche se alcuni prodotti ci tentano). Un'interfaccia per un monitor 22 pollici non puo` essere la stessa di uno a 7. Per quanto si possa fare degli ottimi sistemi di ridimensionamento, cambia proprio la LOGICA DELLA GUI. Cambia la suddivisione dei menu. Cambia tutto. Non si puo` ADATTARE 1 sola gui web a tutto. Detto questo risulta evidente che necessita fare le GUI diverse, usando se necessario anche linguaggi diversi. Questo riporta a bomba: scindere bene la GUI da tutto il resto per non dover rifare l'intera applicazione cambiando il "terminale" d'interazione con la business logic.

I punti 1 e 2 hanno molti altri sotto punti che ora non menziono. Purtroppo questo porta ad una conclusione: e` impossibile fare tutto questo solo in Lazarus a meno che non si facciano dei CGI da mettere sui web server o che non si disponga di server propri dove si puo` far girare qualsiasi cosa.

Pero` almeno la parte desktop per PC classici e` sicuramente fattibile in Lazarus anche con tale ottica.

Purtroppo devo sottolineare che il linguaggio che meglio si presta a questo tipo di ottica non e` Lazarus ma Java perche' e` one for all, nel senso che gira su desktop, web server, cellulari, e ovunque.... sebbene sempre in ottica di massima economicita` per l'utente, personalmente la parte server la farei comunque in PHP perche' e` onnipresente su qualsiasi web server, persino quelli Windows con IIS. Molto piu` difficile e costoso e` invece trovare un web server con Java (Tomcat, Glassfish, ecc.).

MA SOPRATTUTTO parlo di Php per un altro fatto: la possibilita` di passare da applicazione che gira su un computer standalone, alla stessa applicazione usata a livello enterprise con servizi su web server in Internet. Mi spiego:

1) Applicazione web su web server. Vengono fornite pagine html. Stop

2) Applicazione Desktop in locale. Stop.

-----  Vie di mezzo ------

3) applicazione desktop con DB remoto (classico client/server)

4) applicazione desktop che interroga web service online

5) applicazione RIA che interroga web service online (il browser scarica la app ria e la mostra e questa dal browser agisce verso il web service come fa quella desktop)

6) Cio` che non puo` fare una app RIA e figata pazzesca: avere un web server locale con DB locale che viene lanciato dalla APP stessa e niente che necessita installazione con tutto che gira anche senza internet MA VOLENDO raggiungibile da uffici remoti via ADSL.
Questo significa avere una applicazione che si comporta sia come applicazioncina da edicola (anzi addirittura puo` essere portable) e che al contempo DA SUBITO puo` essere usata per accesso esterno (apertura router porta 80) con cellulari ed altri PC desktop remoti.
Se invece l'azienda si espande e necessita:
a) non essere con il computer dell'ufficio sempre accesso
o
b) necessita di molte connessioni dall'esterno tali che l'ADSL dell'ufficio non li regge,
basta spostare il DB online passando da un micro Sqlite ad un piu` tosto MySql ed il web serverino integrato (che NB: con PHP5.3 e` gia` incluso in PHP!!! ) si trasforma in Apache.
Nessuna perdita di dati, nessuna modica al software e si scala da applicazioncina standalone portable a super applicazionciona in grado di gestire 1 milione di utenti remoti.

Non vedono nessun'altra struttura migliore. Le altre sono o troppo enterprise da subito e diventano poco economiche e complicate (e ad esempio non vendibili come applicazione Stand Alone), oppure sono troppo classiche e legate solo al mondo desktop.

Questo sistema, ripeto, in parte e` realizzabile anche in Lazarus, sebbene il linguaggio top sarebbe Java perche' entro certi limiti e` riciclabile anche sui cellulari senza dover cambiare linguaggio. Inoltre col Java webstart si prendono anche i clienti che sono propensi a robe che girano solo su web dato che la loro idea deriva dal non dover gestire nulla in locale (e cosi` sarebbe visto che la differenza da Flash diventa solo che gira esterna alla cornice del browser... che e` solo un VANTAGGIO in piu`).

Pero` con un po' di accorgimenti e qualche fatica in piu` anche con Lazarus questa struttura e` parzialmente fattibile.

E con una roba cosi`, il RIA classico al confronto pare un abbroccio ridicolo che complica solo la vita, utile solo laddove ci siano utenti saltuari che devono vedere una roba nel browser 1 volta all'anno o 1 volta una tantum.
Sono convinto che NESSUNO preferirebbe lavorare con app ajax o flash nel browser dopo aver testato con mano l'uso di una struttura simile che mixa linguaggi nativi a servizi web. E` lo stesso motivo per cui Gmail fa cagare chiunque sia abituato all'uso di un client di posta locale e che vede in Gmail online solo una scappatoia per quando il client nativo non ce l'ha sotto mano. Ma se gli diamo la stessa cosa con java webstart o smartphone o con interfacce xhtml (magari solo per robe tipo agenda, visualizzazioni ecc. senza dover gestire tutto cio` che fa il client nativo)  voglio vedere chi preferisce l'interfaccia one-for-all che in realta` e` un abbroccio-for-all scritta in JS o Actionscript, ecc.

Ergo: il desktop non solo non e` morto, ma ATTENZIONE perche' questo e` il momento buono per SFONDARE sul mercato, mercato che oggi vedere una marea di invasati fissarsi sul voler per forza fare tutto online a scapito di qualsiasi cosa, mentre in azienda a me telefonano sempre piu` ditte che chiedono esplicitamente ROBA DESKTOP perche':
1) Hanno paura a mettere dati online (e fanno bene perche' anche per legge tutto cio` che e` online e` visionabile da enti statali SENZA CHIEDERE NULLA)

2) Non vogliono essere penalizzati da mancanza di rete.

3) Non vogliono pagare abbonamenti perche' specie con la crisi tendono a risparmiare. Magari spendono di piu` una tantum, ma ci sono tante ditte piccole che ci tengono a non avere abbonamenti e anche per l'assistenza pagare solo quando serve.

4) Si incavolano quando, CLASSICO, ADSL o web hanno i momenti di intasamento e vanno di fretta per cui il nervosismo sale.

Questo con una pura app web e` fattibile solo mettendo un web server in LAN, ma capirete che la cosa si complica rispetto ad un prodotto che invece puo` essere un vero desktop e scalare online.

Ad ogni modo, lasciando perdere questa struttura, ribadisco che comunque le app desktop non sono morte, non moriranno e anzi ora come ora che c'e` crisi rischiano di andare via come il pane!

[xinyiman]

Tutto verissimo! Anzi addirittura sacrosanto! 

[xinyiman]

Ti andrebbe di entrare nel dettaglio del punto 6! Da te mensionato?!

Dicci qualcosa di più! Potresti fare un esempio per cui tale metodo è significativo!

[Rik]

In pratica, si resta sempre con la struttura di base formata da un client nativo + web server, ma cio` che cambia e` CHE TIPO di web server si va ad usare. Se e` per gestire come il piu` delle volte succede, entro le 10 postazioni, come DB basta Sqlite (basta e` un eufemismo visto che ne potrebbe gestire benissimo 1000 o anche 10000 in base a come lo si usa) e come web server (premesso che un apache e` di fatto portable e quindi si potrebbe pure usare quello), ora si puo` pure usare PHP 5.4 (sopra ho sbagliato a scrivere 5.3) che ha gia` all'interno un web server. Questo significa che aggiungendo al proprio applicativo una cartella con dentro PHP 5.4 (che ovviamente non necessita installazione), l'applicazione basta che lanci php come un qualsiasi altro comando shell (tenendo presente che NON termina) e si ritrova un web server attivo sulla propria macchina, in grado di rispondere a richieste http.
Nella fattispecie il comando e`

Codice: [Seleziona]

$ php -S localhost:8000

che ritorna

Codice: [Seleziona]

Server is listening on localhost:8000... Press CTRL-C to quit.

Volendo essere leggermente piu` professionali basta comunque portarsi dietro una cartella con un qualsiasi webserver lite. Ce ne sono a bizzeffe, tutti senza install, basta lanciare 1 comando e restano li' in ascolto. Potrei menzionare lighttpd, Litespeed che usato con PHP e` 1,5 volte piu` veloce di Apache (http://litespeedtech.com/), nginx, ecc.

In questo modo il client nativo (es. scritto in Lazarus) non usa connessioni a DB classiche, ma si comporta come un browser specifico che chiama il webserver locale.
Un sistema cosi` (non ho parlato della business logic che e` la parte forse piu` importante e complicata, ma per ora non importa) permette alla ditta che lo usa di passare da app simil stand alone da 50 euro, a 10 postazioni in lan senza fare una mazza, e ha gia` tutto la possibilita` di funzionare anche da remoto aprendo il router sulla porta del web server (es. lavorare da casa con i dati nell'ufficio), ed in finale, il giorno che deve super-scalare perche' e` diventata la FIAT, si sposta il web server dell'ufficio che neanche sapevano di avere, su un server che sta in hosting in una webfarm dove non hanno problemi di banda come ha invece l'ADSL dell'ufficio e tutto prosegue come prima.

La stessa cosa non potrebbe essere fatta con un collegamento diretto a DB per vari motivi aggirabili e non

1) Difficilmente in hosting danno accesso diretto ad un DB con connessione classica.

2) La connessione classica, statica, prevede l'occupazione di una porta fino a quando non si chiude il programma, cosa che potrebbe portare problemi di quantita` di porte disponibili e di consumo di ram sul server. I sistemi invece tipicamente usati in unione ai web server sono connessioni mordi e fuggi: connessione->query->sconnessione. Questo mangia qualche mS ma il gioco vale la candela

3) Chi ci dice che altri tipi di clients possano accedere ad un determinato DB? Se invece il dialogo avviene in forma di web service (da envelope soap a piu` semplici pacchetti custom con xml o json o piu` semplici API web dedicate con json come sistema di dialogo) la risposta e` usabile pure da una lavatrice!


E qui si passa al punto piu` importante: la business logic.
Pero` ne parlo piu` tardi o domani perche' bisogna che mi metta al lavoro.

[xinyiman]

si ho capito, ma sostanzialmente tu sostieni di usare il lato server per interfacciarsi al db! Giusto?! E Basta?! Quindi come se ricevessimo una pagina html con dentro i dati formattati come li vogliamo noi! Ed eventualmente cifrati in qualche modo! Giusto?! E poi il resto invece usare Lazarus (o java)! Correggimi se sbaglio...

[Rik]

Quasi, nel senso che quello e` il layer di astrazione dal DB (o dai dati) e stop. Se puo` interessare solo l'astrazione dal DB in modo che non servano driver specifici, puo` anche andar bene fermarsi qui, ma non e` cio` che mi interessa.

Oltre all'astrazione dal DB e` importante separare la business logic senno` l'applicazione andrebbe rifatta per intero per desktop, poi per i client xhtml, poi ancora per smartphone, ecc.

E qui viene un punto problematico per Lazarus rispetto a Java. Con java la business logic potrebbe avere tutta o una bella fetta comune ai vari clients e stare lato client. Con Lazarus invece deve per forza stare lato server perche' dubito che Lazarus funzioni su iPhone (al massimo ci funzionera` il pascal), e sicuramente non nei browsers, mentre Java funziona ovunque anche se in base al tipo di device avra` piu` o meno possibilita`.

In quest'ottica quindi con Lazarus al massimo si arriva al rich client nativo desktop e magari usando solo il pascal si puo` interagire anche con API dell'iPhone, ma sara` posso immaginare che sara` molto piu` laborioso e comunque sara` impossibile usare il pascal nei browser. Per questo motivo, se si pensa di fare la struttura come da me illustrata, con Lazarus la business logic conviene metterla sul server.
Cio` significa che tutta l'applicazione dovra` essere usabile con chiamate al server http. Il piu` dell'applicazione dovra` quindi essere in PHP (o cgi pascal se si preferisce).
Lavorando in Java invece tutta tale parte puo` essere lato client perche' la manipolazione dei dati in java e` fattibile pure dentro il pannello di un frigorifero! 

Qual'e` la differenza tra business logic sul server o lato client? Esempio pratico: selezionare un'immagine presente nel device (PC, smartphone, ecc.) ridimensionarla e salvarla con una chiamata al web service.
Se la business logic e` nel web service sara` necessario inviargli l'immagine non ridimensionata e ci si viene quindi a trovare con lo stesso problema di una applicazione puramente html che deve prima uppare sul server 20 MB di immagini per poi avere solo 1MB di immagini ridimensionate. E` abbastanza illogico.
Se invece la business logic e` lato client al web service gli spediamo solo 1 MB contro 20.

C'e` da dire che ci sono pochi casi in cui ci si trova in situazioni simili. Resta pero` il problema che anche senza dover ridimensionare immagini, alla fine tutto il carico finisce sul web service ed il client non fa nulla se non mostrare i dati e spedirli... cosa che sarebbe meglio evitare visto che un web server si satura, mentre 1 client no (o se lo fa non ce ne frega una mazza perche' e` un problema localizzato... mentre un web server che si pianta significa legnate da parte di 1000 clienti che telefonano incavolati).
Immagina un'applicazione che deve fare delle statistiche o fare calcoli scientifici: un conto e farli lato client sfruttando il processore del PC, un altro e` farli lato server dove si va a rallentare tutto il resto, anche l'altro PC che sta solo chiedendo 4 righe di agenda.
Non che sia strano perche' oggigiorno tutte le applicazioni online funzionano cosi`, pero` il fatto e` che vorrei MIGLIORARE non fare dei surrogati all'applicazione web.

Come ovviare con Lazarus? Sui desktop non c'e` da ovviare nulla: la business logic si fa in lazarus. Va solo scissa come strato logico ma gira sempre sul client dove e` anche il codice della GUI. Il problema viene su altri tipi di client, come smartphones o browsers. Sugli smartphone si puo` usare il pascal senza lazarus (nel senso di "Senza libreria grafica di Lazarus", solo il linguaggio pascal che interagisce con le API native, credo). Sui browser invece non c'e` proprio scampo, va fatta una applet java o flash o silverlight (sconsigliatissimo visto che su Linux fa cagare... praticamente non sarebbe multipiattaforma). Pero` cosi` c'e` un GRANDE problema: la business logic va fatta 2 volte in 2 linguaggi diversi. Non e` fattibile.... e` poco logico. Un sacco di lavoro in piu` che e` fattibile solo se necessitano solo parte di funzioni semplici, tipo vedere un'agenda. Non si puo` certo rifare la business logic 2 volte per un programma di contabilita`!
Per cui secondo me con Lazarus l'unica e` business logic lato server con override di certe funzioni tipo ridimensionamento immagini che usando un client non desktop saranno gestite con il ridimensionamento lato server, mentre con un client desktop si usa una seconda business logic che chiameremo "Helper" perche' contiene solo delle funzioni particolari tipo ridimensionare le immagini o quelle cose che vale la pena gestire 2 volte. IL 95% della business logic sara` tutta sul server usata sia dai desktop che piccoli device, mentre un 5% (helper) sara` un duplicato lato client solo sui desktop che sono anche i client piu` usati per lavoro serio e che quindi allevieranno tantissimo il carico sul server.

Spero di essermi spiegato. Ho fatto un po' di ridondanza sperando sia utile a fare chiarezza su cosa intendo dire.

[Rik]

Piccola aggiunta: immaginiamo il caso di un programma di vendita al banco come avevo gia` indicato in post precedenti. Di certo in un browser non si puo` gestire periferiche particolari a meno che queste non abbiano una loro API web o un web server embedded come ad esempio hanno gli scanner di rete funzionanti in WAN. Ci si trova comunque di fronte a variazioni di prezzo allucinanti, del tipo che uno scanner ordinario costa 70 euro e l'altro 1000. Diventa leggermente complicato essere competitivi cosi`. Un conto e` una software house che mira solo a vendere all'industria, ed un conto e` una software house che punto alle PMI. Spesso quando si parla di RIA spuntano fuori DIPENDENTI, risottolineo, DIPENDENTI (mai proprietari), che lavorano in una ditta che vende alla FIAT o alla CAMERA, ovvero software house che se ne stra-sbattono se per fare una scansione il cliente deve acquistare una periferica da 2000 euro o una qualsiasi periferica che costa 40 volte piu` del normale. Vorrei che tali signori si presentassero con una app RIA con JAVA EE, Application Server vari, DB Oracle, ecc., a vendere ad un alimentari con 2 dipendenti! Vorrei vedere che calci in culo rimediano!

E` per questo motivo che sto parlando di mix "strani". Se non ci fossero problemi di costi usiamo Java EE con tutti gli ammennicoli vari di contorno e stop. Di coloro che dicono: "Non voglio essere online ma neanche avere in azienda JBOSS e Oracle" ce ne freghiamo e siamo a posto. Ma se invece vogliamo prendere piu` clienti possibili, di cui le micro aziende e PMI sono il 97% ed il 3% di grandi industrie resta nei sogni ma si vuole comunque lasciare una porta aperta, ci si deve un po' ingegnare come illustravo sopra.

Viceversa non resta che smanettare 2 o 3 volte in piu` creando lo stesso prodotto 2 o 3 volte: 1 con Lazarus solo desktop, 2 con Ajax, 3 con Java EE. Dubito sia un bella strategia pero`.

[xinyiman]

Si penso di aver capito cosa intendi. Spunti interessanti comunque.

[Stilgar]

Come è finita?

[xinyiman]

E' finita che io ho acquistato una licenza raudus e nei prossimi giorni lo provo per vedere cosa è cambiato! Poi vi aggiorno

[Rik]

Ciao xinyiman!
Io nel frattempo mi sono trasferito in UK e praticamente il 99% della programmazione e` sullo lo stack php/mysql/html5/css/js/jquery/[bootstrap].

[Danycop]

Ciao a tutti,
questo è il mio primo post,
sono un programmatore VB5/VB6 felicemente approdato a Lazarus dopo estenuanti ricerche di un RAD degno di tale nome...
Nell'attesa di vedere finalmente realizzato un clone di intraweb anche in lazarus
e cercando qualcosa di simile a Raudus, mi sono imbattuto in questa pagina sommario di tecnologie WEB presso Embarcadero:
https://community.embarcadero.com/pt/blogs/entry/web-front-end-frameworks-webinar

penso sia un utile compendio di tecnologie interessanti e che possa interessare a molti, in particolare l'ultimo link:
http://www.cybelesoft.com/thinfinity/virtualui/

descrive una tecnologia che in pochi minuti è in grado di trasformare un'applicazione delphi, Lazarus, VB6, C# e VB.NET in una WEBApp!
Io l'ho provata con un programma di 50000 LOC in VB6 ed anche con una piccola app di prova ( accesso a DB Jet tramite ODBC e Report ) in lazarus ed ha funzionato a primo colpo!
buon Lavoro a tutti.

[SB]

http://www.cybelesoft.com/thinfinity/virtualui/
descrive una tecnologia che in pochi minuti è in grado di trasformare un'applicazione delphi, Lazarus, VB6, C# e VB.NET in una WEBApp!
Io l'ho provata con un programma di 50000 LOC in VB6 ed anche con una piccola app di prova ( accesso a DB Jet tramite ODBC e Report ) in lazarus ed ha funzionato a primo colpo!

Non metto in dubbio che funzioni e non l'ho nemmeno provata, ma vorrei esprimere la mia perplessità su questo tipo di soluzioni.
Visto il nome, viste le applicazioni simili dell'azienda, visto il costo, visto che basta aggiungere una riga di codice... presumo che sia semplicemente una versione ridotta di un desktop remoto e quindi siamo ben lontani da una applicazione web, anche se può funzionare dentro un browser...
Se ho ragione, l'unico reale vantaggio che si ottiene è quello di evitare di installare il programma in tutti i computer degli utenti di un'azienda.
Infatti l'interfaccia viene inviata come immagine della form, e per l'input vengono inviati all'applicazione gli eventi di mouse e tastiera del client.
Questo vuol dire che funziona discretamente bene in una rete locale ad alta velocità e non intasata.
La vedo molto dura usare una simile soluzione nel web, soprattutto con dispositivi cellulari (consumo di traffico, banda limitata, schermi ridotti, interfaccia touch, ecc)
Inoltre trasformando l'applicazione in un server si hanno problemi di sicurezza, carico computazionale, accesso alle risorse.
Non so... applicazioni simili esistono da decine d'anni e non mi risulta che, per quanto affascinanti, siano mai decollate.
Forse in futuro, quando il traffico sarà più veloce e meno costoso e il servizio di housing sarà economico anche per server molto potenti... ma comunque mi appoggerei ad un servizio server ben consolidato e non ad una libreria sconosciuta.