Newsgroup: it.comp.www.asp
Titolo: ActiveX ed ASP --- commercio elettronico

Ho creato con VB un ActiveX "Commercio" con all'interno tre moduli :
 - articolo
 - Carrello
-  Fattura
Ebbene: Carrello è costruito come una collection di articoli più qualche
variabile (data, ora)
Ho creato un metodo Carrello.add che aggiunge un articolo al carrello
*Con Visual Basic ho testato il tutto e funziona egregiamente.*
Quando uso ASP cominciano i problemi. Le seguenti righe di codice :
dim ArticoloDLL
dim CarrelloDLL
set ArticoloDLL=server.createobject("Commercio.Articolo")
set CarrelloDLL=server.createobject("Commercio.Carrello")
ArticoloDLL.id     = 1
ArticoloDLL.Nome   = "Nome"
ArticoloDLL.Prezzo = 12000
ArticoloDLL.Pezzi  = 10
ArticoloDLL.Tipo1  = "Tipo1"
ArticoloDLL.Tipo2  = "Tipo2"
CarrelloDLL.add ArticoloDLL
Generano un errore del tipo: "Type mismatch" alla riga 'CarrelloDLL.add
ArticoloDLL'
Sembra che ASP non riconosca la variabile Articolo come di tipo
Commercio.Articolo
Da cos apuò essere causato tutto ciò? Grazie Martino

 Da cos apuò essere causato tutto ciò? Grazie Martino
devi dichiarare il parametro come variant., e non come Commercio.Articolo,
cioe':
function add(articolo AS VARIANT)
gli unici TIPI di dati passabili sono variant.
Poi all'interno della function lo puoi trattare
tranquillamente come un oggetto di classe articolo.
Provare per credere.
F.

function add(articolo AS VARIANT)
Oppure definire alcune variabili come globali (i dati dell'articolo):
Global ID_Articolo as Integer
Global Nome_Articolo as String
Global Prezzo_Articolo as Currency
Global Pezzi_Articolo as Integer
Global Tipo_Articolo as String
e quindi richiamare la funzione:
CarrelloDLL.add
senza alcun parametro.
Definendo una variabile come globale, la stessa può essere richiamata
direttamente all'interno della function (o sub) senza doverla
nuovamente "passare".
Questo metodo (peraltro logico) l'ho utilizzato per realizzare il
componente "Un'oggetto COM per la visualizzazione dei database"
pubblicato anche su 
www.aspitalia.com
:
http://www.aspitalia.com/articoli/db/mdb2html.asp
Dove le variabili definite globalmente sono quelle relative ai
settaggi delle tabelle e relativi colori che vengono impostati
solamente all'inizio (o quando si vuole) rimanendo tali sino alla fine
o sino a quando non vengono nuovamente modificate.
Mariotti Michele

 nuovamente "passare".
[cut]
Definire una o piů variabili in modo che si abbia ad esse un accesso globale
da parte di tutti i metodi degli oggetti istanziati, č sicuramente una
pratica da sconsigliare vivamente in tutti i casi in cui si possa proporre
un'alternativa, il che significa, per quella che č la mia esperienza
personale, quasi in ogni caso..
Ale
--
Alessandro Riolo,
Sen s.r.l., Responsabile delle risorse tecniche
www.sen.it

 ArticoloDLL'
La soluzione suggerita da Francesca in
news:r3l07.28512$
u%1.23...@news1.tin.it
 (utilizzo di Variant) è senz'altro
valida, gli script engine istanziano gli oggetti a runtime, non essendo
ovviamente compilati, quelli della MS utilizzando una tecnica da loro
chiamata late binding (o associazione tardiva); ora utilizzando il
visualizzatore oggetti per curiosare, ad esempio, nella libreria ADODB 2.6
(quantunque le altre versioni dovrebbero avere la stessa interfaccia),
poniamo il caso della classe Recordset, si può notare come la maggioranza
dei metodi e delle proprietà abbia come parametri i tipi standard (i vari
String, long, boolean e così via della piattaforma VB), e tra questi
dovrebbero fare all'uopo sia Variant (che internamente è implementata come
una union del linguaggio C, cfr. Inside DCOM degli Eddon, MS Press), ma
anche Object (in effetti la proprietà Recordset.ActiveCommand è implementata
come Object) ed è sempre possibile il ricorso ad IUnknown (che btw è
scarsamente documentato per la piattaforma VB, se non erro c'è qualcosa in
Hardcore VB e nel Balena, entrambi MS Press).
Ora Variant abbiamo detto essere una union, e fra i suoi membri ha la
possibilità di indirizzare variabili di tipo Object, che sono
(documentazione VB alla mano) "indirizzi di 32 bit (4 byte) riferiti a
oggetti", cioé veri e propri riferimenti, praticamente puntatori :-)
Quando si definisce un oggetto come Object, quest'oggetto è associato
tardivamente, a runtime, perciò non è spesso conveniente usare Object quando
si passano parametri, tranne che se uno volesse utilizzare quel componente
COM da un linguaggio di scripting, dove tutto è istanziato appunto con
associazione tardiva.. ora in verità il tipo Object, come tutto in COM,
deriva da IUnknown, per cui se uno volesse togliersi un altro po' di
overhead potrebbe essere tentato di definire così i parametri, però questo
non è documentato/supportato, almeno nella piattaforma VB, il che implica
che probabilmente è meglio limitarsi ad Object, se uno non è preparato ad
affrontare tutte le possibile evenienze ;-)
Ecco un piccolo esempio di cosa si può fare, se non vi spaventano i
side-effect e se scavalcare i muri della tipizzazione "forte" (;-p) di VB
non vi spaventa:
Private Function a (ByRef b As Object) As IUnknown
    Dim c As IUnknown
    Set b = New ADODB.Connection
    Set a = b
End Function
Se vi siete fatti prendere dalla curiosità, ed invece di Recordset vi siete
andati a vedere la classe Command, e l'occhio vi è caduto sulla proprietà
ActiveConnection, sì, e proprio vero, ritorna un oggetto di tipo
Connection.. e come fa? tutto il discorso di prima sul late binding era
forse campato in aria? no, solo che quell'oggetto ritornato da
ActiveConnection è in realtà di tipo String, ma questa è tutta un'altra
storia, e questo post sta diventando un trattato :-)
Ale
--
Alessandro Riolo
