You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user I want to pass a complex parameter as an object when calling contract entrypoints so that I don't have to format flat list of parameters one by one without annotations.
Background
When calling a smart contract entry point having a complex parameter, even with the abstraction over the Michelson syntax, it might be hard for the user to write the parameters.
We would have two implementations that have the same purpose. The difference would be that they accept a different parameter format and the users could choose between their preferred one. We could deprecate the methods member in the future if there is more enthusiasm over the new methodsObject member.
The same logic as the one used for the storage parameter when deploying a contract is used, i.e.
the keys of the object are the annotations or indexes when the Michelson type does not contain annotation. Note, this is the same logic as the one used for the storage parameter when deploying a contract is used.
See details: #840
Acceptance criteria:
Add a new property on the ContractAbstraction named methodsObject that accepts an object with annotations and indexes.
Use EncodeObjectMethod that is also used for the storage
Update documentation to include this new method.
The text was updated successfully, but these errors were encountered:
As a user I want to pass a complex parameter as an object when calling contract entrypoints so that I don't have to format flat list of parameters one by one without annotations.
Background
When calling a smart contract entry point having a complex parameter, even with the abstraction over the Michelson syntax, it might be hard for the user to write the parameters.
We would have two implementations that have the same purpose. The difference would be that they accept a different parameter format and the users could choose between their preferred one. We could deprecate the methods member in the future if there is more enthusiasm over the new methodsObject member.
The same logic as the one used for the storage parameter when deploying a contract is used, i.e.
the keys of the object are the annotations or indexes when the Michelson type does not contain annotation. Note, this is the same logic as the one used for the storage parameter when deploying a contract is used.
See details: #840
Acceptance criteria:
The text was updated successfully, but these errors were encountered: