TokenScript meeting #39

Tokenscript Design
3

Yes, and James Brown proposed a new element for a simple model which I agreed (instead of using distinct as we planned to do with <token>. Here is what he proposed (I called him up today to make sure we are on the same page as of the proposed use of <source>)

First, instead of this:

We should have this:

<ts:card type="activity" name="ownerApproved">
    <ts:source>
        <ethereum:event type="Approval" filter="owner=${ownerAddress}">
    </ts:source>
    <ts:item-view xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
        <style type="text/css">&style;</style>
        <script  type="text/javascript">&item-view-ownerApproved.en;</script>
    </ts:item-view>
    <ts:view xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
        <style type="text/css">&style;</style>
        <script  type="text/javascript">&gaveApproval.en;</script>
    </ts:view>
</ts:card>

Notice that he used the word source and I'll go along with him for now (whether or not we consistently use source or origins is a separate topic).

Now, what to do with the JavaScript API? Remember we never standardised the JavaScript API, thinking that we first must fix the XML schema. We had some thinking on card property 9-meetings ago, like this:

web3.card.setProps({
			nodeRefs : namehash.hash(this.props.fullName)
		}, function(error, tokenProps) {
                ... view update code ...
               });

I propose that sourced data is accessed throught .source insetad of .props. That is, if without using React.js, it would look like this:

const {from, to} = web3.card.source; // does the job of line 75-90

Now let me reason why card.source is not card.props. There are 2 reasons.

1. The same thinking can be applied for <input> and <output>

So we might have card.input[0] and card.input[1] at the same level as card.source. The same goes for constructing card.output albeit more complicated. There are just not enough namespace to hold data from 1st input, 2nd input and output all under .props.

2. structured data probably should be treated differently than card variables

when it comes to sourcing data from a module (in this case an event), the structure is tree-like and not flat like how <ts:attribute> used to work. For example, imagine you have an event that represents a vote, you might have structures like this as card.source (reëncoded in JSON for the convenience of discussion)

{
    "author": {
        "name": "Weiwu",
        "address": "0x808735070620485"
    },
    "representitive": {
        "name": "James Brown",
        "address": "0x8093804230437ac"
    }
}

Which gets you stuff like card.source.author.name and card.representitive.name, unlike the traditional arrangement of attributes.

Now having explained the JavaScript API and XML schema proposed, let me propose card to be the top level. That is:

    const {from, to} = card.source; // does the job of line 75-90

Instead of

    const {from, to} = web3.card.source; // does the job of line 75-90

As of why card is top-level, let's not forget we are talking about how to code JavaScript in a TokenScript card, not how to access TokenScript card from a website. In this context, JS works in a special environment, card serves a similar purpose of window of a website, and developers have to worry about an already-existing global variable also going by the name card inherited from the website. Whereas web3 was designed to be called directly and we may still choose to provide API to websites under web3 namespace (and continue to use 'web3.token' if we like).