Visualizzazione dei risultati da 1 a 10 su 14

Hybrid View

  1. #1
    Utente di HTML.it L'avatar di Alex'87
    Registrato dal
    Aug 2001
    residenza
    Verona
    Messaggi
    5,802
    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    A cosa serve il modificatore public messo li?? per me da ignorante non serve a nulla, ma invece a cosa serve di preciso??
    Se una classe top level non ha uno specificatore di accesso (solo "class" quindi) allora è visibile solo da classi all'interno dello stesso package. Con "public" invece è visibile ovunque.

    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    Ormai mi ero dato per spacciato, e quindi mi spiegavo il perche utilizzare il Framework Spring, e quindi le dependency injection, ma adesso che ho risolto mi riviene un dubbio, a cosa serve questo Framework??
    Ehm... Prima di metterti ad usare un framework come Spring (che fa TANTE cose, ha un sacco di moduli...) forse ti conviene studiarti bene Java (in particolare vita morte e miracoli dei java bean)
    SpringSource Certified Spring Professional | Pivotal Certified Enterprise Integration Specialist
    Di questo libro e degli altri (blog personale di recensioni libri) | ​NO M.P. TECNICI

  2. #2
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Serve a far sì che la classe sia accessibile da qualunque altra classe in qualunque altro package. E questo serve a FreeMarker, che accede al tuo bean tramite reflection.

    Già che ci sono ti segnalo anche una cosa: hai usato FreeMarker come "template" per pagine HTML. FreeMarker è generico, di per sé non "sa" nulla di HTML o altro linguaggio di markup. Se il tuo title (o qualunque altra property che esponi) contiene dei caratteri speciali per HTML es. '<' o '>', il tuo HTML complessivo risulta sballato.
    Per l'escaping serve dell'altro, vedere sul manuale: http://freemarker.org/docs/dgui_temp...insertion.html

    http://it.wikipedia.org/wiki/Spring_framework
    http://en.wikipedia.org/wiki/Spring_Framework

    Grazie mille ancora una volta ) molto utile l'escape ), per il framework spring mi sa che come dice Alex'87 devo studiare un po di più java e i java bean


    Quote Originariamente inviata da Alex'87 Visualizza il messaggio
    Ehm... Prima di metterti ad usare un framework come Spring (che fa TANTE cose, ha un sacco di moduli...) forse ti conviene studiarti bene Java (in particolare vita morte e miracoli dei java bean)
    Si, faccio tesoro di questo consiglio!
    Per caso avete qualche fonte dove leggere più in dettaglio cosa sono i java bean?
    Praticamente spring non usa i java bean classici ma bensi un altro tipo di oggetto proprietario con un funzionamento simile ma migliore, dico bene?

  3. #3
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    Praticamente spring non usa i java bean classici ma bensi un altro tipo di oggetto proprietario con un funzionamento simile ma migliore, dico bene?
    No, Spring tecnicamente è in grado di gestire qualunque tipo di oggetto, sebbene è ovvio che ha senso ed è tipico gestire oggetti che sono dei POJO (Plain Old Java Object) che a livello pratico vuol dire la stessa cosa dei Java Bean.
    A livello basilare un Java Bean=POJO è semplicemente e banalmente una classe che definisce oggetti che hanno "proprietà", accessibili usando una serie di convenzioni sui nomi dei metodi. Tutto qui. Poi le specifiche Java Bean effettivamente sono più complesse e contemplano ad esempio anche la gestione degli eventi. All'inizio infatti sono state pensate nell'ottica di definire "componenti" (specialmente quelli grafici GUI) che fossero riutilizzabili, "introspezionabili" e configurabili.
    Al giorno d'oggi quest'ultimo uso, cioè per componenti "grafici", non è più molto comune.

    Forse ti è utile anche: http://www.shaunabram.com/beans-vs-pojos/
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  4. #4
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Poi le specifiche Java Bean effettivamente sono più complesse e contemplano ad esempio anche la gestione degli eventi.
    Con questa frase intenti queste specifiche?


    1. Have a public default (no argument) constructor
    2. allows access to properties using accessor (getter and setter) methods
    3. Implement java.io.Serializable


    onestamente ho letto l'articolo da te suggeritomi, che semplicemente dice che i POJOs sono dei Java Bean ma allo stesso tempo sono Spring Bean... cioe, come hai detto tu, sono delle normalissime classi che istanziano degli oggetti; ad esempio una classe Book istanzia un Bean "libroJava" che rappresenta un libro.

    La cosi tanto semplice affermazione (se corretta) mi porta a pensare che un POJO è un oggetto che non seguele le specifiche dei Bean (sopra scritte), mentre uno Spring Bean è un oggetto che rispettale specifiche dei Bean ma è gestito dal Framework e non dalla classe a cui ne affida i servizzi...

    Spero di non aver confusione nel mio cervello

  5. #5
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    Con questa frase intenti queste specifiche?

    1. Have a public default (no argument) constructor
    2. allows access to properties using accessor (getter and setter) methods
    3. Implement java.io.Serializable
    No, quelle che hai appena detto sono solo le caratteristiche più basilari/fondamentali dei Java Bean. Le specifiche Java Bean sono più complesse, le trovi a partire da qui:
    http://www.oracle.com/technetwork/ja...ec-136004.html

    Nella pagina di download, scarica il PDF di 114 pagine e te ne renderai conto ....

    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    La cosi tanto semplice affermazione (se corretta) mi porta a pensare che un POJO è un oggetto che non seguele le specifiche dei Bean (sopra scritte), mentre uno Spring Bean è un oggetto che rispettale specifiche dei Bean ma è gestito dal Framework e non dalla classe a cui ne affida i servizzi...
    Dalla pagina: http://en.wikipedia.org/wiki/Plain_Old_Java_Object

    "The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks."

    Questa in effetti è la spiegazione corretta del termine POJO, ovvero oggetti Java che non seguono un modello particolare, nemmeno convenzioni o framework particolari.

    I Java Beans invece seguono delle convenzioni, già anche solo per i nomi dei metodi "accessori". Ma anche qui non è sempre tutto nero o bianco. Non sei obbligato a seguire tutte le specifiche Java Bean. La tua classe banquet non l'hai marcata Serializabile. Non serve, ti funziona lo stesso. Ma a livello basilare segue almeno le convenzioni Java Bean per definire le "proprietà", perché questo è quello che richiede FreeMarker.

    Nel libro Spring in Action, Third Edition c'è un paragrafo che forse ti può illuminare:

    "Although Spring uses the words bean and JavaBean liberally when referring to application components, this doesn’t mean that a Spring component must follow the JavaBeans specification to the letter. A Spring component can be any type of POJO. In this book, I assume the loose definition of JavaBean, which is synonymous with POJO."

    Alla fin fine puoi chiamarli solo "bean" o "Java Bean" o POJO ... anche per me almeno al livello più basilare sono abbastanza equivalenti.

    In un file di configurazione dei bean di Spring puoi mettere:

    codice:
    <bean id="myBook" class="xyz.Book">
        <property name="title" value="Spring in Action"/>
    </bean>
    Questo è un comunissimo bean, Spring a runtime istanzierà Book e lo inserirà nel suo container dei bean. Ma vedi bene quel <property>, qui segue e deve seguire le convenzioni Java Bean, almeno a livello basilare, ovvero un metodo setTitle con un parametro compatibile con il value. Tutto qui.

    Quell'oggetto identificato da myBook lo puoi "iniettare" in un altro oggetto gestito da Spring. Ma alla fin fine cosa ci fa la applicazione con questi oggetti sono affari della applicazione ... non di Spring. Una volta che la applicazione riesce ad ottenere la istanza di quel Book, ci fa quello che vuole, anche invocare metodi particolari definiti in Book, es. dumo() o altro che non centrano nulla con i "Java Bean".
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

Tag per questa discussione

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.