Added a contract constraints section to the key concepts doc. (#1704)

Documentation for contract constraints.

Added to index.

Review fixes round 1.

More review fixes.

Review fixes.

Explained package contents.

review fixes.

Addressed RGB's final review comments.

Updated source code type to 'java'
This commit is contained in:
Clinton
2017-09-30 13:10:58 +01:00
committed by Clinton Alexander
parent 659b447362
commit fee156cc4a
2 changed files with 9 additions and 9 deletions

View File

@ -15,7 +15,7 @@ A typical constraint is the hash of the CorDapp JAR that contains the contract a
include constraints that require specific signers of the JAR, or both the signer and the hash. Constraints can be
specified when constructing a transaction; if unspecified, an automatic constraint is used.
A ``TransactionState`` has a ``constraint`` field that represents that state's attachment constraint. When a party
``TransactionState``s have a ``constraint`` field that represents that state's attachment constraint. When a party
constructs a ``TransactionState`` without specifying the constraint parameter a default value
(``AutomaticHashConstraint``) is used. This default will be automatically resolved to a specific
``HashAttachmentConstraint`` that contains the hash of the attachment which contains the contract of that
@ -80,8 +80,8 @@ attachment JAR. This allows for trusting of attachments from trusted entities.
Limitations
-----------
An ``AttachmentConstraint`` is verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is
called it is provided only the relevant attachment by the transaction that is verifying it.
``AttachmentConstraint``s are verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is called
it is provided only the relevant attachment by the transaction that is verifying it.
Testing
-------