Hi Paul:
Thanks for your detailed response. Please see below:
On 4/19/12 1:45 PM, madppiper wrote:
Hi Ruth,
thanks for the great feedback :)
To answer your questions, I think you got a mixup in the paypal integration
there. Without going over the details, I would recommend to implement paypal
the following way:
This is pretty much how I do it. I didn't change any of this part of
OFBiz OOTB. Only thing I do differently is always make the buyer go
directly to PayPal anonymously (with a OFBiz loginId of "anonymous").
Then, when the IPN returns satisfactorily, I create the login account -
or not - if they already have a userLoginId. Creating the account isn't
the problem. It is the email notification that tells the user how to
access the account. If the email isn't sent because myofbiz.com is
blacklisted or if the PayPal email account id (an email address) is no
longer valid, the user never gets the email and thus never gets any info
about the order or how to login.
It gets really sticky when the buyer's PayPal email account Id is no
longer a valid/working email address. That is because I have no way to
contact the buyer - at all.
So, for the very few times (I think 3 times) this has happened, I'm not
sure it is worth making everyone create an account before the pay.
* Create User (use his paypal-eMailaddress in your form, you can prefill
paypal with this, btw)
* Create Order (needed for paypal processing anyhow)
* Forward user to paypal (do handshake and all that in the background,
depending on the implementation i believe you have to create a session?!)
* Deliver paypal with a return url, pickup orderId with it, complete order;
handle paypal status
* Use email-Address to provide customers with a way of accessing the site
and to provide them with an order status.
I don't think there is much of a workaround otherwise, since you will
require to create an order, which requires a user to be set up. If you want,
contact me directly, and we can discuss it there in detail. Paypal, however,
only allows two ways of implementation: by iFrame, or by a full redirect, so
it leaves you with a limited amount of choices...
Thanks for the offer. Wish you had made that about a year ago. I did
eventually figure all this out. Not without many hours of trial and
error and I even figured out how to use the PayPal sandbox to great
effect. Its a wonderful thing once you know how to use it.
About the product caching: it is not entirely true. See, the problem with
the original eCommerce App is completed without performance in mind. If i
recall correctly: Take the category screens for instance, which really on
the large product widgets. If you look more carefully, you will notice that
the widgets include a multitude of groovy files and so does the category
widget. The reason being, that it was designed by reusing some already
available groovy script that takes care of the actual data (some were
chained because one delivers some informaton that is needed by another). The
problem is, that groovy scripts are not handled in a global manner, but you
iterate over them every time, just for data preparation. So yes, with
caching you can somewhat control the database queries, but the groovy
scripts for actually accessing the data are going to be called either way.
There are many obstacles like this and there was alot of room for
improvement ...
Ah...I am aware of the limitations of Groovy scripting in the context of
the screen widgets. But I didn't realize it is such a drain on
performance. So, in your implementation, does Solr replace all the
Groovy scripts related to retrieving product info from the database? If
so, that is a wonderful thing.
The books are going to be our own little secret, but you can be sure they
are your perfectly legal to download - have fun :)
Will do! And thanks so much for taking the time to respond.
Cheers!
Ruth
Cheers,
Paul
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Free-Audio-Books-powered-by-OFbiz-tp4564360p4571645.html
Sent from the OFBiz - User mailing list archive at Nabble.com.