Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Rendering

Tempo fa avevo accennato ad un famoso pezzo di HTML che genera un output diverso in dipendenza del browser anche usando i pezzi più elementari di CSS.

Eccolo:

image Firefox 3.0.x
image Safari 4/Chrome 1.x
image IE 8

Il file HTML lo si può trovare qui. E pensare che c’è chi sogna di poter sostituire Office con un po’ di HTML/JavaScript in un mondo in cui la proliferazione dei browser sta diventando la regola.

-quack

P.S. è molto plausibile che di CSS non abbia capito una vera mazza, ma mi sembra paradossale ottenere rendering così diversi con davvero pochi elementi.

Update: Se non ci si vuol uscire pazzi consiglio questo post e questo tool.

Potrebbero interessarti anche:
Commenti (49): [ Pagina 1 di 2  - più vecchi ]
20. NickelGreen
venerdì 6 marzo 2009 alle 4:13 AM - IE 7.0 Windows Vista
   

Detto questo mi associo al coro di dissenso verso test come Acid3 et co. Se il risultato è che un browser può passare l'Acid3 ma fare come ca**o gli pare con il box-model vuol dire sicuramente qualcosa sulla qualità del test: forse che ci sono cose più fondamentali da testare e far allineare di qualche feature del piffero.

La pensa abbastanza così anche il "buon" Ed Bott. Ha senso un "test" con 23378978398 codici tutti assieme, che non si presentano MAI come tali ma spesso separatamente, come cartina di tornasole?
A me, sinceramente parlando, i difensori accaniti del W3C (o WC-3 direi) cominciano sempre di più a sembrare i vescovi del vaticano. Tutti a difendere le loro teorie (religiose, per l'appunto).

   
21. Enrico FOLBlog
venerdì 6 marzo 2009 alle 8:46 AM - firefox 3.0.7 Windows Vista
   

Assisto allibito a questo enorme dispendio di neuroni per un problema così banale.
E sogghigno pensando a WDF....e a quanto centri il bersaglio.

   
22. Gabriele
venerdì 6 marzo 2009 alle 9:09 AM - firefox 2009020409 Debian 3.0.6
   

semmai far notare quanto anche uno standard sigillato e approvato possa essere "tricky"

Non mi pare che il link provi alcunché. Fa solo vedere che il supporto allo standard è vario (e basso in IE5). Peraltro mi pare una pagina un tantinello outdated. Si parla di IE5, Mozilla 1.4, Opera 7, Netscape ... archeologia informatica

http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(CSS)

Mi sembra che buona parte dello standard CSS 2.1 sia supportato da tutti (gli sviluppatori di IE8 ne hanno fatto motivo di vanto di ciò... come a dire il supporto agli standard non è importante quando non ce l'ho e lo diventa quando ce l'ho. Tra l'altro con parole molto condivisibili... compatibilità ... interoperabilità ... si sente quando a parlare sono gli svoluppatori e quando invece è la sezione marketing)

Se il risultato è che un browser può passare l'Acid3 ma fare come ca**o gli pare con il box-model

en.wikipedia.org/.../Internet_Explorer_box_mode...

No se un browser può fare come gli pare con il box model, non passerà nessun Acid Test, manco l'1 e farà girare le scatole agli sviluppatori che dovranno scrivere tonnellate di codice solo per lui. Eh sì, 10 righe per tutti, 50 per IE6. Con lo spreco di soldi tempo e bestemmie degli sviluppatori di tutto il mondo lo correggevo io il bug di IE6. Ma non la MS ... "pensa a quanta gente ormai si è abituata a questo bug ... teniamolo"

Esagero se suppongo che il prossimo "standard" del w3c prevederà di scrivere direttamente le pagine web in assembly ?

A me, sinceramente parlando, i difensori accaniti del W3C (o WC-3 direi) cominciano sempre di più a sembrare i vescovi del vaticano. Tutti a difendere le loro teorie (religiose, per l'appunto).

www.ecma-international.org/.../...ailable_docs.htm

Hmm ma io ci vedo i WC-3 XML Schema! Vuoi vedere che la schiera dei fedeli di questa religione si sono andati espandendo anche in casa MS!!

“If a sibling block box (that does not float and is not absolutely positioned) follows the run-in box, the run-in box becomes the first inline box of the block box. A run-in cannot run in to a block that already starts with a run-in or that itself is a run-in.”

Sono 5 righe di una specifica di 100 pagine. Tra l'altro se uno sa cosa sono i block inline non è incomprensibile. Ha solo uno stile pessimo. Sei sicuro che preferisci questo qua sotto (scelto a caso a pagina 53 di 5219):

To determine if any two adjoining paragraphs should have a between border or an individual top and bottom border, the set of borders on the two adjoining paragraphs are compared. If the border information on those two paragraphs is identical for all possible paragraphs borders, then the between border is displayed.
Otherwise, each paragraph shall use its bottom and top border, respectively. If this border specifies a space attribute, that value is ignored - this border is always located at the bottom of each paragraph with an identical following paragraph, taking into account any space after the line pitch.
If this element is omitted on a given paragraph, its value is determined by the setting previously set at any level of the style hierarchy (i.e. that previous setting remains unchanged). If this setting is never specified in the style hierarchy, then no between border shall be applied between identical paragraphs.

Pensa 6000 pagine di cose così... auguri.

   
23. FDG
venerdì 6 marzo 2009 alle 11:32 AM - safari 528.16 OS X 10.5.6
   

Penso che se oggi decidessero di rifare lo standard da zero, senza nessun vincolo legacy, sarebbe molto più semplice e di facile comprensione. Lo standard attuale non è così perché si porta dietro la storia del web.

Ad esempio, io trovo facile definire le dimensioni relative di un gruppo di elementi quando si parla della larghezza. C'è qualche complicazione nell'esprimere la dimensione in percentuale perché bisogna tenere conto del riferimento usato per calcolare la dimensione. Ma trovo molti più problemi quando devo definire l'altezza degli elementi.

   
24. Scrooge McDuck
venerdì 6 marzo 2009 alle 12:08 PM - firefox 3.0.7 Windows Vista
   

No se un browser può fare come gli pare con il box model, non passerà nessun Acid Test, manco l'1 e farà girare le scatole agli sviluppatori che dovranno scrivere tonnellate di codice solo per lui. Eh sì, 10 righe per tutti, 50 per IE6. Con lo spreco di soldi tempo e bestemmie degli sviluppatori di tutto il mondo lo correggevo io il bug di IE6. Ma non la MS ... "pensa a quanta gente ormai si è abituata a questo bug ... teniamolo"

Tutto bello, ma hai linkato un bug di IE5 che in IE6 sopravvive solo nel quirks mode (don't break the internet tanto per ricordare).
Tra l'altro parlare di 10 righe per tutti e 50 per IE6 mi pare francamente eccessivo, per lo meno se ci si accontenta di avere un risultato che può essere un pelo differente e pensando già prima alle limitazioni di IE6 non bisogna poi scrivere così tanto codice in più.
E detto questo neanche supportare tutti i motori di rendering è proprio così banale e immediato (e parlo di pagine validate con il validator del w3c, non roba scritta male che potenzialmente può attivare il quirks mode).

Anche se forse il bug più bello è uno di IE che avevo beccato qualche annetto fa
img25.imageshack.us/my.php?image=firefoxw3c.png
img17.imageshack.us/my.php?image=operaw3c.png
Opera e Firefox sono simili
http://img18.imageshack.us/my.php?image=iew3c.png
In IE (non mi ricordo se era già il 7 o ancora il 6) il testo invece non è allineato (mi pare di ricordare che la causa fosse il div posta alla sinistra).
Mai capito come potesse succedere una cosa del genere...

   
25. 0verture
venerdì 6 marzo 2009 alle 1:10 PM - firefox 3.0.7 Windows XP
   

E sogghigno pensando a WDF....e a quanto centri il bersaglio.

Un motivo c'è se un giorno qualcuno s'è svegliato ed ha pensato di creare una cosa come quella.

Presa per conto suo sembra una carineria inutile ed invece, analizzando la cosa nel contesto si capisce che è molto di più.

   
26. FDG
venerdì 6 marzo 2009 alle 5:08 PM - safari 528.16 OS X 10.5.6
   

Un altro esempio di framework volto a semplificare il lavoro degli sviluppatori di applicazioni web.

Ma cosa avrebbe di particolare questo "WDF"? Al di la delle parole usate per descriverlo, non mi pare molto diverso da altri framework per applicazioni web, in particolar modo GWT.

   
27. Enrico FOLBlog
venerdì 6 marzo 2009 alle 5:40 PM - firefox 3.0.7 Windows Vista
   

@FDG

Ma cosa avrebbe di particolare questo "WDF"? Al di la delle parole usate per descriverlo, non mi pare molto diverso da altri framework per applicazioni web, in particolar modo GWT.

Come "parole usate per descriverlo"?
Link ad una demo con il codice sorgente scaricabile sono "parole"?

Non so se hai un po' di esperienza in programmazione per desktop (applicazioni stand alone) e se hai mai avuto a che fare con gli strumenti di sviluppo per desktop (Visual Studio ad esempio).
WDF consente di scrivere un'intera applicazione in C#,VB.NET,J# o Java senza preoccuparsi (ad esempio) del rendering, di cui si occupa appunto WDF.
Inoltre lo sviluppo avviene utilizzando lo stesso paradigma utilizzato per sviluppare applicazioni desktop.
In sostanza anche chi non ha mai fatto un'applicazione web in vita sua, da oggi potrebbe realizzare un'applicazione web complessa  senza dover imparare nulla di nuovo e senza dover cambiare il paradigma utilizzato per lo sviluppo.
Se non hai mai programmato per desktop, non puoi apprezzare al 100% questo aspetto. Però puoi certamente apprezzare il fatto che i problemi di rendering come quello descrito dal Papero più veloce del west, con WDF non sono più cose di cui lo sviluppatore web deve preoccuparsi: il rendering è a carico di WDF.

   
28. FDG
venerdì 6 marzo 2009 alle 5:55 PM - firefox 3.0.7 OS X 10
   

@Enrico FLOBlog

Forse non mi sono spiegato.

Non mi stai dicendo nulla di nuovo. Prendi ad esempio GWT. Mi piacerebbe conoscere quali sono le differenze tra i due framework, a parte che GWT è portato avanti da Google e il codice si scrive in Java.

Ad esempio:

public class ButtonExample implements EntryPoint {

public void onModuleLoad() {
// Make a new button that does something when you click it.
Button b = new Button("Jump!", new ClickListener() {
public void onClick(Widget sender) {
Window.alert("How high?");
}
});

// Add it to the root panel.
RootPanel.get().add(b);
}
}

Anche altri framework JavaScript, come ExtJS, qooxdoo, Dojo, YUI, usano lo stesso paradigma. Per quanto il linguaggio sia quello del client ed è necessario usare due ambienti diversi per sviluppare (problema che comunque si può risolvere).

   
29. Paperino
venerdì 6 marzo 2009 alle 6:40 PM - firefox 3.0.6 Windows 7
   

@Gabriele:

  1. non volevo fare nessuna dietrologia. Se ho tempo ti passo un po' di esempi che illustrano le differenze di rendering tra tutti i browser in cui mi son imbattuto per creare una semplice interfaccia a tab basata su liste (non chiedo mica la luna!). Non sto usando IE6 o altri browser paleolitici, sto usando IE8 che tendenzialmente si comporta abbastanza bene, bachi permettendo
  2. non capisco cosa centrino le specifiche di OOXML. Mi sto lamentando in generale del fatto che se i browser fanno un po' come ca**o gli pare e le specifiche sono scritte in quel modo riesco pure a comprenderli. Se vuoi un esempio migliore prendi quelle del formato XSD. Per interpretare alcuni costrutti, con tutta la buona volontà, avevamo bisogno di una persona dedicata.

Il sito che ho linkato è vecchio e menziona versioni antiquate di browser. Però anche facendomi un giro oggi con IE8, Firefox 3.06 e Chrome non ho trovato ancora quello che desideravo: un'interfaccia a TAB che funzionasse decentemente su tutti.

In quanto all'ACID test: il mio punto di partenza è 0, forse anche meno. Però ho scoperto che ad esempio l'ACID3 contiene test che sono sulla wish-list di alcuni disegnatori web (saranno i parrucconi? Non li conosco). Roba insomma neanche approvata! Morale della favola: il prossimo che se ne esce fuori con questo o quel browser ha fatto questo o quei punti al test ACID3 si prende una spernacchiata da me medesimo personalmente.

Prima di intavolare qualsiasi discussione "interessante" dobbiamo prima ammettere che il WEB è rotto ma funziona (quasi).

   
30. Enrico FOLBlog
venerdì 6 marzo 2009 alle 7:35 PM - firefox 3.0.7 Windows Vista
   

@FDG

WDF non traduce il codice Java o C# in javascript.
Inoltre sarebbe impossibile realizzare in quel modo un'applicazione di 500.000 righe di codice: quanti GB sarebbero, tradotti in javascript?
L'applicazione weD risiede ed è eseguita interamente lato server.
WDF utilizza js solo per inserire opportunamente nell'albero DOM le sotto porzioni HTML in arrivo dal server: il server fornisce le istruzioni su come va renderizzata la pagina; il codice js lato client (fisso) è la parte che sul client esegue queste istruzioni, modificando solo quella frazione della pagina web che risulta da cambiare.
Client e browser per WDF sono poco più di uno standard output mentre con GWT l'applicazione gira, in tutto od in parte, sul client stesso.
Quindi quando sviluppi l'applicazione con GWT è necessario aver ben in mente questa cosa altrimenti si rischia di scrivere del codice Java che poi non è traducibile in javascript.
Con WDF questo tipo di problemi non si pongono.
D'altro canto, WDF proprio per questo motivo, stressa maggiormente il server, perciò non è indicato per realizzare applicazioni web con un altissimo numero di accessi.
Queste cose rendono WDF estrememente indicato per applicazioni web complesse (tipicamente business applications desktop-like da utilizzare da remoto, magari in una intranet) oppure per realizzare sofisticatissimi backend di applicazioni il cui frontend è realizzato usando altri strumenti (vedo benissimo ad esempio l'accoppiata Silverlight / WDF).
Più l'applicazione web è complessa, più WDF è indicato.
Infine, i tempi di realizzazione di applicazioni weD con WDF sono drasticamente ridotti.

   
31. Gabriele
venerdì 6 marzo 2009 alle 7:41 PM - firefox 3.0.7 Ubuntu 8.10
   

Il problema è che il Web non è fatto come il codice di una qualunque linguaggio compilato o interpretato che ti dice solo syntax error.

Qui non è ammesso non caricare la pagina se non è valida, soprattutto se il browser più usato è storicamente molto tollerante e buggato su questo punto.

Quindi è tutto un "vabbe non ha chiuso il tag a, però dopo apre un altro tag li. Hmm forse voleva chiuderlo...". Il risultato è impredicibile e anzi dimostra quanto siano bravi e tolleranti i motori di rendering moderni.

Pensa a come sarebbe fare un compilatore C che cerchi di indovinare le intenzioni dell'autore in caso di errore di sintassi. Ti beccheresti senz'altro del folle. Ma nel web è così. (Coll'aggiunta che a volte non si dichiara nemmeno che versione della sintassi si sta usando )

Oltretutto non puoi pensare che sia facile fare un'interfaccia a tab con dentro del testo e posizionare gli elementi dando le posizioni e le misure in px ma senza prescrivere il font e il font-size.

Oltretutto se uno ingrandisce il testo della pagina va tutto a ramengo.

non capisco cosa centrino le specifiche di OOXML. Mi sto lamentando in generale del fatto che se i browser fanno un po' come ca**o gli pare e le specifiche sono scritte in quel modo riesco pure a comprenderli

Ti facevo vedere che gli standard che descrivono cose complicate sono ... complicati. Quelli del W3C non sono i peggiori anche perché almeno sono brevi...

   
32. Paperino
venerdì 6 marzo 2009 alle 9:10 PM - firefox 3.0.6 Windows 7
   

Oltretutto non puoi pensare che sia facile fare un'interfaccia a tab con dentro del testo e posizionare gli elementi dando le posizioni e le misure in px ma senza prescrivere il font e il font-size.

Ma io nell'esempio reale sono arrivato a prescrivere tutto: posizione, misure in pixel, ecc. (non nella pagina che ho copiato incollato maldestramente) eppure non ci sono riuscito. La mia domanda è: come Web designer è più importante far funzionare le cose semplici o pensare alla wish list di qualche parruccone?

   
33. FDG
venerdì 6 marzo 2009 alle 9:19 PM - safari 528.16 OS X 10.5.6
   

@Enrico FOLBlog

Ho capito. Mi pare di capire che, a parte gli elementi grafici, il DOM, WDF non abbia alcuna logica sul browser. Cioè, manco il controller, tanto per intenderci. Ma se creo nuovi widget, la logica del widget come viene fatta e dove è collocata?

Già che ci sono, ti do qualche dato sul progetto che ho seguito io.

Ho fatto un calcolo rapido e l'applicazione che ho sviluppato io dovrebbe avere 22398 righe di codice java. Non è tutto codice d'interfaccia e non risiede tutto sul browser.

Sul browser ci sono view e controller; sono 5187 righe java, e 25111 righe js impacchettate nel jar, ma sicuramente non sono tutte righe scaricate dal browser perché GWT genera diverse versioni del codice per i diversi browser e a questo va aggiunto il codice js di GWT. Il codice generato dal compilatore è molto compatto, anzi... offuscato.

La logica applicativa risiede sul server. Per estensione il codice server side include anche altri servizi a cui mi appoggio. Il confine tra codice client e codice server lo stabilisco esplicitamente io sia distribuendo le varie classi in diversi package, sia decidendo dove vanno messe le chiamate RPC. Anzi, una cosa che mi dispiace è che al momento si debba usare il protocollo RPC di GWT. Mentre preferirei che l'applicazione fosse un client che accede a servizi esposti tramite un protocolo più diffuso, come ad esempio soap. Non c'è un supporto soap in GWT (non so quanto sia fattibile). Al contrario è supportato json.

   
34. NickelGreen
venerdì 6 marzo 2009 alle 10:20 PM - IE 7.0 Windows Vista
   

Morale della favola: il prossimo che se ne esce fuori con questo o quel browser ha fatto questo o quei punti al test ACID3 si prende una spernacchiata da me medesimo personalmente.

E ANCHE DA ME!!!

   
35. Enrico FOLBlog
sabato 7 marzo 2009 alle 10:20 AM - firefox 3.0.7 Windows Vista
   

@FDG

Ho capito. Mi pare di capire che, a parte gli elementi grafici, il DOM, WDF non abbia alcuna logica sul browser.
Cioè, manco il controller, tanto per intenderci.

Esattamente.

Ma se creo nuovi widget, la logica del widget come viene fatta e dove è collocata?

Spiegami meglio cosa intendi per nuovi widget.
Intendi nuove applicazioni (seppur di dimensioni ridottissime) oppure nuovi controlli (una nuova grid, o una nuova window/form diversa da quelle che hai visto nella demo) oppure una classe nuova?

Nel primo caso, semplicemente scrivi l'applicazione.
Mentre nel secondo caso, cioè l'aggiunta di nuovi controlli attualmente non presenti (ad esempio c'è una prima bozza di un controllo per disegnare forme collegabili con delle frecce direzionali), al momento è acarico di chi il framework l'ha realizzato.

Ho fatto un calcolo rapido e l'applicazione che ho sviluppato io dovrebbe avere 22398 righe di codice java. Non è tutto codice d'interfaccia e non risiede tutto sul browser.

Una precisazione che credo importante.
Ho parlato di 500.000 righe di codice non per sparare un numero alto a caso, ma perchè è realmente la dimensione di una delle applicazioni che, chi ha ideato il framework, ha realizzato per conto di clienti e che da circa un anno è in uso.
Quanti KB occorre scaricare per avviare la tua applicazione?
Perchè una delle preoccupazioni di qualcuno è stata che quelli necessari per eseguire la demo (che sono praticamente gli stessi, qualunque applicazione si crei), sono troppi....

Anzi, una cosa che mi dispiace è che al momento si debba usare il protocollo RPC di GWT. Mentre preferirei che l'applicazione fosse un client che accede a servizi esposti tramite un protocolo più diffuso, come ad esempio soap

GWT mi pare supporti un simple RPC. Ma spesso l'interazione con r con gli oggetti di business. non è così semplice come potrebbe sembrare ed un modello sullo stile RMI (quello utilizzato da WDF) non è il massimo in tutte le situazioni.
Perciò anche in WDF si è fatta la scelta del male minore.
A naso, però, mi pare che WDF continui ad essere utile anche dove GWT si ferma (per una ragione o per l'altra).

Ad esempio, mi piacerebbe capire se con GWT sia possibile realizzare tutto ciò che è stato già realizzato con WDF e che è illustrato nella demo.
Popup (che interrompono l'esecuzione del codice fino a quanto l'utente non fa una scelta) e dockbar, per farti solo due esempi che ho visto tirar fuori spesso da Davide, colui che ha ideato il framework.

Non conosco json.
Ma non perdere mai di vista una cosa (che è quella che mi fa ritenere rivoluzionario il framework): per scrivere un'applicazione weD, non devi sapere nulla ne' di javascript, ne' di HTML, ne' di PHP ne' d'altri strumenti.
In sintesi, realizzi applicazioni web complesse (e sottolineo complesse, non paginette web), senza sapere nulla di sviluppo web!
Questo eprchè non hai proprio nessuna necessità di metter mano a niente che non sia la logica pura dell'applicazione.
Il tutto senza che sia necessario installare nel client nulla, niente di niente: basta un browser compatibile HTML4 (per ora; quando diverrà opportuno, il passaggio a XHTML sarà una bazzeccola, e nessuna applicazione andrà riscritta!) e js.
A tutto il resto (che è tutto quel che genera problemi nello sviluppo web) ci pensa WDF.

Tieni presente che WDF, nonostante sia utilizzato da oltre un anno per la realizzazione di applicazioni web complesse che girano regolarmente con grande soddisfazione di chi le usa, è da considerare poco più che un prototipo, ben fatto, funzionante ma con margini di miglioramento.
Ad esempio, al momento sono stare realizzate delle ottimizzazioni per ciascun controllo, ma manca un meccanismo generale di "caching" automatic, dato che questo andrebbe completamente ripensato. Ci si sta lavorando.

Mi puoi far avere qualche link a web application (paradonabili alla demo) realizzate con GWT?
Sto studiando il modo di realizzare un plugin per Moodle in modo da integrare applicazioni per la gestione di mappe concettuali (CmapTools), possibilmente senza che sia necessaria l'installazione di alcun plugin/activex o software lato client; WDF andrebbe benissimo (la bozza del designer grafico l'hanno realizzata per me ) ma devo capire se esistono alternative che, in questo caso, possono essere utilizzate con altrettanto profitto.



   
36. FDG
sabato 7 marzo 2009 alle 11:08 AM - safari 528.16 OS X 10.5.6
   

@Enrico FOLBlog

Mentre nel secondo caso, cioè l'aggiunta di nuovi controlli attualmente non presenti (ad esempio c'è una prima bozza di un controllo per disegnare forme collegabili con delle frecce direzionali), al momento è acarico di chi il framework l'ha realizzato.

È il secondo caso. A me serve poter definire widget (controlli) miei. Quindi, sottoclassi di una classe Widget (o equivalente).

Ho parlato di 500.000 righe di codice non per sparare un numero alto a caso, ma perchè è realmente la dimensione di una delle applicazioni che, chi ha ideato il framework, ha realizzato per conto di clienti e che da circa un anno è in uso.

Una bella cifra. Però come ti ho scritto in realtà la mia applicazione è solo un front-end ad un sistema più complesso. Cioè, c'è il codice d'interfaccia e codice server side che fa da proxy verso altri servizi.

Quanti KB occorre scaricare per avviare la tua applicazione?

Pochi... misurerò e ti farò sapere.

Perchè una delle preoccupazioni di qualcuno è stata che quelli necessari per eseguire la demo (che sono praticamente gli stessi, qualunque applicazione si crei), sono troppi.

Non penso che sia un problema così complesso.

Questo è un demo di GWT Mosaic, una libreria di widget per GWT:

http://69.20.122.77:8880/gwt-mosaic/Showcase.html - svn

69.20.122.77/gwt-mosaic-current/Showcase.html - stable

Questo è il demo di GWT Ext:

http://www.gwt-ext.com/demo/

Smart GWT, basata su SmartClient:

http://code.google.com/p/smartgwt/

Il demo di SmartClient è sul sito del progetto.

Ci sono altre librerie che sono state integrate in GWT. Io stesso ho iniziato, più per fare un test, una integrazione tra YUI e GWT. Non ho mai proseguito perché preferisco framework "nativi" come GWT Mosaic.

In sintesi, realizzi applicazioni web complesse (e sottolineo complesse, non paginette web), senza sapere nulla di sviluppo web!

Manco con GWT e non è l'unico framework che non ti costringe ad imparare nulla del web, per quanto io pensi che convenga comunque farlo.

   
37. FDG
sabato 7 marzo 2009 alle 11:11 AM - safari 528.16 OS X 10.5.6
   

p.s.: 500.000 righe di codice d'interfaccia? Non penso. È TANTO.

   
38. Enrico FOLBlog
sabato 7 marzo 2009 alle 12:05 PM - firefox 3.0.7 Windows Vista
   

@FDG

500.000 righe di codice applicazione.

A me serve poter definire widget (controlli) miei. Quindi, sottoclassi di una classe Widget (o equivalente).

OK.
Dato che gli oggetti WDF implementano l'ereditarietà, puoi istanziare quante sottoclassi vuoi e fare overriding dei metodi.
Inoltre, l'aggiunta di componenti figli ad una form, ad esempio, può essere fatta sia in modalità statica, sia in modalità dinamica, ad esempio leggendo le informazioni di layout da un file xml.
Inoltre alcuni widget sono superflui, nel senso che fanno già parte integrante di un altro controllo.
Prendi ad esempio il data picker: ovunque si richieda l'inserimento di una data è reso disponibile senza però che esista un "widget" ad hoc.
Per esempio prova a modificare una data nella grid demo.

Se invece vuoi creare un nuovo controllo inesistente, per il quale cioè non esiste una classe da cui ereditare, allora al momento lo può creare solo chi ha realizzato il fw.

Se invece ti ho ancora frainteso, per capirci, fammi un esempio pratico di un controllo che vorresti implementare e che non trovi nella demo.

Non penso che sia un problema così complesso.

Sulle dimensioni del codice da scaricare, la penso come te.

Ho dato uno sguardo alle demo che mi hai proposto.
Con WDF siamo su un altro pianeta!
Ad esempio la grid  (table) è unica, non c'è distinzione tra siple, sroll e paging scroll table.
Ho provato a creare una table di 50000 row, come è proposta nella demo WDF: risultato ottenuto in 101035 millisecondi senza alcun feedback sull'avanzamento.

   
39. Enrico FOLBlog
sabato 7 marzo 2009 alle 2:28 PM - firefox 3.0.7 Windows Vista
   

@FDG

non so più scrivere

"non c'è distinzione tra siple, sroll e paging scroll"

"non c'è distinzione tra simple, scroll e paging scroll"

   
40. FDG
lunedì 9 marzo 2009 alle 2:41 PM - safari 528.16 OS X 10.5.6
   

@Enrico FOLBlog

Dato che gli oggetti WDF implementano l'ereditarietà, puoi istanziare quante sottoclassi vuoi e fare overriding dei metodi.

Ok. Mi chiedo però: per poter definire widget custom devo avere un qualche modo per descrivere come questi widget saranno implementati. Quindi, o il DOM, i css e quant'altro sono visibili all'occorrenza, oppure vengono visti come implementazione di un altro modello. Oppure, è solo possibile aggregare i controlli previsti.

Ho dato uno sguardo alle demo che mi hai proposto...

Premetto che non ho usato GWT Mosaic, che è solo una libreria di Widget. Ma appunto è una libreria, quindi se qualche widget non soddisfa si può sempre usarne un altro e al limite decidere di crearne uno o di modificarne uno esistente, condividendo il risultato (è un widget!).

   
41. FDG
lunedì 9 marzo 2009 alle 2:42 PM - safari 528.16 OS X 10.5.6
   

p.s.: comunque, grazie delle informazioni.

   
42. Enrico FOLBlog
lunedì 9 marzo 2009 alle 4:14 PM - firefox 3.0.7 Windows Vista
   

@FDG

WDF mette a disposizione una sua struttura logica dei controlli con legami tra figli e padri e questa visione è ad un livello di astrazione molto più elevato rispetto a DOM o CSS.
Questo consente di costruire tantissimi controlli a partire dagli elementi base che WDF mette a disposizione.
Ad esempio, già la Dockbar è possibile ricostruirla utilizzando gli elementi a disposizione.
Per altri controlli più complessi, invece, cioè per costruire altri elemnti di base, è necessario l'intervento di chi ha realizzato il framework.
Ad esempio il controllo che permette di inserire la mappa di Google nell'applicazione, non sarebbe stato possibile realizzarlo senza un intervento alle fondamenta, perchè in quel caso si rendeva  necessario chiamare alcune API di Google da JS e dato che WDF non da' accesso a JS la cosa diventava complicata.

Ma alla fine che te ne pare di WDF?

   
43. FDG
martedì 10 marzo 2009 alle 6:25 PM - safari 528.16 OS X 10.5.6
   

@Enrico FOLBlog

WDF mette a disposizione una sua struttura logica dei controlli con legami tra figli e padri e questa visione è ad un livello di astrazione molto più elevato rispetto a DOM o CSS.

Ricorda il Composite di GWT. Cioè, è possibile comporre Widget più semplici in Widget complessi. Alcuni Widget di GWT fungono da container e possono includerne altri. Nel Composite è sufficiente creare un contenitore e impostarlo come Widget root del Composite. Rispecchia la struttura DOM perché i Widget di GWT sono associati ad Elements del DOM.

Ma alla fine che te ne pare di WDF?

Sulla qualità del framework non posso dire nulla non avendolo mai usato. Ma come ti ho detto prima, non è il primo framework pensato per scrivere applicazioni web senza preoccuparsi dei dettagli implementativi. L'utilità di questi framework secondo me più che nel non avere a che fare con html, css e dom è nella possibilità di usare lo stesso linguaggio, la stessa sintassi, la stessa descrizione dell'Object Model sia per l'intefaccia che per la logica applicativa. Mentre non mi interessa ignorare il modo in cui l'interfaccia viene realizzata. Per me il livello d'astrazione più che nascondere completamente ciò che c'è sotto deve essere un supporto per poter usare più agevolmente le tecnologie del web. A me non dispiace aver a che fare con DOM, css, JavaScript, html e tutte le tecnologie messe a disposizione dal browser. Se questo può essere fatto più agevolmente, mi va anche bene. Per capirci faccio un esempio: ad ogni Widget c'è associato un Element DOM. Quindi, il Widget implicitamente ha associati gli attributi dell'Element. Quindi, l'attributo "class" dell'Element è anche l'attributo class del Widget. Però quando realizzo un Widget definisco una classe con membri (proprietà e metodi) pubblici e privati, cosa che usando solo JavaScript e DOM non è immediato. Questo è particolarmente comodo non solo quando si vogliono realizzare controlli custom, ma anche per usare librerie JavaScript esistenti (es.: JQuery, Ext, SmartClient e così via) o per supportare standard del web come i microformats.

   
44. Enrico FOLBlog
martedì 10 marzo 2009 alle 8:13 PM - firefox 3.0.7 Windows Vista
   

@FDG

è possibile comporre Widget più semplici in Widget complessi. Alcuni Widget di GWT fungono da container e possono includerne altri.

Se per "widget più semplice" intendi anche la singola scroll bar o il singolo pulsante, allora WDF e GWT consentono di fare la stessa  cosa riguardo a questo aspetto.

A me non dispiace aver a che fare con DOM, css, JavaScript, html e tutte le tecnologie messe a disposizione dal browser.

Beh, certo. A qualcun altro non dispiacerà utilizzare PHP, Ruby, Silverlight o altri strumenti.
Ma poi se vuoi sviluppare un'applicazione per desktop, tutto quel bagaglio di conoscenze lo puoi anche gettare a mare e devi possedere altri skills.
Con WDF invece le competenze di un settore sono valide anche nell'altro...perchè son le stesse

Il processo di sviluppo software è un processo industriale come un altro.
Perciò se uno strumento è in grado di abbreviare notevolmente il tempo necessario alla produzione, a mio parere, DEVE essere adottato, pena accumulare un ritardo sulla concorrenza.

WDF oltre a rendere realizzabili applicazioni che altrimenti non lo sarebbero (per gli inostenibili tempi di risposta, ad esempio), accorcia i tempi di produzione e, particolare non da poco, semplifica la manutenzione successiva.

Purtroppo, se non si ha presente il processo e di sviluppo di un'applicazione desktop (molto, molto diverso da quello relativo ad un'applicazione web, almeno fino ad ora), è difficile apprezzare l'importanza che riveste il fatto che WDF eguagli i due paradigmi.

Con WDF, adottando particolari attenzioni si può arrivare a realizzare un'applicazione che poi può essere compilata per funzionare sul web o su un desktop in locale.
Il codice sorgente sarebbe lo stesso e verrebbe compilato una volta in modo da prevedere un utilizzo locale (applicazione desktop) e un'altra l'uso da remoto (applicazione web).
In sostanza, sarebbe possibile commercializzare la stessa applicazione come applicazione desktop, o come applicazione web ma anche come SaaS (Software as a Service): il tutto avendo un unico reparto, un unico team di sviluppo.
Questi vantaggi, che il larga scala significano risparmi colossali, sono a mio avviso tali che converrebbe gettarsi a corpo morto a perfezionare il framework in modo da colmarne le lacune che potrebbero rivelarsi come un potenziale ostacolo.
Infatti, mentre framework come GWT, pur essendo già una soluzione molto evoluta, non mi pare abbiano potenzialità di sviluppo molto superiori alle attuali (data l'architettura), WDF ottiene gli stessi risultati essendo appena nato, con potenzialità di evoluzione a mio modo di vedere enormi.

P.S.

In un commento precedente ho parlato del controllo per inserire una mappa di Google in un'applicazione e solo dopo mi son reso conto che nella demo non è stato inserito...

Inoltre, sempre rileggendo un commento precedente, mi sembra sia necessario precisare che WDF consente di istanziare oggetti utilizzando anche Soap, volendo.

   
45. FDG
mercoledì 11 marzo 2009 alle 11:59 AM - safari 528.16 OS X 10.5.6
   

@Enrico FOLBlog

Il processo di sviluppo software è un processo industriale come un altro. Perciò se uno strumento è in grado di abbreviare notevolmente il tempo necessario alla produzione, a mio parere, DEVE essere adottato, pena accumulare un ritardo sulla concorrenza.

Sono d'accordo. Quando parlo di "supporto" intendo proprio qualcosa che ti semplifica lo sviluppo. Cioè, il framework è modellato rispecchiando il problema che deve affrontare: costruzione di interfacce desktop-like. Però se questo viene fatto anche adeguandosi alla struttura del livello sottostante, esponendola quando può essere utile, c'è la possibilità di sfruttarla a proprio vantaggio quando l'astrazione di livello superiore è insufficiente, inadeguata. Una cosa che purtroppo capita. E quando capita...

Con WDF, adottando particolari attenzioni si può arrivare a realizzare un'applicazione che poi può essere compilata per funzionare sul web o su un desktop in locale.

Ok, questa è una cosa che m'era sfuggita. Out of the box è già possibile fare così senza giri strani. Anche questa non è una caratteristica esclusiva perché mi vengono in mente vari modi di ottenere lo stesso risultato programmando per il web, per quanto non mi aspetto con la stessa immediatezza che tu mi fai capire abbia WDF.

Però, si parla di necessità particolari: l'applicazione deve essere distribuita sia sul web che come applicazione stand-alone; l'azienda che adotta lo strumento sviluppa sia applicazioni web che stand-alone.mentre framework come GWT, pur essendo già una soluzione molto evoluta, non mi pare abbiano potenzialità di sviluppo molto superiori alle attuali (data l'architettura)

Io ne vedo diverse. Dall'hosted mode come modalità di deploy, al supporto di altre sintassi, alla compilazione a partire dal bytecode, all'integrazione di tecnologie proprie del web in modo naturale...

   
46. FDG
mercoledì 11 marzo 2009 alle 12:00 PM - safari 528.16 OS X 10.5.6
   

p.s.: Ho fatto un po di casino col quoting.

   
47. FDG
giovedì 12 marzo 2009 alle 2:55 PM - safari 528.16 OS X 10.5.6
   

Comunque, si possono fare tanto discorsi, ma alla prova pratica il browser che più rompe le palle è IE. Fai una cosa, 80% dei casi i problemi li da Explorer. Esattamente ora, sto giocando col posizionamento assoluto e GWT. Firefox, Safari, Opera, Chrome, sia su Windows che su Mac, danno esattamente lo stesso risultato. Indovinati qual è il browser che invece si fa i cazzi suoi? E perché? Boh! Ora mi tocca perdere tempo solo perché c'è ancora un sacco di gente che non l'ha cestinato.

E poi mi devo vedere il papero che fa certi post per dimostrare tesi che non stanno ne in cielo ne in terra. Mi viene pure da pensare che in questo momento il web senza Explorer sarebbe un posto migliore.

   
48. Enrico FOLBlog
giovedì 12 marzo 2009 alle 3:30 PM - firefox 3.0.7 Windows Vista
   

@FDG

Con WDF è il contrario: funziona tutto con IE, Safari, Chrome, mentre ci son problemi con Firefox e Opera

   
49. Paperino
giovedì 12 marzo 2009 alle 4:24 PM - firefox 3.0.7 Windows Vista
   

E poi mi devo vedere il papero che fa certi post per dimostrare tesi che non stanno ne in cielo ne in terra.

Capisco la frustrazione di quando le cose non funzionano come dovrebbero. Ma non capisco perché arrivi a dire che la mia tesi non sta ne in cielo ne in terra: la mia tesi è di una banalità sconvolgente. Con il CSS puro (senza giochetti strambi) è impossibile ottenere un effetto di navigazione a TAB che funzioni sull'ultima versione di tutti i browser. Mi ero illuso che questa implementazione funzionasse con tutti ma non è così. Per smontare la tesi basterebbe un controesempio. Sistemate le cose semplici si potrà pensare a quelle più complicate.

   
[ Pagina 1 di 2  - più vecchi ]
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)