Privacy Policy [FOLBlog] WDF rivoluziona il modo di realizzare le applicazioni web – Parte 1 (di enrico)

Ricerca in FOLBlog

Feb 052009
 

image

Alcuni mesi orsono ho accennato all’imminente arrivo di un nuovo, rivoluzionario framework per lo sviluppo di applicazioni web complesse.
Con il deposito di brevetto effettuato nel dicembre scorso è ora possibile svelare alcuni aspetti e iniziare ad approfondire l’argomento.

Non ho esitato a definirlo rivoluzionario per ciò che consente di fare e la facilità con cui rende possibile creare applicazioni web complesse in poco tempo, ottenendo risultati quasi impensabili con gli attuali migliori strumenti si sviluppo web.

Oggi ho il piacere e l’onore di pubblicare un’intervista realizzata con l’ideatore del framework, Davide Gaibotti, laurea in Ingegneria Informatica al Politecnico di Milano, che ne ha implementato una versione perfettamente funzionate utilizzata attualmente dalla sua società, Evoluzione Sistemi, per lo sviluppo di applicazioni web.

Enrico: “Innanzitutto complimenti; ho avuto il piacere di vedere all’opera una applicazione realizzata con il tuo framework e ne sono rimasto molto colpito. (vedi snapshot)
Com’è nata l’idea del framework? Qual’è stata la considerazione o la motivazione alla base?”

Interfaccia applicazione WeD

Davide: “Lo sviluppo di applicazioni web è oggi caratterizzato da una molteplicità di tecnologie, sia lato server che lato client.
Quando il progettista inizia a studiare l’architettura di questo tipo di applicazioni, deve ben presto porsi il problema di come disporre le varie parti logiche sui vari livelli dell’infrastruttura web e conseguentemente deve decidere quali tecnologie adottare.
Deve scegliere il tipo di tecnologia server, come ASP, ASP.net, PHP, Java Servlet, etc… il tipo di tecnologia client, come HTML, JavaScript, VBScript, Flash, Applet Java, etc… il tipo di refresh delle pagine: refresh completo o refresh parziale.
Anche se la scelta di una o più di queste tecnologie potrebbe sembrare solo una questione di preferenze del progettista, di fatto, ha un forte impatto sul come devono essere progettate le componenti server e client, sull’usabilità dell’applicazione e sull’adeguamento agli standard.
Durante lo sviluppo di applicazioni desktop, il progettista ha invece normalmente a disposizione un unico framework di riferimento, come Microsoft.NET o J2EE ed un unico linguaggio di programmazione, spesso Object Oriented come C# o Java, sia per realizzare le componenti lato client che per realizzare quelle lato server.

Quasi sempre dispone inoltre di numerose librerie grafiche con oggetti complessi come Form, Button, TextBox, DropDown, ListView, TreeView, Grid ed altri che gli consentono di sfruttare a pieno le potenzialità grafiche dei moderni sistemi operativi, realizzando così applicazioni con una elevata user experience.
Conseguentemente, per il progettista, risulta molto diverso sviluppare un’applicazione web da una desktop.
WDF [questo è il nome del framework n.d.r.] rende invece possibile sviluppare un’applicazione WeD [WeD application, dove WeD è l’acronimo di Web/Desktop, n.d.r.] utilizzando gli stessi strumenti e lo stesso paradigma utilizzato per lo sviluppo di applicazioni stand alone.

Enrico: “In sostanza si scrive il codice in uno dei linguaggi .NET esattamente come si farebbe per realizzare un’applicazione desktop, avendo a disposizione set di controlli simili a quelli che ritroviamo in questo tipo di applicazioni (Form, Button, TextBox, DropDown, ListView, TreeView, Grid, ecc.).?”

Davide: “Esattamente.”

Enrico: “Beh, ma anche con altri framework si possono realizzare delle interfacce con controlli avanzati, simili a quelli presenti nelle applicazioni desktop…”

Davide: “Attualmente, per costruire applicazioni web che seguano le direttive del W3C è necessario appoggiarsi, per la parte di codice residente lato client, alla coppia di tecnologie HTML/JavaScript. Queste tecnologie, per quanto potenti, soffrono tuttavia di una serie di problemi:

  • L’HTML non ha il concetto di finestre, bensì quello di pagine.
  • Il linguaggio JavaScript è un linguaggio interpretato e non appartiene alla categoria dei linguaggi object oriented pur avendo alcune caratteristiche similari.
  • Gli eventi grafici presenti all’interno delle pagine web non sono nativamente correlati con altrettanti eventi lato server.

Ne consegue che in diverse applicazioni risulta decisamente laborioso effettuare dei controlli sull’operatività dell’utente, tenendo conto inoltre che molti di questi controlli richiedono accesso alle componenti della business logic che si trovano lato server.”

Enrico: “Mi pare di capire quindi, che ad aver ispirato la nascita di WDF non sia tanto la necessità di rendere possibile la realizzazione di interfacce con controlli avanzati.
Interfacce complesse possono anche essere realizzate con strumenti come Flash, o framework come  ExtJS ma costringono ad una mole enormemente maggiore di lavoro; di fatto è questo il motivo per cui certe cose, pur tecnicamente realizzabili, non val la pena di implementarle.
Invece il vostro framework rende il processo produttivo delle applicazioni web efficiente quanto quello della realizzazione di applicazioni stand alone, riutilizzando efficacemente strumenti e competenze già in possesso della vostra azienda, facendovi risparmiare un mare di tempo. E’ così?”

Davide: “Si. WDF infatti mette a disposizione del progettista un framework che consente di sviluppare applicazioni web come se fossero applicazioni desktop e quindi modificando di fatto il paradigma di programmazione delle applicazione web stesse.
Il progettista può così ragionare con componenti complesse come Form, Button, TextBox, DropDown, ListView, etc… all’interno di un linguaggio object oriented senza dover pensare a come queste componenti lavoreranno lato client.
WDF nasconde le logiche di comunicazione tra client e server e fa sì che sia il più naturale possibile poter intercettare gli eventi client sul lato server.”

Enrico: “In pratica tutti quei programmatori che fino ad oggi hanno sviluppato applicazioni desktop utilizzando linguaggi tradizionali, con questo nuovo framework possono continuare a fare la stessa cosa essendo ora in grado però di produrre anche applicazioni web complesse?”

Davide: “Diciamo che questo è…un effetto collaterale; a me quel che rodeva è che per realizzare cose relativamente semplici e che con gli strumenti per lo sviluppo di applicazioni desktop non rappresentavano alcuna difficoltà, si era invece costretti a risolvere una montagna di problemi collaterali dilatando enormemente i tempi di realizzazione del prodotto finale”.

Enrico: “In cos’altro si differenzia un’applicazione WeD da un’applicazione web realizzata con gli strumenti attuali e quali sono invece le analogie con le applicazioni desktop?”

Davide: “Nelle applicazioni web tradizionali, l’interfaccia grafica è fortemente orientata sul concetto di pagina e sul concetto di navigazione tra pagine.
Per alcuni tipi di applicazioni questo approccio può risultare appropriato, ma per altri tipi di applicazioni può risultare molto scomodo e decisamente poco appropriato.
Nelle applicazioni desktop complesse infatti l’interfaccia grafica è basata sul concetto di finestra e non su quello di pagina.
Più finestre possono essere aperte contemporaneamente ed ogni finestra può contenere al suo interno molte componenti grafiche.
WDF fornisce allo sviluppatore un ambiente multi-finestra che gli permette di aprire, all’interno di una applicazione WeD, una o più finestre contenenti una o più componenti grafiche interattive come Button, TextBox, InputBox, DropDown, ListView, TreeView, Grid ed altro.

Durante lo sviluppo di applicazioni desktop, ci sono molte situazioni in cui è necessario dover interrompere l’esecuzione del codice per poter richiedere all’utente alcune informazioni prima di proseguire.
Si pensi ad esempio a tutte quelle situazioni in cui chiudendo una finestra si voglia avvertire l’utente di salvare le modifiche appena apportate. In tutte queste occasioni è necessario aprire una richiesta di salvataggio, in cui l’utente si trova obbligato a rispondere, la cui risposta consentirà all’applicazione di intraprendere le azioni più idonee.
WDF, da un lato gestisce l’obbligatorietà della richieste aprendo finestre di tipo pop-up e dall’altro sospende l’esecuzione del processo che ha effettuata la richiesta verso l’utente, così da poter successivamente eseguire le azioni più idonee una volta ottenute le risposte.

Infine, nello sviluppo di applicazioni desktop, si ha la necessità di predisporre del codice che sia attivabile in relazione a determinate azioni intraprese dall’utente sull’interfaccia grafica. Pensando ad esempio ad un controllo di tipo Button, è immediato comprendere la necessità di poter avviare una qualche porzione di codice in risposta alla sua pressione.
WDF
implementa la gestione degli eventi, cioè quei meccanismi che rendono trasparente la comunicazione di un evento grafico (come il click di un pulsante avvenuto all’interno di un web browser) al server e che consentano quindi l’avvio automatico delle porzioni di codice associate all’evento stesso.”

Enrico: “E per poter usufruire di tutto questo ben di Dio, cosa occorre installare, lato client? Quali plugin sono necessari per  poter utilizzare un’applicazione WeD?”

Davide: “Nessun plugin. Nessuna estensione, ne’ alcun controllo ActiveX. Niente di niente.
La tecnologia utilizzata per la gestione dell’interfaccia grafica è l’HTML nella sua versione più estesa nota come HTML 4 o DHTML.
La tecnologia dei CSS è usata da WDF per avere il massimo controllo sulla formattazione grafica dei contenuti visualizzati all’interno della pagina.
WDF usa DOM per costruire e modificare in modo dinamico il contenuto della pagina, evitando così di dover effettuare dei refresh completi dei contenuti ogni qual volta una parte di questi necessiti di un cambiamento.
Per poter riuscire a manipolare la pagina tramite DOM e poter quindi aggiungere, modificare ed eliminare tag e attributi grafici è necessario un linguaggio di programmazione. Per fare questo WDF utilizza JavaScript la cui forza è quella di essere stato standardizzato dalla ECMA.
Per effettuare la comunicazione con il server è utilizzato AJAX che, grazie allo scambio in background di piccoli pacchetti di dati, non costringe a ricaricare l’intera pagina web ogni volta che l’utente effettua una modifica riuscendo quindi ad assicurare una migliore interattività, velocità e usabilità.
In sintesi, per utilizzare un’applicazione WeD occorre un comunissimo browser e nient’altro.

Enrico: Se uno sviluppatore avesse bisogno di costruire nuovi componenti grafici da utilizzare nelle proprie applicazioni potrebbe farlo?”

Davide: “Certamente. Uno dei grossi vantaggi di lavorare con linguaggi object-oriented è proprio quello di poter estendere i componenti di base per crearne di nuovi più specializzati. WDF fornisce già una buona libreria di componenti grafiche di base e queste ricombinate possono essere utilizzate come mattoni per costruirne di nuove, il tutto senza scrivere codice HTML o JavaScript”

Enrico: “Dato che l’architettura di WDF è realizzata tramite il Framework .NET di Microsoft….”

Davide: “Abbiamo iniziata a realizzare anche una versione che si basa su J2EE; ma per motivi contingenti legati a necessità interne alla mia azienda, abbiamo sviluppato maggiormente la versione .NET, che risulta, al momento, molto più evoluta della versione J2EE del framework

Enrico: “Ah, buono a sapersi. Quindi in futuro si potrà avere anche una versione del framework che consenta di sviluppare in Java e non solo in uno dei linguaggi Microsoft .NET.
E quali sono i requisiti lato server?”

Davide: “WDF, nella versione .NET, si appoggia completamente al framework .NET di Microsoft.
Tramite questa tecnologia è possibile sviluppare sia le componenti basate sull’architettura ASP.NET, necessarie alla comunicazione tra il web browser ed il server web funzionante tramite IIS, che le componenti del middle-tier che consentono una gestione centralizzata delle componenti applicative ed una migliore scalabilità delle prestazioni.
WDF sfrutta il framework .NET per entrambi gli scopi.
Tramite le pagine aspx, WDF crea il ponte tra le chiamate AJAX, in arrivo dal client, e le componenti del middle-tier preposte alla risoluzione delle richieste.
La comunicazione tra le componenti ASP.NET e le componenti del middle-tier è effettuata tramite la tecnologia Remoting del framework .NET che consente ai vari processi distribuiti di comunicare attraverso una rete permettendo una migliore distribuzione del carico di elaborazione e consentendo di posizionare le componenti del middle-tier su server differenti rispetto a quello in cui è in esecuzione il web server.

La versione di WDF implementato usando la piattaforma J2EE, si appoggia invece al framework J2EE.
Tramite questa tecnologia è possibile sviluppare sia le componenti basate sull’architettura Java Servlet, che le componenti del middle-tier che consentono una gestione centralizzata delle componenti applicative ed una migliore scalabilità delle prestazioni.
WDF sfrutta J2EE per entrambi gli scopi.
Tramite le servlet, crea il ponte tra le chiamate AJAX, in arrivo dal client, e le componenti del middle-tier preposte alla risoluzione delle richieste.
La comunicazione tra le componenti servlet e le componenti del middle-tier è effettuata tramite la tecnologia RMI, una tecnologia che consente a processi Java distribuiti di comunicare attraverso una rete.
L’utilizzo della tecnologia RMI permette una migliore distribuzione del carico di elaborazione, consentendo di posizionare le componenti del middle-tier su server differenti rispetto a quello in cui è in esecuzione il web server.

Enrico: “Come intendete immettere sul mercato il framework?”

Davide: “Ci sembra naturale tentare di proporre il framework a Microsoft che sarebbe anche il soggetto più adatto per integrare il proprio ambiente di sviluppo in modo da prevedere la realizzazione di applicazioni WeD in modo visuale. Staremo a vedere se a Redmond saranno interessati.”

Enrico:Quindi attualmente non è stato ancora realizzato un apposito IDE con cui creare interfacce WeD in modo visuale, posizionando i vari controlli a disposizione?”

Davide: “No. Attualmente utilizziamo Visual Studio ed i controlli dell’interfaccia li inseriamo manualmente tramite la scrittura di codice C#.”

Per il momento, credo che leggendo le risposte di Davide in molti si possano iniziare a fare un’idea più precisa di cosa sia questo nuovo framework e dell’enorme impatto che può avere in questo settore.
Di colpo una miriade di sviluppatori tagliati fuori dallo sviluppo di applicazioni per il web si ritrovano nuovamente messi in gioco.
Inoltre si apre un ventaglio di possibili evoluzioni la cui portata risulta ancora difficilmente prevedibile.

In conclusione, esistono altri framework che consentono di ottenere analoghi risultati riguardo all’interfaccia (si veda ad esempio ExtJS); la particolarità e la rivoluzione di WDF è nel modo in cui è possibile realizzare l’applicazione:

  • Si utilizza un unico linguaggio object-oriented come C# e non l’ensamble di altri vari linguaggi di scripting sia per gestire la parte grafica dell’applicazione che per gestire le componenti di business;
  • Si utilizza l’ambiente di sviluppo preferito;
  • Si utilizza il medesimo paradigma di programmazione utilizzato per la creazione di applicazioni desktop (stand alone), cosa che consente di realizzare un’applicazione web a tutti quegli sviluppatori che non hanno mai visto PHP, Flash o altri strumenti utilizzati attualmente per sviluppare applicazioni web.

Come si realizza l’applicazione WeD con WDF sarà oggetto del prossimo articolo in cui verrà illustrata la procedura di realizzazione di una semplicissima applicazione WeD.

Articoli simili:

  19 Risposte a “WDF rivoluziona il modo di realizzare le applicazioni web – Parte 1”

Commenti (16) Pingbacks (3)
  1. Usando Mozilla Firefox Mozilla Firefox 3.0.5 con Mac OS X Mac OS X 10

    Moooolto interessante 😛

    Proprio ora sto studiando RMI. In più ho sviluppato un annetto fa un portale di e-commerce in AJAX e JSF e so cosa vuol dire “lavoro e fatica extra” per sviluppare un applicazione web complessa rispetto ad una desktop. In più sarebbe un orgoglio tutto italiano!

    La tua domanda più bella è stata:

    “Quindi attualmente non è stato ancora realizzato un apposito IDE con cui creare interfacce WeD in modo visuale, posizionando i vari controlli a disposizione?”

    LoL. Il tipo non ti ha risposto sbarrando gli occhi??? Sviluppare un IDE apposito non è che sia proprio la cosa più facile e veloce della storia dell’informatica. Piuttosto vedrei meglio un plugin per Visual Studio o Eclipse.

    Attendo con impazienza il prossimo articolo!

  2. Usando Mozilla Firefox Mozilla Firefox 3.1b2 con Windows Windows Vista

    EnricoC. ha scritto:

    Il tipo non ti ha risposto sbarrando gli occhi???

    No “il tipo” è un tipo molto saggio e paziente….
    In realtà nel passato anche recente hanno sviluppato IDE per altre loro applicazioni ma fino ad ora non per questo; perchè il framework è già “produttivo” in questo modo per loro, per cui preferiscono concentrare risorse per altri scopi (ad esempio l’evoluzione del framework stesso)

    Poi certe domande sono appositamente un po’ naif per far capire a tutti di cosa si tratta.

    EnricoC. ha scritto:

    Piuttosto vedrei meglio un plugin per Visual Studio o Eclipse.

    Si credo anche io che la strada sarà quella.
    Credo anzi che sia per quel motivo che si è pensato di sottoporre il framework all’attenzione di Microsoft.

    Un’alternativa potrebbe essere quello di dare in pasto alla comunità opensource le specifiche strettamente necessarie per sviluppare o un IDE ad hoc oppure un plugin per questo o quell’altro IDE esistente.
    Ma chissa se ci potrà essere un ruolo per l’opensource in questa faccenda….

  3. Usando Mozilla Firefox Mozilla Firefox 3.0.5 con Windows Windows XP

    Prima di lanciarsi nell’open source farebbero meglio a guadagnare un certo quantitativo di quote di mercato altrimenti rischiano solamente di crearsi più concorrenza gratuita che validi aiuti allo sviluppo senza contare i fork che uscirebbero a raffica disgregando quello che fino adesso sono riusciti a costruire.

  4. Usando Internet Explorer Internet Explorer 8.0 con Windows Windows Vista

    C’e’ qualcosa che mi sfugge, va bene la parte di UI, uno la realizza come fosse un’applicazione stand alone e il framework la “traduce” in applicazione Web.
    Quello che non quadra e’ la parte di codice che scrivo in C#… viene tutto eseguito lato server? In questo caso non capisco davvero che vantaggi possa offrire rispetto a ASP.Net.
    E se ho bisogno di scrivere codice che venga eseguito lato client?

  5. Usando Mozilla Firefox Mozilla Firefox 3.0.5 con Windows Windows XP

    “E se ho bisogno di scrivere codice che venga eseguito lato client?”

    Probabilmente non userai questo sistema. Penso che la cosa sia perfettamente voluta per far fronte a tre possibili problemi:

    1- Inquinamento dei dati (in un programma di ecommerce permetteresti al client di fare i conti ?)
    2- Una questione di compatibilità. Le web application, per quello che ho capito, sono nate con lo scopo di girare ovunque senza considerare (o comunque riducendo al minimo) problematiche di compatibilità. L’unica cosa quasi standard presente in ogni sistema operativo è proprio il browser per cui non è il caso di cercar di far girare robe sui client, dovendo poi stare dietro a problemi di compatibilità ad esempio con le macchine virtuali.
    3- Con questo sistema infine puoi collegare tanti terminali a basso costo/potenza/consumi e farli lavorare tranquillamente.

  6. Usando Internet Explorer Internet Explorer 8.0 con Windows Windows Vista

    OK 0verture, ammettiamo queste ipotesi, quindi in questo caso ASP.Net col codice C# lato client cosa avrebbe in meno rispetto al framework WDF?

  7. Usando Internet Explorer Internet Explorer 8.0 con Windows Windows Vista

    intendevo “lato server” ovviamente, non “lato client”.

  8. Usando Mozilla Firefox Mozilla Firefox 3.0.6 con Windows Windows XP

    Ottimo lavoro, ma rispetto ad ASP.NET e ai suoi controlli AJAX dove sta il vantaggio?

  9. Usando Mozilla Firefox Mozilla Firefox 3.1b2 con Windows Windows Vista

    @il nonno, Matteo Italia

    Per quanto riguarda il codice scritto dal programmatore sì, questo viene tutto eseguito tutto lato server.
    I componenti grafici di WDF invece, a seconda delle esigenze, alcune cose le fanno autonomamente lato client e per altre chiamano in modo opportuno il server.

    Per quanto riguarda le differenze rispetto ad ASP.NET le più importati direi che sono:

    – In ASP.net si ragiona fondamentalmente con il concetto di pagina mentre WDF con il concetto di finestre

    – ASP.net è basato su HTML/XML e quindi su TAG mentre per WDF la GUI viene rappresentata in modo similare a quanto fa la libreria System.Windows.Forms di Microsoft

    – Il programmatore non deve MAI scrivere porzioni di codice che generino dinamicamente codice HTML. E’ WDF che pensa a questo in modo automatico.

    – In WDF esiste intrinsecamente il concetto di ereditarietà dei controlli e delle form così come si può fare con Windows.Forms.
    E’ possibile quindi scrivere una form di base per poi ereditarla e quindi specializzarla un numero “n” di volte a piacere.
    Stesso discorso per i controlli.

    – WDF permette di astrarsi completamente da quello che accade lato client. Quindi l’unico codice client che gira è quello di WDF stesso.

    – L’astrazione che WDF offre, ha l’effetto collaterale di consentire di scrivere, con le dovute accortezze, applicazioni che vadano sia su Windows sia sul Web
    Proprio perchè le wed application vengono pensate con la stessa filosofia delle applicazioni desktop.

    0verture ha poi centrato 3 bersagli su 3 😀

  10. Usando Internet Explorer Internet Explorer 8.0 con Windows Windows Vista

    Le 3 puntualizzazioni di 0verture sono poco significative, puoi fare le stesse cose con ASP.Net.
    Qui si confonde il poter fare una cosa con il non volerlo fare.
    Il fatto che ASP.Net permetta codice client side non significa che si debba usare codice client side. WDF invece da quello che dite non lo permette, cosa questa che non e’ affatto elencabile come un vantaggio rispetto ad ASP.Net, ma trattasi di una limitazione, e non da poco.

    Da come la vedo WDF e’ pensato per uno specifico tipo di applicazione. Cosi’ come e’ stato descritto sembra piu’ un accelerator che un framework generalizzato.

    A parte l’ultimo punto che hai descritto per il resto tutto quello che dici si fa con WDF si puo’ fare altrettanto bene con ASP.Net.

    Resto in attesa di vedere del codice per capire meglio di cosa stiamo parlando perche’ al momento non mi e’ affatto chiaro come quanto descritto si possa definire una “rivoluzione”.

  11. Usando Mozilla Firefox Mozilla Firefox 3.0.6 con Windows Windows XP

    Enrico ha scritto:

    @il nonno, Matteo Italia
    – In ASP.net si ragiona fondamentalmente con il concetto di pagina mentre WDF con il concetto di finestre

    Ecco, questo, se in alcuni casi può essere utile, mi sembra un po’ controproducente nella maggior parte dei casi. Le applicazioni web anche come resa visiva hanno un aspetto differente rispetto a quelle desktop, e l’aspetto “web” viene solitamente percepito dall’utente come più gradevole (non chiedermi il perché, non ne ho idea).

    – ASP.net è basato su HTML/XML e quindi su TAG mentre per WDF la GUI viene rappresentata in modo similare a quanto fa la libreria System.Windows.Forms di Microsoft
    – Il programmatore non deve MAI scrivere porzioni di codice che generino dinamicamente codice HTML. E’ WDF che pensa a questo in modo automatico.

    Questo può essere controproducente; e se volessi apportare dei cambiamenti al codice della pagina? Non è un qualcosa di limitante?

  12. Usando Mozilla Firefox Mozilla Firefox 3.0.5 con Windows Windows XP

    “non chiedermi il perché, non ne ho idea”

    Te lo dico io perchè: abitudine !

    Quello è un affare per produrre programmi che dovranno essere usati da persone comuni, abituate al modello del desktop e della finestra. Se invece avesse lo scopo di produrre programmi ad uso e consumo di altre categorie di professioni/esperti probabilmente finirebbe per avere un’interfaccia diversa.
    Di certo la possibilità di poter convertire un programma da win a wdf in maniera abbastanza trasparente non è cosa da sottovalutare

  13. Usando Internet Explorer Internet Explorer 8.0 con Windows Windows Vista

    Certo, e’ una cosa molto interessante in un certo ambito, non certo in generale, perche’ credo sia chiaro che un’applicazione client “grossa” non ha senso farla girare server side, altrimenti sarebbe gia’ nata come applicazione thin-client, e nel mondo reale non ci sono solo applicazioni thin-client ma spesso c’e’ bisogno di un mix tra client side e server side.
    Il punto sarebbe valutare se usando WDF ci si metta effettivamente meno tempo rispetto ad ASP.NET senza pero’ dover fare compromessi in altri ambiti (vedi ad esempio il testing o il debugging).

  14. Usando Mozilla Firefox Mozilla Firefox 3.1b2 con Windows Windows Vista

    @il nonno, Matteo Italia

    WDF non vuole essere un sostituto di ASP.Net ma una sua estensione, per scrivere applicazioni complesse con un livello di astrazione ancora più elevata.

    La possibilità di poter scrivere applicazioni di “business” complesse con il concetto di finestra anzichè quello di pagina aiuta notevolmente.

    Qualunque modifica grafica si può farla manipolando i componenti grafici che WDF mette a disposizione.
    L’obiezione fatta da Matteo al riguardo, è come dire che quando programmo con Windows.Forms ho bisogno di scrivere codice assembly modificare l’interfaccia grafica.
    Non serve, è Windows.Forms che astrae questo aspetto ed è questo quello che WDF fa rispetto al browser.

    La possibilità di modificare l’aspetto delle form è già prevista nel framework, ciò significa che il componente Form del fw prevede già la possibilità di cambiare il proprio layout tramite alcune proprietà.
    In sostanza funziona così: si crea una nuova classe che eredita dalla classe base.
    Nel costrutture di questa si può agire tramite delle proprietà di stile opportune su tutte le caratteristiche esterne della finestra tipo: colore della barra del titolo, icona da visualizzare nell’angolo in alto a sx e così via.
    Come sfruttare questa prerogativa, è lasciata alla scelta dello sviluppatore che può realizzare un’applicazione con un layout fisso, oppure un’applicazione con un layout personalizzabile a discrezione dell’utente, in modo simile a quello che avviene con i temi di XP/Vista/Windows 7 o le skin di programmi come Winamp.

    Il framework deve essere visto come uno strumento per creare applicazioni, con la massima libertà, non come un CMS con le limitazioni imposta da chi lo ha creato.
    Non è un acceleratore (tipo Google Gear).

    E’ vero che, pur essendo possibile, non ha senso utilizzare WDF per fare semplici pagine web (non si ammazza la formica con un cannone); la massima utilità si ha con applicazioni web complesse, di tipo business (si pensi ad un’applicazione di home banking, o un CRM, o una qualsiasi applicazione di back end).
    Il fatto che in teoria è possibile usarlo per tutto non significa che sia una buona ragione per farlo; non uso Vistual Studio Entrprise Super Mega Multi per scrivere una macro di 2 righe per Excel.
    Diverso è il discorso per chi non ha mai fatto un’applicazione web prima d’ora ma ha esperienza di programmazione desktop: per questo tipo di figure professionali WDF potrebbe essere l’unico modo di realizzare un’applicazione web senza esser costretti ad imparare nulla di nuovo.

    Insomma, WDF non è ne’ un’applicazione così verticale come la descrive il nonno, ne’ uno strumento all-purpose pensato per sostituirsi in tutti gli ambiti in cui occorra realizzare qualcosa per il web.

    Infine, riporto anche qui alcune obiezioni e mie risposte date sul blog di Paperino:

    neppure in ASP.Net devi scrivere codice lato client se non vuoi.

    Vero, ma in diverse situazioni, per rendere l’applicazione più usabile diventa quasi un’utopia non farlo.

    Esempio: prova a scrivere un’applicazione ASP.net (senza codice lato client e quindi scritta tutta in C#) che realizzi una gestione di Dockbar (draggabili) simile a quella presente in Visual Studio

    anche con ASP.Net puoi astrarti completamente dal lato client.

    Ripropongo lo stesso esercizio di prima 😉

    …non vedo particolari vantaggi offerti da WDF e mi sa che se aggiungiamo all’equazione le variabili strumenti di debugging e deployment mi sa che ASP.Net risulta avvantaggiato.

    Per scrivere WeD applications si usa Visual Studio e quindi non si perde niente in termini di debugging e deployment.

    0verture mi sembra molto vicino ad aver capito esattamente come stanno le cose.

    Son convinto che una volta capito come si scrivono le applicazioni weD (e magari aver visto i rislutati ottenuti) molte cose saranno più chiare.

  15. Usando Mozilla Firefox Mozilla Firefox 3.0.5 con Windows Windows Vista

    ok iniziano l’opera di demolizione (almeno dei miei dubbi) 😕

    premetto che sono uno sviluppatore web 😎

    1 aspetto principale i server windows sono una minoranza del totale, il framework funzionerà anche su linux/apache/mono in caso negativo la vedo dura finchè non uscirà la versione J2EE.

    2 enfatizzate il fatto che anche i programmatori “classici” che creano applicazioni stand-alone possano entrare nel mercato, ditemi un pò avete messo in conto tutte le problematiche di rendering diverso tra i vari browser esistenti? O fate leva solo sul onnipresente Internet Explorer(che ha il peggior motore di rendering rispetto agli standard)? e le problematiche di sicurezza, di gestione di una banda per il passaggio dei dati sempre ridotta (nonostante le adsl)?

    3 In una risposta parlate di problematiche
    cit.
    “Davide: “Attualmente, per costruire applicazioni web che seguano le direttive del W3C è necessario appoggiarsi, per la parte di codice residente lato client, alla coppia di tecnologie HTML/JavaScript. Queste tecnologie, per quanto potenti, soffrono tuttavia di una serie di problemi:

    * L’HTML non ha il concetto di finestre, bensì quello di pagine.
    * Il linguaggio JavaScript è un linguaggio interpretato e non appartiene alla categoria dei linguaggi object oriented pur avendo alcune caratteristiche similari.

    e dopo dite
    “Davide: “Nessun plugin. Nessuna estensione, ne’ alcun controllo ActiveX. Niente di niente.
    La tecnologia utilizzata per la gestione dell’interfaccia grafica è l’HTML nella sua versione più estesa nota come HTML 4 o DHTML.
    La tecnologia dei CSS è usata da WDF per avere il massimo controllo sulla formattazione grafica dei contenuti visualizzati all’interno della pagina.
    WDF usa DOM per costruire e modificare in modo dinamico il contenuto della pagina, evitando così di dover effettuare dei refresh completi dei contenuti ogni qual volta una parte di questi necessiti di un cambiamento.
    Per poter riuscire a manipolare la pagina tramite DOM e poter quindi aggiungere, modificare ed eliminare tag e attributi grafici è necessario un linguaggio di programmazione. Per fare questo WDF utilizza JavaScript la cui forza è quella di essere stato standardizzato dalla ECMA.
    Per effettuare la comunicazione con il server è utilizzato AJAX che, grazie allo scambio in background di piccoli pacchetti di dati, non costringe a ricaricare l’intera pagina web ogni volta che l’utente effettua una modifica riuscendo quindi ad assicurare una migliore interattività, velocità e usabilità.
    In sintesi, per utilizzare un’applicazione WeD occorre un comunissimo browser e nient’altro.”
    in pratica mi sembra di capire che vi basate su dom javascript (ajax è Javascript oltretutto) e css
    (cosa che i programmatori web seri fanno da tempo).

    Ricordate che ci sono diverse interpretazioni dei vari browser di javascript come avete indicato nella prima frase riportata . Inoltre, sempre grazie ad internet explorer non è possibile creare applicazioni 100% w3c corrette in quanto bisogna usare una marea di hack, codice fuori standard per ottenere gli stessi risultati su diversi browser. E non si possono trascurare oramai i browser concorrenti visto che vengono utilizzati da circa un terzo dei navigatori.

    Un’altra cosa che mi lascia perplesso è il fatto che il codice lato client venga “creato” dal framework vistro che io sono contro la creazione di codice automaticamente sul web perchè gli editor visuali (dreamweaver, Frontpage e il suo sostituto) creano degli orrori assurdi con tonnellata di robaccia inutile che rendono impossibile o quasi effettuare mautenzione sul codice in caso di problemi.

    Scusate la franchezza ma io rimango molto scettico su soluzioni del genere.
    Il mondo web ed il mondo desktop nella progtrammazione sono ancora molto distanti, e questa sembra la rielaborazione dei primi sistemi dinamici del web: i vecchi CGI che potevano essere scritti in perl o anche in linguaggi tradizionali tipo C o C++.

  16. Usando Mozilla Firefox Mozilla Firefox 3.1b2 con Windows Windows Vista

    francesco calvisi ha scritto:

    1 aspetto principale i server windows sono una minoranza del totale, il framework funzionerà anche su linux/apache/mono in caso negativo la vedo dura finchè non uscirà la versione J2EE.

    Vero.
    Non a caso sono state previste entrambe le versioni (.NET e J2EE).
    Il fatto che la versione .NET sia attualmente molto più evoluta della versione J2EE dipenda solo dalle necessità contingenti dell’azienda che ha realizzato e utilizza attulamente WDF .NET
    Non c’è dubbio che se l’idea si rivelasse buona, il gap è destinato ad azzerarsi.

    francesco calvisi ha scritto:

    2 enfatizzate il fatto che anche i programmatori “classici” che creano applicazioni stand-alone possano entrare nel mercato, ditemi un pò avete messo in conto tutte le problematiche di rendering diverso tra i vari browser esistenti? O fate leva solo sul onnipresente Internet Explorer(che ha il peggior motore di rendering rispetto agli standard)? e le problematiche di sicurezza, di gestione di una banda per il passaggio dei dati sempre ridotta (nonostante le adsl)?

    Premesso che il programmatore non deve preoccuoparsi del rendering, di cui si occupa il framework, proprio in questi giorni sto provando una demo su vari browser.
    Funziona con tutti i browser, anche se con Firefox (sia versione per Win che per Linux) si presenta un problema (segnalato e su cui stanno lavorando) e su Opera (ho provato solo la versione per Win) un altro difetto (idem).
    Inoltre, fino ad ora l’ho provato su IE7 32bit, IE8 beta 64bit di Vista, IE8 incluso in Windows 7, e Chrome.
    Funziona tutto perfettamente tranne che su IE8 64bit di Vista, mentre su IE8 di Windows 7, funziona tutto alla perfezione ma a volte IE crasha.
    Mi sembra saggio comunque iniziare a spaccarsi la testa su IE8 quando sarà rilasciato in versione RTM. Fino ad allora i problemi potrebbero derivare dall’instabilità potenzialmente insita in ogni beta.
    Perciò si, è stato affrontato il problema della compatibilità cross-browser.

    Devo francesco calvisi ha scritto:

    noltre, sempre grazie ad internet explorer non è possibile creare applicazioni 100% w3c corrette in quanto bisogna usare una marea di hack, codice fuori standard per ottenere gli stessi risultati su diversi browser. E non si possono trascurare oramai i browser concorrenti visto che vengono utilizzati da circa un terzo dei navigatori.

    Sono proprio quei problemi si cui parlo nell’articolo e che sono stati uno dei motivi per cui WDF è nato.
    WDF è nato esattamente per astrarsi anche da queste problematiche; le affronta e le risolve, o meglio, tenta di risolverle una volta per tutte.
    Vedreme se e in che misura ci sarà riuscito e ci riuscirà.

    francesco calvisi ha scritto:

    Un’altra cosa che mi lascia perplesso è il fatto che il codice lato client venga “creato” dal framework vistro che io sono contro la creazione di codice automaticamente sul web perchè gli editor visuali (dreamweaver, Frontpage e il suo sostituto) creano degli orrori assurdi con tonnellata di robaccia inutile che rendono impossibile o quasi effettuare mautenzione sul codice in caso di problemi.

    Il framework fa in modo che restituisca al client una pagina web perfettamente renderizzata.
    Quando parli di codice ti riferisci all’HTML necessario per crearla?

    francesco calvisi ha scritto:

    Scusate la franchezza ma io rimango molto scettico su soluzioni del genere.
    Il mondo web ed il mondo desktop nella progtrammazione sono ancora molto distanti, e questa sembra la rielaborazione dei primi sistemi dinamici del web: i vecchi CGI che potevano essere scritti in perl o anche in linguaggi tradizionali tipo C o C++.

    E’ assolutamente normale essere scettici.
    Quando mi è capitato di parlarne a qualcuno in passato, mi guardavano con l’indulgenza che si riserva allo scemo del villaggio che racconta di aver visto gli ufo.
    E più la persona che avevo davanti era esperta, più era scettica.
    Ora vediamo come si realizzano le weD app, magari vediamolo in azione su una demo e poi valutiamo, no?
    Secondo me hai ragione: programmazione web e desktop sono attualmente molto molto distanti nonostante gli enormi sforzi profusi (lato web) per tentare di rendere il paradigma utilizzato in ambito web il più simile possibile a quello utilizzato in ambito desktop.
    WDF rappresenta una risposta, secondo me eccellente, proprio a questa esigenza.
    Può darsi che lasci irrisolto qualche problema (nemmeno io ho avuto modo di sperimentare WDF in lungo ed in largo), vedremo; non c’è la pretesa di aver realizzato lo strumento perfetto.
    Inoltre, non bisogna sottovalutare il fatto che WDF è “all’opera” (all’insaputa del mondo intero) già da oltre un anno; chi lo ha ideato ed implementato lo usa con successo per realizzare applicazioni web che fornisce ai propri clienti (e mica Cicco Pasticcio, ma aziende di un certo livello).

 Lascia un commento

Puoi usare questi tag e attributi HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(richiesto)

(richiesto)

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

%d blogger hanno fatto clic su Mi Piace per questo: