JavaServer Faces è uno standard

La comunità di sviluppo di Java ha approvato una nuova specifica che promette di semplificare la realizzazione di interfacce utente Web-based per le applicazioni Java

Roma - Dopo circa due anni di sviluppo, il Java Community Process Executive Committee ha finalmente approvato la standardizzazione di una specifica, chiamata JavaServer Faces, che permette di costruire interfacce utente per le applicazioni Web basate su Java.

Sun, che insieme a IBM, Oracle, Fujitsu, BEA, Borland, Macromedia e Apache Group è stata fra le massime promotrici di questo standard, ha spiegato che JavaServer Faces farà in modo che sviluppatori di varia esperienza possano creare velocemente applicazioni Web avvalendosi di componenti riusabili per assemblare l'interfaccia utente e connettere le applicazioni ad una sorgente di dati.

"Il principale obiettivo è quello di fornire agli sviluppatori di applicazioni e servizi in Java un singolo insieme di API che possa consentirgli di creare componenti in grado di interoperare", ha affermato Craig McLanahan, uno dei maggiori promotori della nuova specifica.
La versione finale della specifica JavaServer Faces 1.0, insieme ad una implementazione di riferimento, può essere scaricata da qui. L'implementazione consente agli sviluppatori di far girare le applicazioni basate sulla tecnologia JavaServer Faces con i container Java Servlet 2.3 e JSP 1.2.

Sun afferma che JavaServer Faces, considerato un componente chiave della piattaforma Java open source NetBeans, permette agli sviluppatori di concentrare i propri sforzi sulla stesura del codice applicativo. Lo sviluppo di applicazioni Web-based sarà ulteriormente facilitato con l'arrivo, a breve, dei primi tool WYSIWYG in grado di supportare la nuova specifica.
TAG: sw
26 Commenti alla Notizia JavaServer Faces è uno standard
Ordina
  • Visto che se ne è parlato, questo è quello per Struts:

    http://www.exadel.com/products_strutsstudio.htm

    Richiede sgancio moneta. Alternative OS su sf.net in embrione.
    FDG
    10909
  • - Scritto da: FDG
    > Visto che se ne è parlato, questo
    > è quello per Struts:
    >
    > www.exadel.com/products_strutsstudio.htm
    >
    > Richiede sgancio moneta. Alternative OS su
    > sf.net in embrione.

    oramai struts è diventato uno standard altro che java server faces dove per inciso senza un'editor decente ti rompi il culo
    e basta.
    questo prodotto comunque non è un granche se fai una ricerca
    su freshmeat ne trovi uno gpl che fa le stesse cose senza
    pagare un cazzoSorride
    non+autenticato
  • - Scritto da: Anonimo

    > oramai struts è diventato uno
    > standard altro che java server faces dove
    > per inciso senza un'editor decente ti rompi
    > il culo e basta.

    Struts è per il controller, JSF per la view. Per quanto a volte facciano la stessa cosa, sono strumenti per scopi differenti. E comunque anche senza strumenti di supporto ti rompi il sedere anche con struts.

    > questo prodotto comunque non è un
    > granche se fai una ricerca
    > su freshmeat ne trovi uno gpl che fa le
    > stesse cose senza pagare un cazzoSorride

    Ma non scrivere tanto per. Intanto l'unica cosa analoga a Struts Studio è EasyStruts (che trovi su sourceforge) che fa una frazione delle cose. E poi se ci lavori e ci guadagni, non vedo perché sia assolutamente da escludere l'uso di uno strumento a pagamento, soprattuto se puoi permetterti di abbandonarlo quando non ti va più di usarlo.

    Io capisco promuovere l'open source, ma da quì a dire cavolate...
    FDG
    10909
  • ...la risposta a .NET con i suoi server controls e a un ambiente visuale com Visual Studio per il web arriva solo adesso? Non mi dite, non voglio scatenare un flame, attendo risposte tecniche. Ho visto struct ma mi sembra ancora grezzo e PESANTISSIMO rispetto alla facilità e semplicità di ambienti grafici. Qualcuno mi puo' spiegare a che livello della facilità e rapidità di sviluppo che si trova nel mondo .NET, questo Javaserver FAces ci porta? Non per polemica, ma non ditemi che tutte 'ste menate su JSP, J2EE ecc., alla fine non c'era ancora un ambiente come Visual studio (intendo server controls)....Ne ho sempre avuto il sospetto, d'altronde JSP sono scopiazzate (con qualche miglioramento) da ASP, ma che ASP.NET fosse cosi' avanti non ci speravo. Speriamo di no, la concorrenza (come ha postato qualcun'altro) fa bene.
    PLEASE!!!! no flame, solo risposte tecniche, cerchiamo tutti di contribuire alla conoscenza tecnica degli altri. Io ci metto del mio con ASP.NET, che mi dite dall'altra parte?
    non+autenticato
  • - Scritto da: Anonimo

    > PLEASE!!!! no flame, solo risposte tecniche,
    > cerchiamo tutti di contribuire alla
    > conoscenza tecnica degli altri. Io ci metto
    > del mio con ASP.NET, che mi dite dall'altra
    > parte?

    Guarda, se vuoi di compri una licenza di WebObjects, che non è standard sun ma si integra perfettamente in ambienti J2EE al 100%, ed hai gli stessi ambienti visuali di .NET, magari qualcosa in più (a me continuano a dire che è fatto veramente bene). Solo che appunto non è frutto di una specifica ufficiale e non è manco open source, cosa che garantisce una certa continuità della soluzione e indipendenza dal particolare vendor.


    p.s.: ma cos'è che trovi di grezzo e pesante in Struts? Se per te grezzo vuol dire che ti devi scrivere i file di configurazione a mano, forse non hai cercato bene. Intanto su java si usa molto xdoclet. Poi se vuoi esistono tool visuali (ne ricordo uno che è un plug-in per Eclipse) che supportano Struts.

    ==================================
    Modificato dall'autore il 09/03/2004 15.26.36
    FDG
    10909
  • ah....grazie, finalmente uno che non scrive tanto perche' gli hanno dato le mani... un po' di argomenti tecnici, come dovrebbe essere un forum.
    Si' in termini di pesantezza mi riferivo ai file di configurazione, ma sinceramente stavo dando piu' un occhiata alle performance. Con gli controlli lato server di .NET, io sto ottenendo (da due anni circa, a dire il vero) ottimi risultati. Vedo progetti paralleli ai miei che arrancano con struct, quando le cose diventano serie, non nelle demo....Sorride
    Inoltre, mi si conferma che adesso io comincio ad avere ambienti decenti (non standard...) quando con .NET ce li avevo nel 2001....Questo mi preoccupa, che M$ faccia tendenza non è un granchè di incoraggiante. Oltre a ciò, mi sembra che per avere una cosa unica devo integrare un po' di cose di qui, un po' di cose di la'......non c'e' una visione unica.
    non+autenticato
  • - Scritto da: Anonimo

    > Vedo progetti paralleli ai miei che
    > arrancano con struct, quando le cose
    > diventano serie, non nelle demo....:)

    Che ti devo dire, forse non è un problema di struts. Quì questi problemi non li ho avuti.

    > Questo mi preoccupa, che M$ faccia
    > tendenza non è un granchè di
    > incoraggiante.

    Se è per questo fa anche "tendenza" nel linguaggio, viste alcune delle novità introdotte nel jdk1.5. Ma queste sono considerazioni parziali. Sarei curioso di valutare .NET e J2EE sotto altri punti di vista. Ad esempio, che c'è di equivalente a cose come JDO e Hibernate su .NET? E cosa per gli EJB? Su J2EE ho diverse alternative, con approcci sostanzialmente differenti, per trattare XML. Si va da soluzioni a basso livello come Xalan/Xerces, a librerie più ad alto livello come JDom e Dom4J, fino a approcci di mapping diretto tra oggetti e frammenti XML come Castor e JIBX. Su .NET?
    FDG
    10909

  • - Scritto da: Anonimo
    > ah....grazie, finalmente uno che non scrive
    > tanto perche' gli hanno dato le mani... un
    > po' di argomenti tecnici, come dovrebbe
    > essere un forum.
    > Si' in termini di pesantezza mi riferivo ai
    > file di configurazione, ma sinceramente
    > stavo dando piu' un occhiata alle
    > performance. Con gli controlli lato server
    > di .NET, io sto ottenendo (da due anni
    > circa, a dire il vero) ottimi risultati.
    > Vedo progetti paralleli ai miei che
    > arrancano con struct, quando le cose
    > diventano serie, non nelle demo....:)
    > Inoltre, mi si conferma che adesso io
    > comincio ad avere ambienti decenti (non
    > standard...) quando con .NET ce li avevo nel
    > 2001....Questo mi preoccupa, che M$ faccia
    > tendenza non è un granchè di
    > incoraggiante. Oltre a ciò, mi sembra
    > che per avere una cosa unica devo integrare
    > un po' di cose di qui, un po' di cose di
    > la'......non c'e' una visione unica.


    Io non ho mai avuto dei problemi di performance con struts... sei sicuro che il problema dipenda proprio da struts e non da qualche altra cosa?

    L'architettura J2EE è immensa e molto complessa. Per ottenere lo stesso risultato puoi utilizzare tecniche differenti (per esempio, puoi interfacciare XML in molti modi diversi, sia a basso livello che ad alto livello.

    Questo puo' sembrare disorientante all'inizio, ma in realtà è una dei punti chiave di questa tecnologia. Infatti ti permette di staccarti completamente dal fornitore: oggi IBM WebSphere, domani Bea WebLogic, tra un anno ORACLE application server... davvero, puoi cambiare tutta l'infrastruttura con una flessibilità incredibile.

    Ovviamente .NET presenta altri benefici e, ovviamente, il più "consistente" è la possibilità di avere un'integrazione totale in una sola tecnologia. Questo è bene a livello dello sviluppatore, ma se devi migrare l'infrastruttura sono dolori...

    Diciamo che è una questione di differente approccio tecnico al problema. Ma ti assicuro che J2EE non ha nulla da invidiare a .NET.

    Shalom

  • rispondo a tutti e due, FDG e lunix....
    Avete ragione ovviamente, non è detto che sia struct, ma da quello che mi dicevano piu' che altro era tutta la serie di strati tra il server e la generazione della pagina HTML client-side, che era un po' pesante. Parlo di applicazioni lightweight, dove alla fine non hai un quadriprocessore con 4gb di ram.....
    per JDO, ovviamente non conosco a fondo la tecnologia, ma se parliamo di persistenza di oggetti, oggetti disconnessi, oggetti DB non legati al DB sottostante, beh, qui .NET si muove bene con ADO.NET (ADO-JDO, non è che è una scopiazzatura anche questa?) ADO.NET contiene vari oggetti interessanti, come i dataset, le datatable, dataview ecc., tutto serializzabile e XML-abile. In merito a Hibernate, non mi sembra ci sia qualcosa di simile, ma non lo conosco, al di la' di quelle due cose che si leggono. Se mi spiegate meglio cosa fa, vediamo.....Beh, per trattare XML, penso .NET sia messo bene: intere classi per la gestione totale, sia DOM che SAX per capirci. I miei ragazzi sono entusiasti, e conoscono anche J2ee...io li' non ci ho ancora messo le mani. Per il mapping, ovviamente abbiamo sembre l'aspetto "disegno" con visual studio, e poi io ho usato xmlspy e cocoon.....
    Tornando alle considerazioni di Lunix, penso che effettivamente .NET, come approccio, sia piu' semplice, piu' lineare, meno prodotti che girano, tutto piu' integrato, uniforme e produttivo. Questo della produttività mi sembra un tema interessante: dato per scontato che nessuno dei due è una ciofeca, io valuterei sinceramente su
    1) PERFORMANCE ( e diteci poco)
    2) produttività del programmatore
    3) riuso
    4) multipiattaforma, portabilità

    Ok, ok, sul punto 4 lasciamo perdere, M$ è fuori di default. A parte il fatto che al PDC di M$ ho parlato con quelli del progetto Mono (mai sentito) e le cose li' sono interessanti....veder girare dot.net sotto una debian non è stato male....
    Ho qualche link a qualche benchmark tra le due architetture, vi interessa?
    non+autenticato
  • - Scritto da: Anonimo

    > Avete ragione ovviamente, non è detto
    > che sia struct, ma da quello che mi dicevano
    > piu' che altro era tutta la serie di strati
    > tra il server e la generazione della pagina
    > HTML client-side, che era un po' pesante.
    > Parlo di applicazioni lightweight, dove alla
    > fine non hai un quadriprocessore con 4gb di
    > ram.....

    Bene, allora il problema non è nello strumento, ma in chi l'ha scelto. Capisci che se per avvitare una vite uso un compressore da 600W, c'è qualocosa che non va. Il problema è che se devi realizzare una applicazione con qualcosa come qualche centinaio di servlet, pagine dinamiche e un modello dati piuttosto complesso, forse ti conviene mettere qualche strato e spendere di più nell'hardware e al limite ottimizzare le prestazioni dove veramente serve, piuttosto che farti tutto a manina e spendere un capitale in risorse umane e in tempo, senza considerare cosa comporta mantenere applicazioni di una certa dimensione. Viceversa, forse è meglio che lasci perdere gli strati che non sono necessari.

    ==================================
    Modificato dall'autore il 09/03/2004 17.04.10
    FDG
    10909
  • Veramente ci sono migliaia di struemnti dio sviluppo e framework gia' belli e pronti in J2EE cosa alla quale la MS e' arrivata molto dopo.

    Dire che JSP e' scopiazzato da ASP denota solamente la tua scarsa conoscenza delle tecnologie web server-side. ASP e' un linugaggio interpretato JSP no e' gia' qui direi che ce ne passa. JSP ha il supporto per le tag library cosa che non esiste nemmeno in .NET senza contare che si possno riutilizzare tutti i package Java che gia' avevi.

    Hai mai provato a riutilizzare codice ASP in ASP.NET . . . un vero macello.

    Senza contare che tutto il visual studio e' limitato dal fatto che gira solo su piattaforma Windows . . . beh da queste cose ci rende facilmente conto che J2EE e' anni luce avanti a NET.

    Da quanto ho scritto ti verra' da pensare che odio MS e .NET ma ti dico che ti sbagli, visto che proprio uno degli ultimi progetti che abbiamo consegnato e' basato su ASP.NET e MS SQL Server 2000. ha funzionato egregiamente ma personalmente ritengo J2EE una piattaforma molto piu' raffinata rispetto a .NET
    non+autenticato
  • ...ti ricordo che ASP è venuto un bel po' prima di JSP, e che sun stessa ha ammesso di essersi ispirata....ovviamente migliorando: chi arriva dopo copia sempre e poi innova. Quindi riguardati le date di uscita dei due prodotti, e capirai che tra i due mi sa che sei tu quello che ha la memoria corta....
    Che JSP sia compilato è una delle novità di JSP, ma è arrivato dopo: il linguaggio, la logica di sviluppo ecc. sono prese da ASP, rileggiti i giornali dell'epoca e soprattutto guardati le date dei due prodotti. Chiaro JSP nasce dopo ed è migliore di ASP, come del resto ASP.NET nasce dopo JSP, e quindi è nettamente superiore. Il parametro di riferimento ora è J2EE....

    Intanto J2ee è language-dependent, .NET moooolto meno. Nel mio ambiente, questo fa differenza....e molta. Se devo formare stuoli di programmatori che non conoscono java (e sono molti...), oppure se posso riciclare le loro conoscenze, questo mi fa la differenza. Come ambienti visuali di sviluppo, voglio proprio vedere un qualcosa di simile, in TUTTE le sue potenzialità, con Visual studio, e non intendo il semplice drag-and-drop, intendo profonda integrazione con il s.o. o con il DB che scegli come back-end. Lo dico amaramente, chiaro, questo è un limite allo stesso tempo, perche' è frutto della tecnologia proprietaria e dell'atteggiamento odiosamente monopolistico di M$, però l'ambiente è fantastico, giù il cappello. Ancora, vorrei veder qualcosa di facile come VS per creare web services e tutto quello che gli sta dietro. E, tornando alla risposta di prima, lo vorrei vedere INTEGRATO, non sparpagliato in 10 ambienti diversi. L'affermazione che fai sul "VS è limitato perche' gira solo su windows", quando windows è l'80-90% dei client esistente al mondo....che ne dici, non l'hai sparata un po' troppo grossa? direi proprio di si', è vero il contrario, che i miei cari colleghi che lavorano su J2EE quando mi vedono lavorare in debugging remoto (con la versione enterprise, è vero) con la facilità che VS, sul 99,5% delle macchine della mia azienda, beh, allora chi è limitato?
    Sul termine che usi "raffinato", non vorrei metterti in bocca cose che non intendevi, ma non ti sembra un po' "spocchioso", da "Informatico che se lo tira", da "quanto sono figo a usare j2ee"? Che vuol dire "raffinato"? In azienda, a me interessa che sia compatibile con i costi, i tempi e la tecnologia che mi chiede il cliente, e che mi consenta di stare dentro a questi parametri. Poi, sul "raffinato" o meno, sai dove me lo metto? Si' hai capito, scusa l'attaccamento al vil denaro, ma le seghe mentali da informatici aristocratici non mi interessano. Ripeto, magari non è il tuo pensiero, ma questa cosa che devo usare J2EE perche' è più "raffinato", mi puzza solo di narcisismo e/o snobbismo informatico....che nedici? Semplice domanda....io riscontro questo atteggiamento, dire J2ee fa molto figo....
    non+autenticato


  • - Scritto da: Anonimo
    > Semplice domanda....io riscontro questo
    > atteggiamento, dire J2ee fa molto figo....

    ... si dalle persone che non lo conoscono.

    Comunque dal tuo discorso si capisce che della tecnologia non te ne frega una cazzo (con questo non sto disutendo la tua compentenza) l'importante e' come hai detto tu il vil denaro.

    Mi sta benissimo e' un punto di vista che rispetto anche se non condivido.
    non+autenticato
  • - Scritto da: Anonimo
    > ...ti ricordo che ASP è venuto un bel
    > po' prima di JSP, e che sun stessa ha
    > ammesso di essersi ispirata....ovviamente
    > migliorando: chi arriva dopo copia sempre e
    > poi innova. Quindi riguardati le date di
    > uscita dei due prodotti, e capirai che tra i
    > due mi sa che sei tu quello che ha la
    > memoria corta....

    mi sembra che tu non sappia nemmeno leggere visto con non ho assolutamente detto da nessuna parte che JSP e' uscito prima di ASP o sbaglio ?

    Per intraprendere una discussione bisogna anche capire quello che l'alta persona scrive
    non+autenticato
  • è possibile con le JSF esprimere una sorta di gerarchia di compilazione della pagina ovvero implementare la dipendenza della compilazione di un campo da quella di un altro?

    Questo sarebbe molto utile.

    saluti
    non+autenticato
  • Come sappiamo le Java Server Faces (JSF) sono diventate finalmente uno standard con il rilascio delle specifiche nella versione 1.0 e con la disponibilità di una Reference Implementation. L'esigenza di una tecnologia di questo tipo è a mio parere naturale conseguenza del bisogno di strumenti STANDARD per la realizzazione delle interfacce Web attraverso la tecnologia JSP delle J2EE.
    Chiunque abbia programmato con le JSP ha da sempre sentito il bisogno di strumenti STANDARD che permettessero di :

    - creare diversi tipi di form (HTML, WML, etc) partendo dal modello dati
    - disporre di un modello flessibile per la validazione dei dati in esso inseriti secondo diversi criteri sintattici o semantici
    - disporre di un modello di gestione e visualizzazione degli errori in modo I18N
    - portare al Web il modello a componenti, e relativa gestione degli eventi, caratteristico delle GUI Desktop a favore del riuso

    il tutto poi utilizzabile attraverso un qualunque IDE.

    In realtà gli strumenti per la realizzazione di queste funzionalità (Struts & C) esistono da tempo ma non rappresentano formalmente uno standard. In linea con la politica Sun, la realizzazione delle specifiche JSF permetterà la realizzazione di componenti Web portabili tra un tool ed un altro. Il vantaggio dello standard riguarda anche la possibilità di poter eseguire una stessa applicazione basata sulle JSF in application server diversi sfruttando le diverse implementazioni che gli stessi mettono a disposizione.
    Altra importante caratteristica delle JSF è inoltre quella di essere un framework facilmente estensibile attraverso la realizzazione di componenti Custom di visualizzazione, validazione e gestione degli eventi associati.
    A mio parere si tratta comunque di una tecnologia che, nonostante debba fare ancora qualche passo avanti, diventerà di fondamentale importanza nella realizzazione di progetti Web basati sulla tecnologia Java.

    Massimo Carli
    http://www.carlimassimo.com
  • - Scritto da: massimocarli

    > In realtà gli strumenti per la
    > realizzazione di queste funzionalità
    > (Struts & C) esistono da tempo ma non
    > rappresentano formalmente uno standard.

    E sono pure centrati sul web, mentre JSF, da quel che ho capito, ne è indipendente. E poi Struts svolge principalmente le funzioni di controller. Tant'è che JSF non lo sostituirà, se non nelle parti comuni.
    FDG
    10909
  • Qualcuno ha provato le implementazioni open source di JSF?
    FDG
    10909
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)