-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User functions guide #252
base: dev
Are you sure you want to change the base?
User functions guide #252
Conversation
Add links to examples of usage (if such examples exist in our codebase). If I understood correctly, information about exception handling is going to be in a separate section. In that case we should move all the specific function information into subsections:
I think we should also sort the functions in the order of their usage frequency. |
WARNING: the guide has one |
…vlov/dialog_flow_framework into docs/user_functions_guide
There is still one TODO left! |
Maybe split into sections And also reorder sections (service handlers should be before extra handlers; actor handlers should be last). I think that Pre-transition and Pre-response could be merged into one section since there is no difference between the two besides the point of execution. And the guide should include information about the most common use cases for functions with examples (e.g. pre-response processors are commonly used to modify response which is done by updating the |
Is this about this line?
I don't understand why that is needed here. Parser is not merged yet and I don't see the connection between the two. |
Some of the functions can only be defined in python diction. AFAIK parser adds support for parsing the dictionary from YAML file. How will the functions (e.g. labels) be represented in the file? |
|
||
.. code-block:: python | ||
|
||
def handler(ctx: Context, pipeline: Pipeline) -> Context: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we assume that the API update will be merged before this PR or after it? If yes, the processing signature will be different: functions will return None
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consider API compatible with the current one.
Description
Adds userguide describing user-defined functions of the framework.
Checklist