Adesso sono alle presse con un'altro problema: la spedizione.
Ovviamente, la stessa maglietta, spedita in diversi paesi, avra' un costo totale diverso a secondo del paese scelto. Spedire qualcosa in America mi costa piu' di spedire lo stesso oggetto in Australia, no?
Da un punto di vista puramente HTML, questo non e' un grande problema, basta avere un select (cosi' si chiamano le liste in HTML). Ogni voce della lista contiene il nome del paese... e potrei settare il costo di spedizione come il VALUE di ogni voce. VALUE e' come un campo nascosto nelle liste HTML.
In pseudocode, la cosa viene fuori cosi'
select
option (value="$x.xx")America
option (value="$x.xx")Australia
option (value="$x.xx")Andorra
/select
(devo usare pseudocode altrimenti mi viene fuori una lista vera e propria. So che c'e un tag HTML che rende tutto come testo ma non la ricordo adesso).
Quando l'utente clicca sul pulsante di SUBMIT, il VALUE della OPTION scelta va passato al server del shopping cart e basta. Abbastanza semplice.
Allora, il problema si presenta se qualcuno sceglie di comperare piu' magliette.
Ovviamente, cinque magliette messe insieme non pesano lo stesso di tre magliette individuali, perche' la busta e una sola. E poi', il costo di spedizione fa un "gradino" all'inizio (la differenza tra spedire niente e spedire qualcosa che pesa anche un solo gramo) e poi, questo "gradino" diventa piu' sottile con ogni incremento di peso.
Dunque, il problema diventa: come calcolare la differenza in peso (e costo di spedizione) per diversi paesi con accesso al solo HTML, linguaggio stateless. Il carrello mi permette un prezzo di spedizione, e UN prezzo per ogni item aggiuntivo. Ma quando il prezzo per oggetti aggiuntivi varia a secondo del paese... capite? Dovrei potere calcolare i costi di spedizione prima di pasare al carrello, ma l'HTML non permette i calcoli matematici.
Una soluzione sarebbe avere una seconda lista, tipo
America: 1 magliette
America: 2 magliette
America: 3 magliette
Australia: 1 magliette
Australia: 2 magliette
e cosi' via dicendo, ma sarebbe una cosa goffissima. Mi fa schifo al solo pensarci.
Potrei risolvere la cosa subito con uno scriptino JavaScript, ma a secondo dei settaggi di sicurezza del browser del client, lo javascript potrebbe tirare fuori un warning e non eseguire. E penso che molta gente (io compresso, per carita') sia paranoica di un sito sconosciuto che tira fuori i warning di sicurezza. Per'altro, la maggior parte del pubblico fa gli acquisti online utilizzando i PC del loro ufficio, dunque e' quasi scontato che i setting di sicurezza dei loro browser sarano piuttosto alti.
Sto studiandomi il discorso PHP (mio host permette pagine php) ma c'e' il problema che, finche l'utente non preme il pulsante di SUBMIT, non si sa (informaticamente parlando) che cosa sia sulla pagina. Forse posso creare una funzioncina con PHP che venga chiamata dal pulsante di "Buy", e che questa funzioncina esegua il SUBMIT. Ma che palle, pero'..!
Dunque oggi vado in biblioteca per vedere se c'e' qualche manualone di PHP. I tutorial online, compresso quelli delle php.net (sito ufficiale) non sono molto chiari. Tutti presumono un'accesso al server (ovvio: e' un linguaggio per server). Ma il server al quale devo accedere con tutti i costi giusti e' quello di PayPal. E non posso modificare niente sulla loro pagina.
Potrei avere una pagina tra il pulsante di SUBMIT e il sito di PayPal, ma se il cliente ha una connessione dial-up (molto comuni qui) il potenziale compratore si trovera', perplesso, davanti a una pagina vuota, aspettando di essere ridiretto al carrello. Neanche quella e' una bella soluzione, anche con tutti gli "attendere, prego" del mondo. E poi c'e' gente con paranoia dei redirect.
Qualcuno (Marco?) ha delle idee/suggerimenti/consigli in merito? Il mio webhost mi permette anch gli script in Perl, un'altro linguaggio per me sconosciuto. Niente ASP, purtroppo.
Ciao,
Vince.
Subscribe to:
Post Comments (Atom)
3 comments:
Usando solo html e rinunciando a linguaggi di script server e client credo che non ci siano grandi soluzioni oltre a quella (oggettivamente poco professionale) che hai descritto.
Io comunque farei così (come ho visto su altri siti), utilizzando un minimo di codice lato server:
metterei una textbox per il numero di magliette e una option per la destinazione, con un avviso "I costi di spedizione verranno calcolati in base al numero e alla destinazione. Premere "submit" per continuare, sarà possibile confermare la scelta successivamente".
L'utente inserisce le sue 15 magliette da spedire in Europa e preme "submit". Tu posti la pagina ad una tua pagina dove ti fai la moltiplicazione o cos'altro (anche senza asp non dovrebbe essere molto difficile una cosa così), visualizzi una pagina con scritto "Confermare l'aggiunta al carrello di 15 magliette per importo complessivo di 3$ + 1.000$ di spedizione?" e un campo hidden in cui inserisci il valore da postare al carrello.
Io conosco solo asp, ma, ripeto, dovrebbe essere una cosa facilmente fattibile per qualsiasi linguaggio. Il codice asp è il seguente (so che non lo puoi usare, ma magari te lo puoi fare tradurre da qualcuno...) e come vedi bastano 10 righe:
<%
if request("numero_magliette")=1 and request("destinazione")="europa" then
prezzo=1000
else
'Tutte le condizioni che vuoi
end if
%>
<html>
<body>
Confermare l'aggiunta di <% = request("numero_magliette") %> magliette per l'importo di <%= prezzo%>?
<form action="carrello.asp" method="post">
<input name="importo_tot" type="hidden" value="<% = prezzo%>" />
<input name="submit" type="submit" />
</form>
</body>
</html>
Così eviti il redirect con la pagina bianca, dai all'utente la possibilità di controllare il prezzo totale prima di metterlo sul carrello, e puoi inviare al carrello i dati completi.
Altre idee non ne avrei (a parte appunto quella di usare un minimo di javascript sul client)
Alla fine ho capito che e' solo sul lato CLIENT che JavaScript genera dei warning. Cioe, se io scrivo una pagina HTML con un qualsiasi script, e lo lancio sul mio PC (attivita' tipica di sviluppo), vengono fuori i warning.
Se servo la pagina dal server, no.
Dunque, il problema si e' risolto con un JavaScript molto modesto.
Il problema che affronto ADESSO, pero', e' questo. Il carrello della PayPal e' fatto per funzionare una chiamata alla volta.
Mi spiego... (parentesi... puoi passare un prezzo di spedizione e un prezzo aggiuntivo al server) Dunque, se uno compra DUE magliette modello "tale" con prezzo iniziale di spedizione di (metti) 10 e prezzo aggiuntivo di 2, allora tutto funziona. Il carrello segna un costo di spedizione di 12. Cioe, i 10 iniziali e i 2 aggiuntivi. Se compra TRE dello stesso modello, il prezzo diventa 14. 10+2+2.
Il problema avviene quando uno sceglie 2 magliette di modello "tale" e 1 maglietta di modello "quale". Il prezzo diventa 22 (10+2+10)! E questo e' inacettabile. PayPal mi ha gia' detto, fondamentalmente, che la vita e' cosi' e che loro non hanno una soluzione.
Posso utilizzare PHP e un DB MySQL (un DB un po' gioccatolo, se sei abituato ad Oracle, ma lasciamo stare) e cosi' potrei tenermi in pancia tutte le tranzazioni finche l'utente non decide di comprare. Cosi', PayPal diventa un "checkout" piuttosto che un "carrello".
L'unico problema e' che, come non ho controllo sul server PayPal, non ho come sapere se l'utente ha veramente comprato qualcosa o se ha cambiato di parere all'ultimo istante. Non lo so finche non mi sveglio il mattino dopo e trovo la mail (ordine di acquisto) di PayPal nella mia casella. Nel fratempo, l'utente troverebbe che, se volesse fare ulteriori acquisti prima che io bonifichi la situazione *manualmente*, il carrello e' gia' pieno con l'ordinazione precedente. Certo che se potrebbe fare una regola ferrea dove appena premi SUBMIT, il record del DB viene azzerato (o comunque flaggato) ma mi pare una soluzione poco robusta.
Ci penso ancora...
Di solito queste cose vengono fatte con variabili "Session" o con i cookies, se vuoi che il carrello sopravviva all'uscita dell'utente dal browser. Il DB mi sembra una soluzione un tantino scomoda per questo... comunque buona ricerca!
Post a Comment