Attribute Origins

Tokenscript Design
5

You proposed that the two form elements iVal and myValue

 <input type="hidden" name="iVal"/>
 <input type="text" name="myValue"/>

to be referred differently. The former with form-value and the latter with user-input. Because a user-agent would need to observe the initialisation of iVal to do the errand of retrieving an attribute-value that depends on it, while the same doesn't need to be done for user-input, since typically only the final value of user's input is referred to from a transaction occurring as the result of the action.

I wish to address it by showing an example scenario of what I wrote earlier:

This also means we are getting rid of user-entry, since there shouldn't be any difference

  • if you use a form value in the payload for a call to a smart contract to get a value,
  • if you use a form value in the payload for a transaction to a smart contract.

For example, if the action is "purchase" and the orderbook is in a smart contract. The user would type what amount to order and get the estimated price.

<input type="text" name="amount"/>

In an orderbook, the more you want to buy, the worse the price, but there is no way of knowing the price unless you check the smart contract. Therefore, there is an attribute for the price depending on the amount:

<attribute-type id="price"…>
   <origin>
     <ethereum:call function="getPrice">
        <data><uint user-input="amount"/></data>
     </ethereum:call>
   </origin>
</attribute-type>

Let's suppose (apparently) the price is displayed in the view. You are right that only the final value of the user's input is used in the resulting transaction, however, the user agent would do a round of errand every time the value for amount is initialised or changed anyway, and we want to do this through the user-agent, not by bothering developers to write the view calls to smart contracts. Furthermore, this made sure if price is used in the resulting transaction, it is consistent with what smart contract's getPrice() return value, rescuing the user from potential JavaScript meltdown (which might result in 0 in the price.

Hence the proposal not distinguishing between a form-value and a user-input but use form-value across the board.