Even better, we add a state cart and party is required for all other states.
The cart state can be set only programmatically and not by user interface.
2 Likes
Hi,
you can have a look to an e-commerce frontend using tryton as backend here: https://surfshop24.de/
I plan to open source it. A first review was done by @udono.
I wrote one single module for tryton exposing an API to the frontend to simplify and standardize the communication between tryton and a class using this API from cherrypy (or flask with little rewrite). I used cherrypy because of the awesome default()-method, which lets you implement a dynamic routing.
The module sale.sale is used as cart. Like @ced stated: calculating shipments, coupons, pricelists etc is already implemented in this module. I use a dummy_party, which is used for anonymous users. So you can define all defaults on this dummy user. There is also a relation to this dummy_party or a different one on country.country to calculate shipments on country change in payment integrations (f.e. paypal has a callback to your system if user changes the delivery address). This resolves a practical problem: in most cases the final customer is known after checkout, because buying as guest using external payment services is the most used way to shop this days.
The frontend uses product data cached in redis on create/write in tryton. A fulltext search is implemented using solr (after using whoosh first - to slow).
I decided to handle all the payment workflow in the frontend and on success I use the payment modules of tryton to store the result.
About the frontend: I use cameleon templates and a minimal set of javascript because I donât like this dependency juggernaut of javascript frameworks this days. All is done with a masterpage an about 10 small templates filling slots in the master.
One of the hard things to manage are caching policies. I try to minimize callbacks to tryton for performance gain. So one thing you have to deal with is cache handling and define smart triggers to invalidate/rebuild them.
I appreciate further discussions.
1 Like
I do a matching if user buys as guest to avoid a lot of duplicates - and if not there is already the module to merge them. A script to find possible duplicates would be nice for better data quality.
I like the âdummyâ concept more since there are a lot of functionalities in sale bind to the presence of a party. Creating a party before the confirmation/payment of the sale will bloat the database with trash and should be avoided regarding GDPR
I checked this integration and its nice. But I decided to a run the workflow of the payments until confirmed in frontend for the following reasons:
- it is faster
- there are sdk for them and so no need to bloat tryton
- it is more easy to handle the design and configuration side by side with the frontend
I only store the credentials in tryton so the shop owner can change them. I also have a bool for each one inside tryton for switching between live and sandbox mode.
FYI, I just uploaded a work in progress of vue storefront integration on Issue 9010: Integration with vue storefront - Tryton issue tracker
It is just the task to fill the elasticsearch with product, category and attribute.
1 Like
I havenât seen any images management on the review. How dou you plan to manage them?
Vue Storefront expect an URL pointing to the image, so I went with a predefined schema using SKU (aka code). So user will have to ensure a correct is deliver at this URL. Of course the schema can be overridden.
I think it is will be wrong to deliver those images from Tryton because we want speed on such delivery (and even CDN). So this will be better managed by a proper web server with static content.
There is also an optional media_gallery attribute which is not filled by default. This will be left to custom implementation (or for sub-module).
1 Like
Hi
What exactly does this module do?
It fill the elasticsearch and implement routes required by VueStoreFront.
Thank you.
What does this mean? I am sorry, but what is meant by elasticsearch and what is meant by implement routes required by VueStoreFront?
Does it mean a customer can connect to Tryton and he/she will only see their information?
These are the things that Tryton needs so that it can be used as a backend for Vue Storefront.
Not quite, it means that with this module you can use Tryton and Vue Storefront to create a web shop that customers can use to buy things from you.
Thank you. I considered Prestashop before, but our need for ecommerce is more for existing customers, to just place sales order, and not really doing online buying like retail business.
Its seems this is a better option then?
Yes, once complete I think this would be a good option.
1 Like
Wouldnt it be just easier to create those customers as a special type of user that can only see functions like sales order and debtor statement for his own account(s)? Not sure if this is possible to restrict a user in thia way?
Yes, this is managed by the web_user module and this module is used on the e-shop modules.
Is the implementation dependent on ElasticSearch?
It is a requirement of VueStorefront, so yes.