Eccone uno che ha proprio ragione !!!

Let's face it: the majority of XPage developers will never write their own controls. Their employer subscribes to the "do more with less" philosophy, so they're behind schedule on ten different projects because they're the only Domino developer at their company who hasn't already been laid off. They want components that already work that they can just drag onto a page, set a couple properties, and have the page do what the component descriptions imply they'll do.

Ci sono riuscito, ma perche' complicare le cose semplici?

Le Xpages saranno belle, potenti, ti permettono di fare un mucchio di cose ecc. ecc.
Sarà anche vero, pero' ti fanno pure incazzare !
Premessa : costruendo una view in Notes (senza le X) esisteva l'opportunita' di avere una colonna con delle icone . Bastavano 2 click e una formulina per scegliere l'icona da inserire ed il gioco era fatto.

Ora costruendo una Xpage con dentro un viewcontrol ho avuto bisogno di fare lo stesso ... e mi sono incazzato.
Perche invece dei 2 click ho dovuto scrivere del codice....

A causa dello spostamento del blog l'articolo completo si trova ora qui :
http://www.fabiodipaola.it/2010/11/19/ci-sono-riuscito-ma-perche-complicare-le-cose-semplici/

Webservices

beh, devo dire che fino ad ora e' andata piu' liscia di quanto pensassi : costruire un webservice (provider) in Notes e' stato quasi banale .
A parte qualche dettaglio e' come scrivere un agent (ovvio, non ho usato Java!!) , tutta la parte Soap me la inserisce Domino senza che io faccia niente...adesso giro i dettagli a chi gestisce l'applicazione che dovra' farmi da consumer , vediamo la risposta.
Due consigli:
leggetevi questi articoli
http://www.ibm.com/developerworks/lotus/library/web-services2/
http://www.ibm.com/developerworks/lotus/library/nd7-webservices/
e poi scaricatevi la versione free di SoapUI per testare il tutto http://www.soapui.org/

P.S. poi vi spiego perche Java mi e' antipatico, nulla di personale ma mi e' antipatico proprio

Lotusscript verso Db2 - parte seconda

Una volta connessi al nostro Db2 (vedi post precedente della serie) passiamo a scrivere e leggere i dati , che e' quello che realmente ci serve.
Il primo esempio e' ovviamente quello piu' semplice: costruiamo uan query in SQL , la passiamo al Db2 e poi gestiamo i risultati.


Nelle dim inserisco una dichiarazione
Dim fldLst As New LCFieldList
Cosa significa ? LCFieldList rappresenta un results set che puo contenere uno o piu' record coi relativi campi ed e' il "contenitore" dove vanno a finire i risultati della query .
Poi vediamo come utilizzarla

Primo passo : in una variabile inserisco la query SQL
interroga="select * from schema.tabella where nome='Pippo' order by cognome"
(occhio alle virgolette/apici)
e poi la faccio eseguire , magari controllando che mi ritorni effettivamente dei dati:
If (connect.Execute (interroga, fldLst) = 0) Then
Print "Spiacente, non ci sono documenti che corrispondono alla query "
Exit Sub
End If
Da notare la la parte connect.Execute (interroga, fldLst) dove in pratica chiedo di eseguire la query SQL tramite la LCConnection che ho dichiarato (vedi post precedente) e di inserire il risultato in fldLst.
Nel caso la execute mi ritorni uno zero significa che non ci sono record corrispondenti e quindi avverto ed esco.

Se invece i risultati ci sono lo script prosegue e comincia a ciclarli con un while cosi' strutturato:
While (connect.Fetch (fldLst) > 0)
.....
Wend

ed al cui interno inserisco quello che mi serve: banalmente faccio una print dei dati estratti
Print fldlst.nome(0)
Print fldlst.cognome(0)
dove nome e cognome sono i campi Db2 ritornati dalla query
In pratica l'elemento chiave qui (ed in altri casi simili) e' la classe LCFieldlist , una volta capito il suo scopo e funzionamento si va' via spediti .
Ah, dimenticavo: LCFieldlist contiene ovvimanete degli oggetti di tipo LCField che sono i campi veri e propri della tabella, poi parliamo anche di questi