Newsgroup: it.comp.os.dibattiti
Titolo: [OT] Oracle*Forms ed altro.

Mi pare d'aver capito, dalle passate discussioni, che alcuni qui
hanno, o hanno avuto, a che fare con le famigerate Oracle*Forms.
Io ho da poco scoperto l'esistenza di una API di Oracle che permette
di maneggiare in Java i file .fmb dei sorgenti delle Form, e mi
chiedevo quanto potesse essere utile/praticabile realizzare un tool, o
set di tools, che permetta di convertire una Form in qualcosa di più
moderno e mantenibile (io pensavo a Grails/Groovy).
Ho già fatto qualche esperimento, ma mi interessava sapere se e quanto
un simile giocattolo sarebbe di interesse per qualcuno. So per certo
che ci sono soluzioni commerciali (e costose...) che permettono di
fare qualcosa del genere, che producono progetti J2EE o maschere
Swing.
Commenti? Critiche?
Saluti
Raffaele

 moderno e mantenibile (io pensavo a Grails/Groovy).
Il problema non e` quanto sia utile, il problema e` convincere il
cliente ad abbandonare quel cesso di Oracle*Forms per qualcosa di piu`
moderno e manutenibile (e.g. un Grosso cliente della ditta per cui
lavoro ci ha chiesto e ci continua a chiedere espressamente Oracle*Forms
per un progetto)
Enrico

 per un progetto)
Beh, io ho sentito voci secondo cui tempo addietro era stato
ipotizzato un port dei nostri applicativi da Oracle*Forms a Java, ma
che non se n'era fatto nulla a causa dei costi eccessivi in termini di
tempo e budget (il nostro cliente è Carrefour Italia).
Avendo qualcosa (ie.un tool) in grado di abbattere i costi di porting
automatizzando quantomeno in maniera grezza il processo, senza costare
uno sproposito (ho trovato un tool che fa esattamente questo, ma che
costa 10.000$....), l'operazione sarebbe realizzabile in con una
quantità finita e ragionevole di tempo e denaro.
Raffaele

E' un lavoro assolutamente inutile .... le applicazioni forms possono 
essere deployate in oracle application server e rese accessibili via web 
.... fa gia tutto la oracle.... che senso ha farlo pure tu ?
ciao
PP
raffaele...@gmail.com
 ha scritto:


 
raffaele.casta...@gmail.com
 ha scritto:
gnem..non ci siamo capiti.
Le oracle forms vengono deployate su Oracle AS, e servite come applet
sul client.
Io parlo di convertire un'applicazione esistente in qualcosa di più
moderno, e buttare le forms.
1) le form sono sostanzialmente delle applet, ed usano un runtime
(JInitiator) diverso dal JRE SUN.
2) lo sviluppo delle forms, e credo chiunque le abbia usate possa
confermarlo, è un palo nel cu*o
3) PL/SQL nei suoi tempi d'oro poteva essere un linguaggione, ma oggi
è parecchio superato
4) form*builder fa abbastanza cacare
5) lo sviluppo e manutenzione delle forms è un processo tedioso, prono
ad errori, ed apportare modifiche apparentemente semplici viene reso
difficile dai limiti della tecnologia stessa, e dai limiti
dell'ambiente di sviluppo.
Raffaele

beh però devi considerare 2 cose ... economicamente esiste gia una 
soluzione per deployare le forms su intranet .... e poi .... a quanto si 
sente in giro forms e report sono prodotti che dovrebbero andare a 
morire ....


Non è questione di deployarli in una maniera piuttosto che un'altra.
Si tratta di avere una form convertita in qualcosa di umanamente
mantenibile, sulla quale poter avere completo controllo, che possa
venire sviluppata usando degli strumenti moderni e degni di questo
nome, che possa essere versionata in maniera decente, etc etc.
Le voci riguardo la possibile estinzione delle forms sono la causa/
conseguenza delle brutture che le caratterizzano. Oracle ha un
interesse limitato a mantenere e migliorare le forms, ed i relativi
strumenti, quindi chi può le evita.
Ma in prospettiva della morte delle Forms, è opportuno iniziare a
premunirsi per essere in grado di abbandonare la nave al momento
giusto. Altrimenti ci si ritrova ad avere un immensa quantità di
forms, male o per nulla supportate da Oracle, che finiranno per essere
rattoppate per anni, mentre il resto del mondo o quasi si aggiorna a
tecnologie più efficaci e moderne.
Anche perchè le Forms saranno anche moderatamente utilizzate in giro
per il mondo, ma non possono contare sull'immensa base di utilizzatori
che hanno certi "linguaggi morti" come il COBOL.
Arriverà certamente il giorno in cui queste forms andranno gettate
alle ortiche, quindi perchè non cominciare a pensarci fin da ora, e
cercare una soluzione poco costosa (open source, free, etc, dato che
soluzioni più o meno valide esistono già in campo commerciale), che
semplifichi il più possibile questo passaggio?
Ora, non dico di sviluppare una scatola magica che mangi forms e cachi
%your-preferred-technology-here%, ma almeno un qualcosa che
"predigerisca" una form in modo da poter poi portare a termine il
lavoro "a mano" senza impiegarzi un secolo e mezzo.
Raffaele

 tempo e budget (il nostro cliente è Carrefour Italia).
Forse non mi sono spiegato. Il problema non sono i costi, ma il grado di
conoscenze del cliente. Ovvero, quel cliente vuole solo e soltanto
Oracle*Forms, e nient'altro (da quello che so, solo ora si stanno
timidamente aprendo a JSP)
Enrico

 timidamente aprendo a JSP)
Forse non mi sono spiegato neanche io... il _cliente_ aveva tempo
addietro ipotizzato la conversione degli applicativi (o parte di essi)
su piattaforma java, ma aveva abbandonato l'idea in seguito alle
proiezioni troppo esose in termini di tempo e denaro.
Del tipo "convertire 1000 forms e tutto il resto costa 100 e richiede
365 giorni uomo", con il cliente che risponde "no, è troppo, lasciamo
perdere".
L'idea che espongo io è che avere un tool, o un set di tools, che
permetta di poter dire "convertire 1000 forms e tutto il resto costa
50, e richiede 170 giorni uomo" potrebbe aiutare a portare a casa il
lavoro.
So bene pure io che in molti casi il cliente "vuole esattamente
quello". Ma in molti altri casi il cliente dice di no semplicemente
perchè non vuole spendere più di tot, e vuole avere il lavoro finito
entro tot mesi. E credo sia lapalissiano che avere tool in grado di
facilitare una conversione come quella di cui parlo permetterebbero di
ottenere esattamente questo.
Per dire, senza tools la conversione manuale comprende punti tipo:
  - creare la parte di accesso al DB
  - riscrivere da zero le pagine
  - riscrivere da zero la logica contenuta nelle form
  - etc etc vari altri step
Ogni singolo step che si riesce ad automatizzare, del tutto o in
parte, è tempo risparmiato, che può contribuire a rendere più
"appetibile" l'offerta.
Cose decisamente fattibili (nel senso, ho perlomeno qualche vaga idea
su come potrebbero funzionare):
- generazione delle pagine a partire dal layout delle form, anche in
formato grezzo, da rifinire a mano
- generazione del mapping delle tabelle, e delle relative classi di
dominio
- strutturazione del contenuto della form in un formato che ne
faciliti la conversione "manuale"
Cose più complicate da realizzare (dal mio punto di vista):
- conversione automatica e completa del PL/SQL contenuto nelle forms
- creazione "intelligente" delle pagine, in modo che rispecchino il
layout originale
- strutturazione di molte forms (centinaia) in una struttura coerente,
stabile, comprensibile e manutenibile.
Spero di essermi chiarito..
Raffaele

Beh il mio dubbio č perchč farlo tu quando 99 su 100 gia Oracle lo sta 
facendo o pensando ....

 facendo o pensando ....
Qualche notizia riguardo azioni da parte di Oracle in tal senso?
Io a parte sentire voci da parte di alcuni nomi di Oracle riguardo la
futura "morte" di Oracle*Forms, non ho trovato nulla che faccia
pensare allo sviluppo da parte di Oracle stessa di soluzioni per la
migrazione delle forms stesse...
Comunque, un certo Tugdual Grall (gh!) mi ha proposto di scrivere un
piccolo articolo a 4 mani sull'uso di JDAPI da pubblicare su Oracle
Technology Network, per vedere se e quanto l'argomento "forms" è
ancora di interesse per qualcuno.
Una volta tastato il terreno sul sentimento degli sviluppatori
riguardo le forms, si può poi vedere su vale la pena proporre lo
sviluppo di tool più "nuovi" per le forms, o addirittura il tanto
sofferto "port".
Saluti
Raffaele

 proiezioni troppo esose in termini di tempo e denaro.
Ok, in quest'ottica si, potrebbe essere una buona idea (anche se,
attualmente, per noi non sarebbe molto utile, in quanto l'unico cliente
che ci chiede Forms non e` intenzionato per ora a cambiare)
Enrico