| Contracts are currently rendered via React, i.e. by client-side DOM manipulation. That's necessary in the WebExtension wallet, as in a web extension we don't have any server to render stuff for us ;-) We could of course also use this code in the the merchant backend HTML page, but that drags in a lot of dependencies (well, mainly React.JS) that we might not want. It also wouldn't work without JavaScript anymore. | |
| I understand that this won't work with JS anymore, that's why I suggested this as a temporary / quick fix (which means additional dependencies can also be OK). I don't think we'll have the time to do a proper (!) and fully equivalent MUST-based rendering for 0.8, and I don't think we want to show the raw JSON or _nothing_ for 0.8. So temporarily dropping in a JS-based solution seemed like an acceptable trade-off. | |
| I don't think this is viable, because the wallet's rendering of the contract terms is very minimalist right now. The functionality we get from (temporarily!) integrating the JS code in the merchant backend HTML page isn't justified. It would be more effective to pass the contract JSON into the mustache template. The mustac library can do this for another JSON library already (json-c): https://gitlab.com/jobol/mustach/-/blob/master/mustach-json-c.h I'll work on making jansson work with mustach. | |
| Putting this on feedback as the following questions are open: 1. Do we really need the label mechanism in the contract terms, or can we inline labels for better rendering, and introduce a tag for a "URL location" 2. The "Location" definition seems incomplete, shouldn't we at least have additional "free form" address lines? 3. What parts of the contract terms should be rendered on the page? Should we really list auditors/exchanges and h_wire? Is the following list enough? * summary * amount * product list (with pictures if available) * merchant information should probably be enough? | |
| I would allow seeing auditors/exchanges and locations via buttons to 'expand' certain details (similar to what we used to do in some wallets). [That is, if JavaScript is enabled. So maybe if JS is off, show everything, if it is on, hide certain details behind buttons to 'expand']. | |
| working on this. the page should work with and without js so i will do a build time rendering. | |
| there is a full react html page that mimic the same design in merchant-backoffice repository (https://git.taler.net/merchant-backoffice.git/tree/packages/backend) we can iterate the design there and new version will be deployed with the merchant backend as the spa.html mustache placeholders are kept for server side rendering one last step is missing: i need help updating the Makefile.am to correctly copying from the merchant-backend submodule to the merchant distribution folder :) | |
| To discuss this with Belen, it would be best if you could (manually) create a full-featured contract (JSON with _all_ the optional fields set to something) and had an easy way to render this contract with your page in a browser.... | |
| I've attached some design suggestions. I agree with Florian that rendering all the items in the contract terms is probably not necessary. I've kept things quite simple as a starting point. sample_for_the_other_pages.png (49,291 bytes) order_details.png (83,556 bytes) | |
| Full-contract page (with selective disclosure) is used in the following contexts: 1. Merchant SPA 2. Web Extension 3. Android Wallet 4. Merchant backend order status page (untrusted, possibly without JS). | |
| Here comes a version 2 showing all the information in the contract except 1) nonce (I didn't think this should be included. Let me know if I am mistaken) and 2) product image (it seems somehow out of place, and I rather keep the page as simple as possible). The approach iI followed was grouping items into logical headings, and roughly sort those headings based on their interest for the customer. | |
| implemented in 62f34bf4 | |
- Anonymous