Si, il problema è che è un attimo più complesso: dovrebbe gestire tutto il transito di materiali e prodotti finiti di un'azienda, aggiornare 5 magazzini diversi, emettere fatture (precise al centesimo), rendere come output fogli destinati per la produzione, calcolare vendite, aggiornare i daatabase ecc. ecc. Non è semplicemente pescare da un database xml. XUL può fare tutto ciò?
Perché vuoi che XUL faccia tutto ciò? Come fa XUL a fare qualcosa se è solo un linguaggio di markup XML?
Per farti capire cosè xul ti faccio questo esempio classico:
Quando programmi in C o C++ scrivi delle funzioni oppure delle classi, insomma del codice che fa qualcosa, tipo:
a = c + d;
printf("%d", a);
ma non hai un'interfaccia grafica. Allora normalmente si aggiungono delle librerie al proprio programma, che possono essere quelle native di Windows, ma anche altre, come GTK, QT ecc. che ti permettono di generare l'interfaccia, a partire dalla finestra, fino ai pulsanti e a tutte le altre widget.
XUL può sostituire proprio questa parte: invece di inglobare windows.h o gtk.h nel tuo programma, puoi inglobare direttamente Gecko, ed invece di utilizzare le widget Windows, GTK ecc, puoi utilizzare le widget XUL.
L'accoppiata wincente più che C+gecko è Python+Gecko, sia per facilità di programmazione che efficienza del software prodotto (i programmi interpretati in Python sono da 2 a 5 volte più veloci degli analoghi compilati in C).
Un'utilizzo differente di xul è quello di avere un backend che produce codice XUL da dare in pasto a Mozilla. Il backend può essere php, python, servlet java, cgi, asp, ecc. che ti genera al volo l'interfaccia e si va a pescare tutti i dati necessari.
Ad esempio php ha tutte le librerie necessarie a trattare file xml con efficienza: basta associargli XUL per avere un'interfaccia grafica degna di chiamarsi tale. Lo stesso lo puoi fare con python, ecc.
Spero di essermi finalmente spiegato! La risposta a "Si può fare con XUL" è decisamente SI se si ha capito cos'è XUL, perché XUL si usa col proprio linguaggio di programmazione preferito per realizzare interfaccie, siano esse locali (caso del binding C (o altro) + gecko) che remote (caso di produzione al volo di codice XUL da far interpretare a Mozilla).
La risposta è NO se invece commetti l'errore di pensare a XUL come a un linguaggio di programmazione (non lo è: è puro e semplice XML).
I vantaggi? Nel caso dell'utilizzo in locale è sostanzialmente il supporto multipiattaforma nativo e la disponibilità di avere il rendering dell'html incorporato. Nel caso remoto (ma che può essere anche locale se si installa localmente l'interprete php, o si compilano gli script) i vantaggi invece sono molto maggiori: si ha al volo un software distribuito e leggero, facile da scrivere (vuoi mettere programmare in python rispetto a quei ruderi di Java o, peggio del peggio, C/C++?), multipiattaforma fin dall'inizio.
Come c'entra JavaScript in tutto ciò (e non confondere Javascript con Java: il termine corretto sarebbe ECMAScript)? Viene utilizzato da XUL per la gestione degli eventi (ovvero il click del mouse, la gestione di un widget, ecc.). In realtà ci si può scrivere anche del software (ECMAscript è un linguaggio completo contrariamente a quanto si possa pensare) ma l'approccio è più difficoltoso per la mancanza di seri strumenti di supporto (a parte Venkman).
Cmq ti ripeto: se chiedi nella ML che ti ho indicato all'inizio del thread troverai un bel po' di persone che hanno già affrontato ciò che tu vuoi... mica la devi seguire sta ML...
Ciao,
Michele