la soluzione che penso di adottare per evitare tutte le cose dolorose di ieri sera se comincio a giocare con XSLT sul client:
creazione di XML da script perl con un modulo CPAN (qual è il migliore?)
traduzione XML-->XLST sul server con PHP, ritorno di una risposta in HTML formattata in CSS. Questo però introduce una dipendenza tra CSS e XLST che però presumo non sia troppo grave. per questo ci vogliono apposite librerie PHP (powered by Sablotron)
lunedì 26 novembre 2007
domenica 25 novembre 2007
feel the PAIN #1 (nel senso francese)
eccomi con i miei primi problemi di cross-browser compatibility (ovviamente sono indietro con la schedule perché tutti i tutorial che volevo fare avevano tutorial prerequisiti, ma la notte è giovane).
xPath, bel linguaggio di navigazione in XML, è implementato MOLTO diversamente in IE e in Mozilla&co.
per selezionare una lista di nodi:
xmlDoc.selectNodes(path expression) in IE
in Firefox bisogna fare un oggetto XPathEvaluator: dal sito http://www.wrox.com/WileyCDA/Section/id-291861.html
This example uses the XPathResult.ORDERED_NODE_ITERATOR_TYPE result, which is the most commonly used result type. If no nodes match the XPath expression, evaluate() returns null; otherwise, it returns an XPathResult object. If the result is a node iterator, whether it be ordered or unordered, you use the iterateNext() method repeatedly to retrieve each matching node in the result. When there are no further matching nodes, iterateNext() returns null.
var oEvaluator = new XPathEvaluator();
var oResult = oEvaluator.evaluate("employee/name",
oXmlDom.documentElement, null,
XPathResult.ORDERED_NODE_ITERATOR_TYPE, null);
if (oResult != null) {
var oElement = oResult.iterateNext();
while(oElement) {
alert(oElement.tagName);
oElement = oResult.iterateNext();
}
}
L'articolo continua spiegando che si possono fare funzioni aggiuntive per Element per poter usare la stessa sintassi. E' un po'complicato though, speriamo che non serva - in mancanza di tempo vado avanti tenendo buona la referenza.
xPath, bel linguaggio di navigazione in XML, è implementato MOLTO diversamente in IE e in Mozilla&co.
per selezionare una lista di nodi:
xmlDoc.selectNodes(path expression) in IE
in Firefox bisogna fare un oggetto XPathEvaluator: dal sito http://www.wrox.com/WileyCDA/Section/id-291861.html
This example uses the XPathResult.ORDERED_NODE_ITERATOR_TYPE result, which is the most commonly used result type. If no nodes match the XPath expression, evaluate() returns null; otherwise, it returns an XPathResult object. If the result is a node iterator, whether it be ordered or unordered, you use the iterateNext() method repeatedly to retrieve each matching node in the result. When there are no further matching nodes, iterateNext() returns null.
var oEvaluator = new XPathEvaluator();
var oResult = oEvaluator.evaluate("employee/name",
oXmlDom.documentElement, null,
XPathResult.ORDERED_NODE_ITERATOR_TYPE, null);
if (oResult != null) {
var oElement = oResult.iterateNext();
while(oElement) {
alert(oElement.tagName);
oElement = oResult.iterateNext();
}
}
L'articolo continua spiegando che si possono fare funzioni aggiuntive per Element per poter usare la stessa sintassi. E' un po'complicato though, speriamo che non serva - in mancanza di tempo vado avanti tenendo buona la referenza.
ieri&oggi
ieri:
-Il tabbed browsing con le librerie trovate non funziona con i widget di NetVibes (almeno la seconda tab). Will look into that if & only if c'è bisogno di usare netVibes, perché con qualunque altra pagina html funziona (e presumo quindi anche con miei wrapper dei PlottingTools)
-Scritta la documentazione di base e inquadramento del problema
oggi:
-finire tutti i tutorial (mattina)
-cominciare a lavorare su LSF box = sample widgetBox da script
-definire convenzione tag XML per informazioni che vengono da perl script
-script dovrà avere output XML
-definire convenzione tag XML per config file
-ajaxificare (refresh: 10')
-css positioning (leggere tutorial prima)
chiave di tutto: parser XML!!!
-Il tabbed browsing con le librerie trovate non funziona con i widget di NetVibes (almeno la seconda tab). Will look into that if & only if c'è bisogno di usare netVibes, perché con qualunque altra pagina html funziona (e presumo quindi anche con miei wrapper dei PlottingTools)
-Scritta la documentazione di base e inquadramento del problema
oggi:
-finire tutti i tutorial (mattina)
-cominciare a lavorare su LSF box = sample widgetBox da script
-definire convenzione tag XML per informazioni che vengono da perl script
-script dovrà avere output XML
-definire convenzione tag XML per config file
-ajaxificare (refresh: 10')
-css positioning (leggere tutorial prima)
chiave di tutto: parser XML!!!
venerdì 23 novembre 2007
prototype
Per cambiare un pochino sto imparando a fare i tabs in prototype - così si spera entro stasera di implementare sulla pagina di test almeno le due applets di phedEx utilizzando netVibes. Domani sperando di essere meno stanchi si finiscono i tutorial e domenica/lunedì si comincia a scrivere un po'di vera pagina (wishful thinking!)
Sto ancora cercando un editor html decente. Scartato Kompozer (tag in maiuscolo??????) ho provato Quanta ma crasha spesso. Proverò Bluefish.
Sto ancora cercando un editor html decente. Scartato Kompozer (tag in maiuscolo??????) ho provato Quanta ma crasha spesso. Proverò Bluefish.
giovedì 22 novembre 2007
w3cschools
nice & easy tutorials on:
CSS
XHTML
JAVASCRIPT
DOM
XML
www.w3schools.com. Non particolarmente ben scritti, ma apprezzo il fatto che si possa andare a smanettare sul codice in un editor appropriato. Considerati lettura preliminare di orientamento al libro di AJAX&javascript & utilizzo di varie librerie. Da fare entro domani:
XSL
XSLT
XQuery
DTD
PHP
AJAX
Progetti per il fine settimana: YUI & Prototype, qualche pagina di test.
CSS
XHTML
JAVASCRIPT
DOM
XML
www.w3schools.com. Non particolarmente ben scritti, ma apprezzo il fatto che si possa andare a smanettare sul codice in un editor appropriato. Considerati lettura preliminare di orientamento al libro di AJAX&javascript & utilizzo di varie librerie. Da fare entro domani:
XSL
XSLT
XQuery
DTD
PHP
AJAX
Progetti per il fine settimana: YUI & Prototype, qualche pagina di test.
mercoledì 21 novembre 2007
utilisssssimi consigli
cambio di rotta e fine del GWT+Tomcat. Motivazioni (che andranno nel report di metà tirocinio quindi tanto vale che le scriva qui):
Il Google Web Toolkit ha il vantaggio di poter compilare javascript a partire da codice java. Esistono però alcuni svantaggi concernenti la futura mantenibilità del progetto:
-il javascript "offuscato" prodotto dalla compilazione del java originale è praticamente impossibile da controllare e correggere in caso di errori di funzionamento
-non c'è la possibilità di intervenire sul flusso di lavoro ajax - approccio 'black box' nel caso delle chiamate asincrone
-servlet e Tomcat: rischio di utilizzare strumenti troppo complicati (con curva di apprendimento ripida) per un design sostanzialmente semplice
(altro?)
Ora si aprono alcune strade - ho parlato con un paio di responsabili dei WebTools e ho concluso che (wish list!)
a. imparerò il javascript (avevo già iniziato, e 2 ore al giorno sui mezzi sono utili e rilassanti)
b. curioserò nelle librerie Prototype, Scriptaculous, YUI
c. installerò Bonsai (il framework CMS per i webtools) per vedere come funziona, ma anche questo rischia di complicare le cose (python per i web applets potrebbe non servire).
d. continuerò a fare tutorial XML perché mi è stato suggerito XLST come la soluzione a molti dei nostri problemi, traduce XML in altro (HTML magari!) secondo dei fogli di stile predefiniti
e. userò php (e basta!) per interfacciarmi a Redacle
f. userò script perl (Nazgul) per chiedere le informazioni più elaborate e.g. LSF
g. capirò come recuperare (via web) le informazioni di Ganglia
h. userò i GraphTools hopefully as-is (javascript, no?) per PhedEx
Il Google Web Toolkit ha il vantaggio di poter compilare javascript a partire da codice java. Esistono però alcuni svantaggi concernenti la futura mantenibilità del progetto:
-il javascript "offuscato" prodotto dalla compilazione del java originale è praticamente impossibile da controllare e correggere in caso di errori di funzionamento
-non c'è la possibilità di intervenire sul flusso di lavoro ajax - approccio 'black box' nel caso delle chiamate asincrone
-servlet e Tomcat: rischio di utilizzare strumenti troppo complicati (con curva di apprendimento ripida) per un design sostanzialmente semplice
(altro?)
Ora si aprono alcune strade - ho parlato con un paio di responsabili dei WebTools e ho concluso che (wish list!)
a. imparerò il javascript (avevo già iniziato, e 2 ore al giorno sui mezzi sono utili e rilassanti)
b. curioserò nelle librerie Prototype, Scriptaculous, YUI
c. installerò Bonsai (il framework CMS per i webtools) per vedere come funziona, ma anche questo rischia di complicare le cose (python per i web applets potrebbe non servire).
d. continuerò a fare tutorial XML perché mi è stato suggerito XLST come la soluzione a molti dei nostri problemi, traduce XML in altro (HTML magari!) secondo dei fogli di stile predefiniti
e. userò php (e basta!) per interfacciarmi a Redacle
f. userò script perl (Nazgul) per chiedere le informazioni più elaborate e.g. LSF
g. capirò come recuperare (via web) le informazioni di Ganglia
h. userò i GraphTools hopefully as-is (javascript, no?) per PhedEx
domenica 18 novembre 2007
RequestSWVersion
In questo caso non c'è un perl di mezzo, basta un ls nella directory dove sappiamo essere il sw. Non dovrebbe essere un problema eseguire comandi dal servlet, perché il codice del servlet non è visibile dal client. Ma questo è da controllare per non lanciare eccezioni in giro.
RequestInfoRedacle
Richiesta di informazioni a Redacle: 2 possibilità (cambia una relazione)
1. il codice client pesca un file xml che viene prodotto da un cron-ed script in perl che fa le query a Redacle
2. il servlet triggera lo script in perl che fa le query a Redacle, poi la gestione dell'xml è la stessa
NB: SEMPRE last modified tag...
Possibili problemi:
1. il file xml sta in scrittura e la pagina va a pescarsi roba mezza mangiucchiata - soln: tenere due copie? ma il problema si ripresenta...da chiedere!
2. non è che tutti gli utenti chiedono di riscrivere il file! viene un casino se due utenti chiedono di riscrivere l'xml contemporaneamente. Quindi meglio il push per semplicità...evitare la possibilità di refresh.
3. take care per la cancellazione/(sovrascrittura?) dei vecchi file, altrimenti si riempie il disco...
XML Parse&Translate
L'idea è di mantenere il parser/traduttore in un'unica classe, che però deve venire implementata in maniera diversa a seconda di cosa deve fare. (Abstract factory pattern probabilmente, v. http://en.wikipedia.org/wiki/Abstract_factory_pattern).
domenica al computer
_pezzo del potenziale report che di qualche ora dovrò anche fare. il report di metà tirocinio descrive le tecnologie&il problema + use case, il report finale descrive l'implementazione_
DIZIONARIO:
web applet = il box
servlet = applicazione java che lavora sul server (non viene tradotta in js da gwt, mi sembra) - definizione recuperata da webopedia: A small program that runs on a server. The term usually refers to a Java applet that runs within a Web server environment. This is analogous to a Java applet that runs within a Web browser environment.
L'idea è di disaccoppiare le richieste del server alla farm dalla visualizzazione in gwt. Si evita in questo modo di avere un codice java complicato e difficile da mantenere a causa delle dipendenze dalla struttura di database e dei servizi connessi (LSF, PhedEx, Ganglia) e si possono generalizzare più facilmente le classi da utilizzare. Quindi il flusso di lavoro per la generica applet è
Uno script perl (cron) produce un file xml con le informazioni desiderate.
Il codice client (scritto in GWT, java) fa una richiesta al server - il servlet quindi recupera il file xml prodotto dallo script perl, lo restituisce al codice client (classe parser + visualizzatore EntryPoint) che lo traduce e lo visualizza.
nota:
ORA, il problema sta nella definizione di asincrono - le varie web applet devono essere asincrone TRA DI LORO, altrimenti abbiamo una pagina statica che pesca file di testo. nel codice java del servlet dovrei poter anche chiamare lo script perl indipendentemente l'uno dall'altro. Non è che questo porta a problemi di sicurezza?
possibile soluzione: aggiungere una specie di listener triggerata dalla data del file xml - quando il file xml cambia viene anche rinfrescata la web applet. (problemi di data/ora? non dovrebbero essercene, visto che gira tutto sul server e sarà tutto fornito in termini di data-ora di Roma)
TODO per oggi:
magicdraw use case diagram
pensare allo script perl che interroga il db
scrivere codice gwt per la scatola di info quasistatiche come se fosse l'unico box nella pagina
capire xml&java (SAX)
TODO per domani:
chiedere a GO
-installazione gwt, tomcat
-utente su db per lo script perl
-cron per lo script perl (apache può farlo)
DIZIONARIO:
web applet = il box
servlet = applicazione java che lavora sul server (non viene tradotta in js da gwt, mi sembra) - definizione recuperata da webopedia: A small program that runs on a server. The term usually refers to a Java applet that runs within a Web server environment. This is analogous to a Java applet that runs within a Web browser environment.
L'idea è di disaccoppiare le richieste del server alla farm dalla visualizzazione in gwt. Si evita in questo modo di avere un codice java complicato e difficile da mantenere a causa delle dipendenze dalla struttura di database e dei servizi connessi (LSF, PhedEx, Ganglia) e si possono generalizzare più facilmente le classi da utilizzare. Quindi il flusso di lavoro per la generica applet è
Uno script perl (cron) produce un file xml con le informazioni desiderate.
Il codice client (scritto in GWT, java) fa una richiesta al server - il servlet quindi recupera il file xml prodotto dallo script perl, lo restituisce al codice client (classe parser + visualizzatore EntryPoint) che lo traduce e lo visualizza.
nota:
ORA, il problema sta nella definizione di asincrono - le varie web applet devono essere asincrone TRA DI LORO, altrimenti abbiamo una pagina statica che pesca file di testo. nel codice java del servlet dovrei poter anche chiamare lo script perl indipendentemente l'uno dall'altro. Non è che questo porta a problemi di sicurezza?
possibile soluzione: aggiungere una specie di listener triggerata dalla data del file xml - quando il file xml cambia viene anche rinfrescata la web applet. (problemi di data/ora? non dovrebbero essercene, visto che gira tutto sul server e sarà tutto fornito in termini di data-ora di Roma)
TODO per oggi:
magicdraw use case diagram
pensare allo script perl che interroga il db
scrivere codice gwt per la scatola di info quasistatiche come se fosse l'unico box nella pagina
capire xml&java (SAX)
TODO per domani:
chiedere a GO
-installazione gwt, tomcat
-utente su db per lo script perl
-cron per lo script perl (apache può farlo)
sabato 17 novembre 2007
paralisi da analisi
Sto cercando nel mucchio del twiki di capire qualcosa di come funzionano i plotting tools per phedex, ma sono giunta alla conclusione che dovrò scrivere allo sviluppatore perché 'include the relevant js file' è un po'generico. meanwhile, il tabbed browsing con 80 finestre di acrobat aperte mi sta facendo perdere un sacco di tempo ma anche capire qual è il problema: troppe informazioni in troppi punti diversi. Il problema è che se io continuo a voler aggiungere informazioni mi posso anche perdere a vedere gli N modi in cui i vari gruppi di informazioni vengono estratte (es. dashboard-->SAM visualization, sito phedex, ganglia...) quindi forse the safest bet è cercare di fare una versione di base e poi riempire le scatolette dei servizi con le varie implementazioni.
Quindi design first (intanto i bookmarks e la cartella dei pdf ingrassano), con sempre il dubbio dell'overkill con gwt/tomcat, ma credo che adesso sia troppo tardi per fare altro (es. imparare javascript così bene da poter gestire la sorgente ajaxiana). Bisogna sviluppare un sistema di classi che sia estendibile, sicuro (importante: weatherApplication demo con le cartelle common per validazione client side/server side!!) e semplice da manipolare. Poi il fatto che la sorgente non sarà mai leggibile a parte da chi possiede il java mi turba un pochino, ma penso che se vogliamo usare GWT non ci siano alternative.
Quindi design first (intanto i bookmarks e la cartella dei pdf ingrassano), con sempre il dubbio dell'overkill con gwt/tomcat, ma credo che adesso sia troppo tardi per fare altro (es. imparare javascript così bene da poter gestire la sorgente ajaxiana). Bisogna sviluppare un sistema di classi che sia estendibile, sicuro (importante: weatherApplication demo con le cartelle common per validazione client side/server side!!) e semplice da manipolare. Poi il fatto che la sorgente non sarà mai leggibile a parte da chi possiede il java mi turba un pochino, ma penso che se vogliamo usare GWT non ci siano alternative.
mercoledì 14 novembre 2007
lista della spesa per la ui
chiesto a FST se installa sulla ui:
-gwt
-tomcat
trovato il wiki di Tomcat - per farlo parlare con php bisogna ricompilare il pacchetto php come da wiki:
http://wiki.apache.org/tomcat/UsingPhp
quando servirà...
FST dice che possiamo fare-da-noi e comunicargli le modifiche di roba installata secondo i nostri piani. Però finché non ho qualcosa di decente che gira in locale non ha molto senso mettersi a installare altro.
-gwt
-tomcat
trovato il wiki di Tomcat - per farlo parlare con php bisogna ricompilare il pacchetto php come da wiki:
http://wiki.apache.org/tomcat/UsingPhp
quando servirà...
FST dice che possiamo fare-da-noi e comunicargli le modifiche di roba installata secondo i nostri piani. Però finché non ho qualcosa di decente che gira in locale non ha molto senso mettersi a installare altro.
martedì 13 novembre 2007
tomcat purrs
Finalmente funziona. Seguire il tutorial trovato sul forum di gwt, ma avere l'accortezza di piazzare tutto il path da com.test.etcetc dentro la cartella classes in WEB-INF di tomcat. Ho fatto uno script giusto per dimenticarmelo appena possibile. Un altro paio di tutorial un pelino più avanzati a livello di rpc e poi si comincia a sviluppare il design della farm
lunedì 12 novembre 2007
uf.
uf. ho una google.gwt.user.client.rpc.InvocationException non meglio definita. tentate più o meno tutte le soluzioni di path per DataService, potrebbe essere qualunque cosa. Ultima cosa per oggi: vediamo se sono io o se è il gatto selvatico con il link di test
http://www.coreservlets.com/Apache-Tomcat-Tutorial/tomcat-5.5.html#Test3
http://www.coreservlets.com/Apache-Tomcat-Tutorial/tomcat-5.5.html#Test3
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/a403ebd45c94c77e/06f12f38c1381add?lnk=gst&q=tomcat+deployable+user+jar#06f12f38
Dal google group di GWT, per far girare l'applicazione su Tomcat (web mode)
OK got it running on Tomcat. Here are the steps
1. Strip the javax.* packages from gwt-user.jar . You can do it with
winzip/winrar etc. Open the jar in such tools and delete all files in
javax folder including the folder
2. Copy the stripped jar in your webapps/YourApp/WEB-INF/lib. Copy the
compiled classes (e.g copy the folder "com" in samples/dynatable/bin )
to webapps/YourApp/WEB-INF/classes
3. Modify your Service Entry point code (if required). Note the text
you put in place /calendar line. You will use this text in web.xml
later
ServiceDefTarget target = (ServiceDefTarget) calService;
String staticResponseURL = GWT.getModuleBaseURL();
staticResponseURL += "/YourApp/calendar";
target.setServiceEntryPoint(staticResponseURL);
4. Run DynaTable-compile.cmd (replace dynatable with app name). File
will be generated in www\com.google.gwt.sample.dynatable.DynaTable\ .
Copy all files within this folder to webapps/YourApp/
5. Create modify web.xml and place it in WEB-INF
SchoolCalendarService
com.google.gwt.sample.dynatable.server.SchoolCalendarServiceImpl
SchoolCalendarService
/calendar
5. Launch tomcat (...tomcat5.5/bin/startup.sh). Open browser e.g.
localhost:8181/YourApp/DynaTable.html
OK got it running on Tomcat. Here are the steps
1. Strip the javax.* packages from gwt-user.jar . You can do it with
winzip/winrar etc. Open the jar in such tools and delete all files in
javax folder including the folder
2. Copy the stripped jar in your webapps/YourApp/WEB-INF/lib. Copy the
compiled classes (e.g copy the folder "com" in samples/dynatable/bin )
to webapps/YourApp/WEB-INF/classes
3. Modify your Service Entry point code (if required). Note the text
you put in place /calendar line. You will use this text in web.xml
later
ServiceDefTarget target = (ServiceDefTarget) calService;
String staticResponseURL = GWT.getModuleBaseURL();
staticResponseURL += "/YourApp/calendar";
target.setServiceEntryPoint(staticResponseURL);
4. Run DynaTable-compile.cmd (replace dynatable with app name). File
will be generated in www\com.google.gwt.sample.dynatable.DynaTable\ .
Copy all files within this folder to webapps/YourApp/
5. Create modify web.xml and place it in WEB-INF
5. Launch tomcat (...tomcat5.5/bin/startup.sh). Open browser e.g.
localhost:8181/YourApp/DynaTable.html
non funziona se non in hosted mode
http://www.oracle.com/technology/pub/articles/dubois-gwt.html - funziona tutto bene in hosted mode, ma non ne vuole sapere se lo carico da browser. vediamo un esempio più semplice (GWT-RPC.ppt) per tirar fuori un # random dal server e vediamo se funziona in locale.
TODO: installare gwt e java sulla ui.
TODO: installare gwt e java sulla ui.
venerdì 9 novembre 2007
packaging
Design rozzo e preliminare --> v.quaderno
Qualche problemino con i packages in Eclipse (sembra non vedere le classi all'interno dello stesso package, sono inesperta abbastanza da dire che ha ragione lui stavolta, ma ho fatto tutto il possibile con classpath e adesso non so proprio cosa vuole).
Finito il tutorial di java.com - cominciato a guardare qualcosa su XML (da vedere più seriamente, intanto ho scaricato i parser per perl e per java). Sera: guardato un altro tutorial http://ajax.lodgon.com/gwt.html, troppo difficile e troppo poco commentato. Letto un po'del manuale ufficiale di GWT http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.html
Altro tutorial: http://www.onjava.com/pub/a/onjava/2006/05/31/working-with-google-web-toolkit.html
Qualche problemino con i packages in Eclipse (sembra non vedere le classi all'interno dello stesso package, sono inesperta abbastanza da dire che ha ragione lui stavolta, ma ho fatto tutto il possibile con classpath e adesso non so proprio cosa vuole).
Finito il tutorial di java.com - cominciato a guardare qualcosa su XML (da vedere più seriamente, intanto ho scaricato i parser per perl e per java). Sera: guardato un altro tutorial http://ajax.lodgon.com/gwt.html, troppo difficile e troppo poco commentato. Letto un po'del manuale ufficiale di GWT http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.html
Altro tutorial: http://www.onjava.com/pub/a/onjava/2006/05/31/working-with-google-web-toolkit.html
giovedì 8 novembre 2007
tutorials e ancora tutorials
Letto il corso di Nigro (JAVA) - tornare sulla parte di Swing quando sarò un po'più lucida (ho passato la giornata a far parlare SL e Debian...)
fatto ancora un po'del tutorial di Ajax for Java Developers,
http://www.ibm.com/developerworks/java/library/j-ajax4/
fino a quando non mi sono resa conto di NON essere un java developer - riprenderò appena avrò le conoscenze necessarie
cominciato i 36 tutorial di Agile Ajax:
http://blogs.pathf.com/agileajax/2007/07/36-gwt-tutorial.html
fatto ancora un po'del tutorial di Ajax for Java Developers,
http://www.ibm.com/developerworks/java/library/j-ajax4/
fino a quando non mi sono resa conto di NON essere un java developer - riprenderò appena avrò le conoscenze necessarie
cominciato i 36 tutorial di Agile Ajax:
http://blogs.pathf.com/agileajax/2007/07/36-gwt-tutorial.html
mercoledì 7 novembre 2007
i LOVE eclipse
fantastico! non so niente di java e faccio già le mie applicazioni integrate in GWT...adesso basta che capiamo se ci va bene (considerato che comunque io ho imparato le basi in un pomeriggio non dovrebbe essere troppo doloroso rimetterci le mani, soprattutto se si scrive codice java pulito e riproducibile per tutte le finestrelle, oppure se si può utilizzare GWT solo come interfaccia e se si vuole un'altro panel si fa copia&incolla.
Altra cosa da controllare: funzionerà in remoto?
Altra cosa da controllare: funzionerà in remoto?
lavoro in locale: test di toolkit
Test #1: DOJO
basta aggiungere div e lui va a pescare gli script per il layout da locale/remoto (aol).
Test #2: GWT
(per farlo funzionare: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/dove c'è il toolkit/mozillaVersion)
Lettura di presentazioni http://code.google.com/webtoolkit/presentations.html#GDD2007)
Bello, ma non c'è HTML nel source, che sembra puro javascript (e.g. se ci voglio mettere le mani in un secondo momento devo andare a trafficare con il codice javascript).
Cominciamo a mettere altra carne al fuoco - per sviluppare applicazioni web proviamo a vedere cosa fa Eclipse. Seguiti i tutorial nel programma (carini ma mi sento un po'minorata a fare le cose così). Eclipse rende la vita più facile essendo un ambiente di sviluppo per Java, ma non troppo.
Credo che tutto sommato GWT faccia cose molto belle ma la curva di apprendimento (considerato che devo imparare java) sia più ripida di DOJO. Eventuali problemi di mantenibilità futura?
Comunque basta layout per oggi, continuiamo con gli scriptini.
basta aggiungere div e lui va a pescare gli script per il layout da locale/remoto (aol).
Test #2: GWT
(per farlo funzionare: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/dove c'è il toolkit/mozillaVersion)
Lettura di presentazioni http://code.google.com/webtoolkit/presentations.html#GDD2007)
Bello, ma non c'è HTML nel source, che sembra puro javascript (e.g. se ci voglio mettere le mani in un secondo momento devo andare a trafficare con il codice javascript).
Cominciamo a mettere altra carne al fuoco - per sviluppare applicazioni web proviamo a vedere cosa fa Eclipse. Seguiti i tutorial nel programma (carini ma mi sento un po'minorata a fare le cose così). Eclipse rende la vita più facile essendo un ambiente di sviluppo per Java, ma non troppo.
Credo che tutto sommato GWT faccia cose molto belle ma la curva di apprendimento (considerato che devo imparare java) sia più ripida di DOJO. Eventuali problemi di mantenibilità futura?
Comunque basta layout per oggi, continuiamo con gli scriptini.
sabato 3 novembre 2007
dojo
toolkit installato e funzionante (http://.../js/dojo-release-0.9.0/dijit/themes/themeTester.html), intanto seguo i tutorial sul docbook (in locale visto che sto in collegio) e poi vediamo che riusciamo a farci. mi pare carino come grafica e non devo scrivere troppo codice (modifica attributi propri con una sintassi abbastanza semplice) - bisogna vedere se è suitable per i contenuti.
Iscriviti a:
Post (Atom)