Newsgroup: it.lavoro.informatica
Titolo: [ot] ma xml si usa?

No, poichè vorrei capire chi è quel pazzo che lo usa e che vantaggi ne ha...
/

 No, poichè vorrei capire chi è quel pazzo che lo usa e che vantaggi ne
ha...
Stai bene ?
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


per usarsi si usa, il problema è che se non lo sai gestire hai
problemi, oramai.

 No, poichè vorrei capire chi è quel pazzo che lo usa e che vantaggi ne ha...
In che ambito?

 No, poichè vorrei capire chi è quel pazzo che lo usa e che vantaggi ne
ha...
chissa' perche' ma viene in mente il pazzo contromano in autostrada :-D
p.s. motiva tu la "pazzia" nell'usare XML

 ha scritto nel messaggio
news:38107cF...@individual.net...

apparte questo namespace xmlns="
http://www.w3.org/1999/xhtml
" che uso a
volte anche in 
asp.net
 non vedo grossi vantaggi che ripaghino lo sforso di
definire inamespace e i DOM nello sviluppo di applicativi in genere.
Oppure non ci ho capito una cippa...
/

 ha
Qualsiasi file
ASC
CSV
stream di byte
eccc
sono + leggibili e manipolabili in xml
N


 sono + leggibili e manipolabili in xml
nella prossima release di openoffice, il formato di default dei 
documenti sarà xml...
bye,
Major

documenti sarà xml...
Come mi facevano notare, anche quello attuale è XML (prova a
scompattare un file...)
--
Ciao!
Luca Menegotto

 sono + leggibili e manipolabili in xml
In effetti avevo pensato anche io a questo, ma sinceramente se scambio i
dati in ascii lo faccio perchè debbo magari mandare un file a un palmare dos
o porcate simili(as400, unix vecchio stile).
Non vedo utilizzo per quel che riguarda le piccole e medie soluzioni, mentre
sicuramente per soluzioni + avanzate potrebbe valere la pena definire un
output in xml.
Vediamo se mi aiutate a chiarirmi l'idee , supponiamo io voglia fare un
report senza usare pdf oppure strumenti particolari, potrei farlo in xml e
fare in modo che se ci doppio clicco con explorer questi si visualizzino e
stampino e se ci clicco con applicazione tizio/caio questi invece magari
vengano interpretati e presentati a video?? A questo puo' servire xml?
/

 No, poichè vorrei capire chi è quel pazzo che lo usa e che vantaggi ne ha...
XML è il futuro. Un po ostico all'inizio, ma incommensurabilmente più potente 
per la definizione e lo storing delle informazioni. 
-- 
______________________________________
Luc (31, CO, VC++ Programmer)
Editorial Systems Software development
______________________________________

Essendo uno standard xml si apre a molteplici funzionalità ed ambienti.
Primo frà tutto l'utilizzo di web service che utilizzano il protocollo soap.
Esempio io scrivo un'applicazione in .net e devo passarti dei dati a te che 
la scrivi in java, in mezzo ci mettiamo un bel webservice che non fà altro 
che restituire un file xml e poi chi lo legge lo manipola senza problemi.
O ancora i file word e excel ecc possono essere salvati in xml.....
Non vedi utilità???? 

 vengano interpretati e presentati a video?? A questo puo' servire xml?
Non sono un programmatore, sviluppatore ed in questo ambito rischio di 
dire cavolate, ma XML dovrebbe essere il nulla.
E' un formato che bene si adatta a contenere dati di ogni genere perché 
estensibile ed in quanto ormai standard è al scelta di default per lo 
scambio di dati tra applicazioni che altrimenti non hanno un protocollo 
comune.
XML non serve a niente senza un parser che ne estragga le informazioni, 
sia in php, c, java e quant'altro.

 vengano interpretati e presentati a video?? A questo puo' servire xml?
Ti rigiro l'esempio (reale):
Prendi i tuoi dati di cui vuoi fare un report, li rappresenti in un 
formato xml secondo uno schema formatting object (fo). Clicchi su 
"Report in PDF" e l'xml viene trasformato in PDF, clicchi su "Report in 
PS" e viene trasformato in PostScript.

 PS" e viene trasformato in PostScript.
Ok, diciao che per prodotti orizzontali è quasi una scelta obbligata, per i
prodotti verticali a cui "purtroppo" sono abituato a partecipare non ho
avuto gran modo di farne utilizzo. Dovendo probabilmente fare analisi
(funzionale e in parte tecnica) per un grosso applicativo java, devo
prendere in considerazione tutto dato che la documentazione j2ee fa molto
riferimento a xml e sinceramente manco di esperienza per il momento e non
vorrei che sia un grosso handicap.
Rischio di  ritrovarmi per la prima volta in vita mia a dover fare analisi
su un prodotto che verrà sviluppato con una tecnologia che non conosco a
pieno(sto già rimediando con le ottime guide sun), io la vedo come un'
opportunità niente male, spero di non fare fregnacce.
Ciao
Luther

 XML non serve a niente
XML è un contenitore. Vuoto non serve a niente, questo è vero, ma... 


 
Anche senza un parser

per la definizione e lo storing delle informazioni.
A pensarci bene se potessi tornare in piedi lo avrei usato per la
realizzazione di alcuni DDT molto complessi fatti tempo fa, mi hanno fatto
davvero patire, soprattutto quando dopo mesi che li utilizzavano mi hanno
chiesto di poterli salvare in pdf o simile...
/

 vengano interpretati e presentati a video?? A questo puo' servire xml?
NO!
L'xml è un file di testo che rappresenta dei dati nudi e crudi. Da questo
punto di vista è assimilabile (con le dovute cautele) ad esempio ad un file
csv. La differenza è che è diverso il tipo di dato trattato.
In un file csv io posso gestire agevolmente un tipo di dato 'dizionario',
del tipo nome = valore
es.
Nome=Roberto
Professione=Programmatore
oppure un tipo di dato tabella:
es.
Nome,Professione
Roberto,Programmatore
Mario,Sistemista
Il vincolo di questo tipo di memorizzazione è dato dalla difficoltà del
parsing dei dati e dalla semplicità del tipo di dato che viene memorizzato.
L'xml è la possibilità di strutturare il dato in maniera più complessa
perchè si utilizza come tipo di dato 'l'albero', in più si utilizzano i
marcatori che danno un significato formale al dato
es.
<a>
   <b>
      <c>Roberto</c>
      <d>Programmatore</d>
   </b>
   <b>
      <c>Mario</c>
      <d>Sistemista</d>
   </b>
</a>
.
I vantaggi sono diversi, il primo è la potenza del tipo di dato, in un
albero io posso memorizzare dati diversi anche non omogenei tra di loro ,
inoltre esistono oramai in tutti i linguaggi di programmazione potenti
strumenti per il parsing automatico dei dati secondo varie metodologie (
vedi API DOM o SAX).
I vantaggi dell'xml non finiscono qui, da questo punto di vista l'xml sembra
utile solo per memorizzare dati e non per rappresentarli ma guarda caso da
qualche anno a questa parte si è diffuso uno strumento che riesce a dare
colori e forme a documenti testuali purchè scritti con opportuni marcatori:
il browser.
Il browser può avere caratteristiche diverse e risiedere su dispositivi
differenti, tutti i browser però sono accomunati da una cosa: leggono file
di testo scritti con un apposito linguaggio a marcatori e ne mostrano il
contenuto opportunamente formattato.
L'xml è anch'esso un linguaggio a marcatori ed ha una caratteristica: è
possibile definire delle opportune trasformazioni e formattazioni (scritte
in un apposito documento sempre xml ma con tag opportuni (come ad esempio
quelli del namespace xsl)) che trasforma un documento con dei marcatori e
contenente dei dati, in un altro documento con altri marcatori ma contenente
sempre gli stessi dati, o una parte di essi o un'elaborazione di essi.
Questo è il vantaggio,
Io posso avere una sola fonte dati rappresentata da un documento xml e
divertirmi a realizzare tutte le trasformazioni che mi pare creando
opportuni documenti xsl che mi trasformano il mio documento di partenza in
un documento con gli stessi dati ma aspetto differente.
Quindi ad esempio potrei avere che:
pippo.xml + pippo.xsl = pippo.htm
pippo.xml + pippo1.xsl = pippo.pdf
pippo.xml + pippo2.xsl = pippo.wml
ecc.
tale fusione non è automatica ma è molto semplice da implementare.
L'argomento è vasto, io ho accennato solo ad un aspetto e lungi da me la
pretesa di essere stato esaustivo o rigoroso, spero solo che quel poco che
ho detto sia stato chiaro o abbia fornito spunti di approfondimento


 ho detto sia stato chiaro o abbia fornito spunti di approfondimento
Ok, comincio a chiarirmi l'idea per un utilizzo in abiente tipicamente
server(web) anche se la mia mente dannata i suggerisce un utilizzo della
tecnologia per archiviare dati complessi.
Grazie del minicorso.
Ciao
Luther

 vengano interpretati e presentati a video?? A questo puo' servire xml?
certo che si.
il caso che citi calza a pennello con le tecnologie accessorie ad xml che 
sono xslt, e xsl-fo che permettono di prendere un xml, e di trasformarlo in 
altro (anche un pdf, o un html), inoltre lo stesso xml puň essere preso cosě 
com'č da una app windows e visualizzarlo a video tramite un datagrid facendo 
un semblice databind dei dai contenuti appunto nel file xml (parlo di 
tecnolgia Microsoft).
tieni presente fra l'altro che il mondo web professionale si sta spostando 
da html ad xhtml, questo non č altro che pagine html inserite in un file 
xml, e quali a questo punto non soffriranno piů delle "dimenticanze" degli 
sviluppatori web (leggasi tag non chiusi, virgolette mancanti, ecc): essendo 
l'html "annegato" nel file xml questo deve essere per forza ben fatto 
(well-formed) altrimenti nisba, con xslt poi sul client viene scaricato il 
file xml orginale opportunamente trasformato (xslt significa proprio 
trasformazione di schema xml) in puro formato html. anzi ti dirň di piů: i 
browser del futuro lo faranno da soli.
saluti
Roberto 

 vengano interpretati e presentati a video?? A questo puo' servire xml?
A partire dal file XML potresti avere più output, compreso il PDF.
Non a caso, negli ultimi applicativi lato server di Adobe (penso a tutti i 
prodotti che rientrano nella etichetta LiveCycle), il PDF è il risultato di 
un processo che coinvolge un XML source. In questo modo tu, anzichè avere 
dei PDF "statici", puoi avere dei PDF che si compongono on the fly a seconda 
del tipo di dato che gli arriva (dato che può essere costituito da xml data, 
xml schema, db, o qualunque cosa ti viene in mente).
Ma in realtà il PDF, ripeto, è, come hai intuito giustamente, uno dei 
possibili output.
Inoltre, vuoi mettere la possibilità di avere molteplici output a partire da 
un codice che è facilmente leggibile ed interpretabile e, soprattutto, è al 
di sopra degli altri formati in quanto a durata nel tempo (nel senso che un 
file XML potrai sempre leggerlo anche con un semplice notepad)?
Ciao,
Alessio (a.k.a. Kinglion) 

 contenuto opportunamente formattato.
Serve comunque un parser, che lof accia il browser o una applicazione 
che genera determinati suoni a seconda dell'xml č indifferente.

 che vantaggi ne ha...
XML è fondamentalmente una moda, gli si è creata intorno una fama di essere 
La Soluzione, e chi non lo usa viene visto come antiquato, obsoleto o 
semplicemente stupido.
È sicuramente un sistema utile e versatile, ma si sopravvive benissimo anche 
senza, e in alcuni ambiti è assolutamente controproducente. È un formato 
estremamente verboso per archiviare dati, e fondamentalmente è sempre e solo 
un file di testo formattato, quindi assolutamente non indicizzabile; inoltre 
spesso, per fare un parsing decente di un file XML, occorre prima leggerlo 
tutto. Va da sé, quindi, che usarlo per archiviare dati è assolutamente 
controproducente... mentre invece, ad esempio, come formato di interscambio 
di informazioni può essere utilissimo, essendo uno standard.
Un paio di link che toccano (sebbene marginalmente) l'argomento:
http://www.joelonsoftware.com/articles/fog0000000319.html
http://www.joelonsoftware.com/articles/fog0000000296.html
Massimo

 Vediamo se mi aiutate a chiarirmi l'idee , supponiamo io voglia fare un
http://forum.ioprogrammo.net/thread.php?threadid=2471&boardid=6&styleid=1&sid=804704e883c8bb3a466a5275311491f7
(occhio al wrap)
Ciao,
Andrea

 Anche senza un parser
i parser esistono, non te li devi scrivere 


 è ovvio che ogni argomento che non hai mai affrontato ha delle incognite, 
ma l'XML è un dato di fatto, prima o poi con dovrai averci a che fare 

Massimo ha scritto:
 > È un formato estremamente verboso per archiviare dati, e fondamentalmente
 > è sempre e solo un file di testo formattato, quindi assolutamente non
 > indicizzabile
Con buona pace di Google.
-- 
Ciao da Villo    -    GPG public key available
                       Ferrara LUG 
http://ferrara.linux.it
		      Remove "+settanta" for email replies
Protect your Freedom: 
http://www.againsttcpa.com/index.shtml

 Con buona pace di Google.
E dai, forse mi sono espresso male, ma tu non far finta di non aver capito.
È assolutamente impossibile, per una semplice questione di complessità 
algoritmica, recuperare dati in tempi umani da una posizione casuale di un 
file XML. Ovvio che poi un indice puoi crearlo a parte, così come puoi fare 
il parsing dell'intero file e tenertelo in memoria... ma la struttura del 
file non prevede la possibilità di raggiungere rapidamente un record 
qualsiasi, le ricerche vanno fatte in modo lineare. E l'aggiunta di elementi 
richiede spostamenti di tutto il testo in memoria, né più né meno che con un 
array.
Massimo


Eccone uno !!! Innanzitutto perche' e' uno standard, molto diffuso, e come
tutti gli standard la diffusione fa la differenza fra una cosa utile e una
cosa inutile.
Da cio' ne consegue che moltissimi altri standard sono basati su XML, e che
ci sono una quantita' infinita di librerie che pemettono di costruire,
analizzare ("parsare"), validare, trasformare xml. Per farti una cultura,
vai su 
xml.apache.org
 ;-)
Altri vantaggi rispetto ad altri standard: supporto unicode e', come si
dice, human-readable, ed e' molto semplice. Scusa se e' poco ...
Dico la verita', non mi sono mai posto il problema se conviene usarlo o meno
perche' lo devo usare.
tra parentesi ... se hai la necessita' di scrivere documenti pdf o di altri
tipi a partire da XML, hai mai sentito parlare di XSL-FO? dai una occhiata
al sito che ti ho indicato, vedrai che ti diverti ... :-)))

 ne ha...
Hai mai letto le FAQ di questo gruppo? Le mantengo in XML, 
http://www.sen.it/faq/it.lavoro.informatica.faq.xml
 (guarda il 
sorgente), i cui elementi rispettano le regole enunciate nello schema 
alla pagina 
http://www.sen.it/faq/faq.xsd
, e che vengono visualizzate in 
html grazie all'utilizzo di un apposito foglio di stile XSLT 
(
http://www.sen.it/faq/faq.xslt
). Se uno ha un browser che non gestisce 
i fogli di stile, allora ho creato un piccolo web service (in house, ma 
se vuoi posso pubblicare il sorgente, banalissimo, in c#) che a partire 
dal file XML e dal foglio di stile XSLT mi restituisce una pagina HTML 
(
http://www.sen.it/faq/it.lavoro.informatica.faq.html
), software che ho 
successivamente modificato (leggermente) quando mi è stato necessario 
creare un'altra versione formato solo testo 
(
http://www.sen.it/faq/it.lavoro.informatica.faq.txt
), grazie ad un 
altro foglio di stile (
http://www.sen.it/faq/faq.text.xslt
). Qualora in 
futuro mi servisse rendere il documento in formato PDF o XLS o DOC o RTF 
o qualsiasi altro formato ti potesse venire in mente, dovrei 
"semplicemente" scrivere un foglio di stile adatto (magari utilizzando 
apposite librerie o tecnologie complementari).
Questo premesso, renditi comunque conto che il piccolo progettino di cui 
sopra è poco più di un'esercitazione di stile (scrivere l'XSLT, gli XSD 
ed il web service in c# mi ha impegnato per una manciata di ore, 
spulciare su Google per trovare i messaggi è molto più time consuming), 
XML e le sue tante ramificazioni sono al giorno d'oggi onnipresenti sia 
in J2EE che in .Net, e che le occasioni di averci a che fare sono 
pressoché continue (DataSet ed ant, giusto per citare le prime buzzword 
che mi vengono in mente, una per framework), e che un po' di tempo 
bisognerebbe investircelo in ogni caso ;-)
HTH,
P.S.: nota personale, la prima volta che ho usato XML professionalmente 
è stato nel lontano 1999, ma già nel 1998 avevo preso parte ad un 
progetto di traduzione in Italiano dello standard ..
-- 
ale
http://www.sen.it
et corruptissima re pubblica plurimae leges 

 array.
A prescindere che sin dalle prime apparizione esistevano gia' le librerie
per fare il parsing intero che quello parziale (dom contro sap mi pare?)
per cui non era affatto necessario leggerlo tutto ma c'erano
indicizzazioni e modi di recupero piu' rapidi.
Stai dicendo una cosa molto ovvia: che non e' il metodo piu' rapido per
indicizzare una struttura di dati. Ma non mi sembra che sia una grande
scoperta. Per il semplice fatto che la soluzione migliore dipenderebbe da
come sono strutturati i tuoi dati. Ma quello che sfugge a te e a Joel e'
che nei progetti informatici non si puo' creare una struttura di
indicizzazione e ricerca dati per qualsiasi documento che ti arriva in
azienda. Questo significherebbe reinventare la ruota ogni volta per
spingere il carro di 10 metri all'ora. Ovvio che se l'indicizzazione dei
dati e la ricerca sono dei parametri fondamentali non farai affidamento a
xml. Ovvero dovrei crearti delle microstrutture che eventualmente andranno
suddivise e su cui agirai con dei formati ad hoc. E anche li' riuscire a
creare un format standard per ognuno delle microstrutture sarebbe
un'impresa abbastanza ardua. Per questo motivo occorre comunque avere una
struttura standard che sia un po' piu' evoluta di un formato testo. 
Ma questo discorso varebbe, ad esempio, per tutte le collection in tutti i
linguaggi; molte volte ti accorgerai che la Hashtable cosi' come la
definisce il c++ o il java non e' la collection piu' adatta al tuo scopo.
Vale la pena riscriverla? Dipende dai benefici che avrai. Ma certo gli
ideatori di java/c++ non hanno pensato male a creare una struttura
standard che era il miglior compromesso tra prestazioni, semplicita' e
affidabilita'.  Ora, se hai in mente una struttura standard per
l'organizzazione dei dati che sia migliore di XML che ben venga (forse sei
troppo giovane per ricordarti i messaggi EDI), se non ce l'hai non ritengo
che tu abbia il diritto di fare una critica del genere che suona piuttosto
pomposa.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

tutto. 
In linea di massima qui sarei d'accordo con te, se non fosse che a mio
avviso non cogli la cosa fondamentale di XML. Faccio un passo
indietro.
Ovvio che si può sopravvivere benissimo senza. In fin dei conti
ciascuno può fare i suoi files di testo, e per molte cose i ceri
vacchi files INI di Windows (o il corrispondente per qualsiasi altro
sistema operativo) vanno bene nel 90% delle applicazioni.
Perché allora XML è così interessante?
Perché è uno standard in grado di rappresentare la quasi totalità
delle situazioni in cui è richiesta l'archiviazione o il trasferimento
dei dati. Intanto, causa la intrinseca struttura gerarchica, è in
grado di meglio rappresentare situazioni in cui altri formati, ad
esempio CSV, danno prova di ridondanza (mandando così a pallino la
loro ipotetica maggior efficienza). In secondo luogo, sono portabili
da un ambiente all'altro (mi viene in questo momento in mente i files
archivio di Thunderbird). Infine, essendo standard, sono leggibili da
un qualunque parser XML in qualunque ambiente operativo. 
E' la soluzione a tutti i mali del mondo? No, ovviamente, come tutte
le soluzioni ha un suo preciso ambito di utilizzo e deve essere
impiegato in modo corretto, e qui sta a chi lo impiega comprenderlo e
utilizzarlo correttamente.
Certo è - e così finisco con un esempio - che nelle prossime
applicazioni che dovrò disegnare da zero non utilizzerò più il
registro di configurazione di Winxx per l'archiviazione dei dati di
configurazione dell'applicazione, ma impiegherò un bel file XML.
--
Ciao!
Luca Menegotto

 ha scritto nel messaggio 
news:cvgks6$mg$1...@news.newsland.it...

Non sto dicendo che XML non serva a nulla o non abbia un suo campo di 
applicazione e una sua utilità.
Sto solo dicendo che usarlo per forza, anche laddove non servirebbe o non 
sarebbe la soluzione ottimale, perché "XML è fico e se non lo usi non sei al 
passo coi tempi" è una pessima mossa.
Massimo


http://www.sen.it/faq/it.lavoro.informatica.faq.xml
 (guarda il 
Al di la del post, che ho letto con certo interesse (sto affrontando
XML in modo serio solo ora), io nemmeno sapevo esistesse una faq.
Ergo, preso e messo fra i bookmarks. :)))
--
Ciao!
Luca Menegotto

 progetto di traduzione in Italiano dello standard ..
Sarà che ho sempre considerato lo standard una cosa per il web e ho lasciato
ai designer la scelta di come fare le pagine, mi rendo conto che mi sono
sbagliato e comincio a essere meno reticente di ieri e lo prendero'
sicruamente in considerazione in fase di analisi e progettazione delle
prossime soluzioni.
/

 memoria, né più né meno che con un array.
Che è una cosa che si fa abbastanza facilmente con le varie librerie, ma 
che se stai offrendo dei servizi su SOAP devi guardarti bene dal fare a 
cuor leggero, modificare il tuo DTD per esperienza non è mai una 
operazione indolore (i.e.: è un bagno di sangue!).
Ho letto anche le altre tue risposte, e in una cosa ti do ragione: XML 
non si deve usare a cuor leggero, solo perché fa figo. Però ora come ora 
  la quasi totalità dei soggetti in circolazione offre o vuole servizi 
online basati su soap ed xml, e a mio avviso fa bene.
-- 
Luca Villani     NOC Manager  -  Wireless Solutions S.p.A.  (Dada Group)
http://www.wseurope.com
          via Castiglione 25, 40124 Bologna Italy
T:
+39 051 2966826
   F:
+39 051 2966800
   M:
+39 348 5298542
   UIN:76272621
GPG public key available

 configurazione dell'applicazione, ma impiegherò un bel file XML.
Pessima mossa, direi, visto che il Registro nasce proprio con questo scopo, 
e soprattutto permette già per sua natura la distinzione tra impostazioni 
computer e impostazioni utente, alla quale altrimenti dovresti supplire 
mettendo i file di configurazione nella directory del programma (orrore!) e 
quindi scordandoti la multiutenza, oppure piazzandoli nella directory del 
profilo utente, spargendo così file per ogni dove.
Massimo

 online basati su soap ed xml, e a mio avviso fa bene.
Questa mi sembra un po' una contraddizione... come si fa a fare bene a voler 
usare XML a tutti i costi se non bisogna usarlo a cuor leggero e solo perché 
fa figo?
Massimo

 Luther
Rischi moltissimo.
In questi giorni sto scoprendo con stupore che anche chi lavora in j2ee da
parecchi anni spesso non ha capito nulla.
Il j2ee e' completamente innaturale per l'essere umano.
Ogni cosa banale diventa un problema, senbra assurda e spesso porta il
programmatore/progettista ad atteggiamenti ostili, e ancora + spesso a
"sgarrare" volontariamente o involontariamente. Purtroppo una applicazione o
e' j2ee o non lo e', non ci sono vie di mezzo, basta una parte che non
rispetta le regole e cade l'artchitettura.
Se ti avventuri in questa impresa, e il progetto e' complesso, probabilmente
andrai al fallimento. Inoltre puoi anche sentirti in colpa che magari togli
il lavoro a un buon progettista con esperienza e se fallisce il progetto
contribuisci a diffondere la spesso diffusa iopinionie che gli informatici
sono dei mezzi imbroglioni che dicono di saper fare e non e' vero.
Se proprio ti avventuri ti consiglio di leggere un buon testo. Non un
manuale, un testo architetturale sulla filosofia che c'e' dietro l'
apparentemente incomprensibile.
Un alteo difetto che spesso riscontro negli informatici e' che non
stuudiano. Vogliono sapere senza studiare. Non si sa come.
senza il minimo rancore, riporto solo la mia opinione da addetto ai lavori.
ciao e buona fortuna,
Nicola


 Il j2ee e' completamente innaturale per l'essere umano.
Perché sostieni questo?
Non lo conosco quasi per nulla, ma questa frase mi ha incuriosito.
Massimo


Il j2ee puro vieta quasi completamente l'uso di
file
socket
thread
risorse native
raramente permette di usare variabili di istanza
spesso integra pattern complessi sia per il front end che il back end
gli ejb richiedono oltre alla programmazione un overhead notevole
per un informatico che magari viene dal C a volte rasenta la follia
normalmente a questo bisogna aggiungere che bisogna conoscere abbastanza
bene gli application server implicati
nulla di impossibile, ci vuole esperienza e studio pero'
tutto imho naturalmente
ciauz N


 tutto imho naturalmente
Detta così, viene da chiedersi perché si usi il J2EE... no, dai, non ci 
credo, qualche vantaggio *deve* averlo!
Massimo

 Massimo
portabilita' reale
load balancing
fault tolerance
molto ordine
manutenzione + facile
sicurezza alta
integrazione alta
ha senso solo per progetti ad alto budget e se ci lavorano un certo nunero
di persone
altrimenti non conviene
ciao


 altrimenti non conviene
Mmmm... non sarà mica ciò che temo che sia, ovvero un pozzo senza fondo dove 
buttare soldi? :-)
Massimo

 solo perché fa figo?
Se un tuo fornitore ti dice "Fammi un post a questa url, il dtd e` 
questo" non hai tanta scelta, come si dice in Emilia Romagna "lego 
l'asino dove vuole il padrone".
Pero` ho aggiunto anche "e a mio avviso fa bene", perche` si eliminano 
tantissimi problemi di interoperability.
