ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-19 21:17:58 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

DEVREL-1287 - Minor Typographic Changes

Browse Source 
CordApp -> CorDapp
This commit is contained in:
ChrissyAtWork 2019-04-25 10:16:27 +01:00 committed by Mike Hearn
parent 5a3073aeb1
commit fc5de7c646
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/source/flow-overriding.rst
View File

@ -8,7 +8,7 @@ Configuring Responder Flows
===========================
A flow can be a fairly complex thing that interacts with many backend systems, and so it is likely that different users
of a specific CordApp will require differences in how flows interact with their specific infrastructure.
of a specific CorDapp will require differences in how flows interact with their specific infrastructure.
Corda supports this functionality by providing two mechanisms to modify the behaviour of apps in your node.
@ -92,13 +92,13 @@ Corda would detect that both ``BaseResponder`` and ``SubResponder`` are configur
Corda will then calculate the hops to ``FlowLogic`` and select the implementation which is furthest distance, ie: the most subclassed implementation.
In the above example, ``SubResponder`` would be selected as the default responder for ``Initiator``
.. note:: The flows do not need to be within the same CordApp, or package, therefore to customise a shared app you obtained from a third party, you'd write your own CorDapp that subclasses the first.
.. note:: The flows do not need to be within the same CorDapp, or package, therefore to customise a shared app you obtained from a third party, you'd write your own CorDapp that subclasses the first.
Overriding a flow via node configuration
----------------------------------------
Whilst the subclassing approach is likely to be useful for most applications, there is another mechanism to override this behaviour.
This would be useful if for example, a specific CordApp user requires such a different responder that subclassing an existing flow
This would be useful if for example, a specific CorDapp user requires such a different responder that subclassing an existing flow
would not be a good solution. In this case, it's possible to specify a hardcoded flow via the node configuration.
.. note:: A new responder written to override an existing responder must still be annotated with ``@InitiatedBy`` referencing the base initiator.
@ -196,4 +196,4 @@ Corda will use the first annotation detected in the class hierarchy to determine
it would be possible to invoke either ``BaseInitiator`` or ``NotaryOnlyInitiator`` and ``BobbyResponder`` would be used to reply.
.. warning:: You must ensure the sequence of sends/receives/subFlows in a subclass are compatible with the parent.
.. warning:: You must ensure the sequence of sends/receives/subFlows in a subclass are compatible with the parent.