Add user manual for observe#1060
Conversation
| Requesting trait attribute change notifications can be done in several | ||
| ways: | ||
|
|
||
| .. index:: notification; strategies | ||
|
|
||
| * Dynamically, by calling on_trait_change() or on_trait_event() to establish | ||
| (or remove) change notification handlers. | ||
| * Statically, by decorating methods on the class with the @on_trait_change | ||
| decorator to indicate that they handle notification for specified attributes. | ||
| * Statically, by using a special naming convention for methods on the class to | ||
| indicate that they handle notifications for specific trait attributes. | ||
|
|
||
| .. index:: notification; dynamic |
There was a problem hiding this comment.
This probably needs to be updated to give the context for the older methods of notification.
| decorator to indicate that they handle notification for specified attributes. | ||
| * Via instance method: By calling |HasTraits.observe| instance method to establish (or remove) change | ||
| notification handlers. | ||
|
|
There was a problem hiding this comment.
You might mention listeners somewhere here as an older alternative.
| applying the |@observe| decorator on an instance method. It has the following | ||
| signature: | ||
|
|
||
| .. py:decorator:: observe(expression[, post_init=False, dispatch="same"]) |
There was a problem hiding this comment.
Can this be made to use autodoc so that it doesn't get out of date if we change the API?
There was a problem hiding this comment.
autodoc ends up bringing the entire docstring here, which is too verbose, an alternative is to write our custom hooks for autodoc but that is probably an overkill. I agree with your concern, so I removed these now and hopefully the links to the API documentation is enough. I reworked these paragraphs to provide the same level of context for the subsequent sections. In particular, the mention of "expression" and "handler" are needed for later sections.
| The |HasTraits.observe| method is useful for adding or removing change handler on a per | ||
| instance basis. The method has the following signature: | ||
|
|
||
| .. py:method:: HasTraits.observe(handler, expression[, remove=False, dispatch="same"]) |
There was a problem hiding this comment.
Same comment about autodoc here
| Notification Handler | ||
| -------------------- | ||
|
|
||
| As soon as a change has occurred, the **handler** callable provided will be |
There was a problem hiding this comment.
"As soon as" is vague. We should probably say something about:
- dispatch usually being immediate, but dependent on the
dispatchkeyword (eg. dispatch="ui" is not immediate) - the order that handlers are called being arbitrary.
| - handler(*event*) | ||
|
|
||
| where the *event* parameter is an object representing the change observed. | ||
| The type of *event* depends on the context of the change. |
There was a problem hiding this comment.
We should mention here any guarantees that we make about the common API, eg. if object is always present.
| .. rubric:: Notes | ||
|
|
||
| #. When a handler is invoked, the change has already occurred. | ||
| #. Multiple handlers can be defined for a given change event and these handlers |
There was a problem hiding this comment.
I'd bump this up, rather than have it in a note (see previous comments).
| captured and logged. | ||
|
|
||
|
|
||
| Differences from |@on_trait_change| |
There was a problem hiding this comment.
Maybe "migrating from on_trait_change"?
corranwebster
left a comment
There was a problem hiding this comment.
A couple of further comments:
- the example code should have module docstrings so that the TraitsUI demo code can display it properly
- while the content is good, we may want to restructure how it is presented into:
- how observation works without any significant reference to listeners (maybe mention their existence in an introduction)
- a more buried section on listeners (part of an "advanced" section, or an appendix) which indicates that it is an older way of doing things
- a "migration guide" section which includes things like differences between listeners and observers, and later things like moving from Either to Union and handling mapped traits with Map
…t is an older mechanism
|
Thank you @corranwebster, all very good suggestions and I made quite a lot of changes:
|
| introduced for overcoming them. See :ref:`observe-notification` for details and | ||
| for how to migrate. | ||
|
|
||
| Change notifications can be set up with **on_trait_change** in several ways: |
There was a problem hiding this comment.
This sentence and the paragraph above are changed. The rest are the same as the original documentation.
|
I overlooked this important request change:
Will continue making changes for this. Removing review request for now. I am sorry for the noise. Edited: Done. |
|
|
||
| * - Expression | ||
| - Meaning | ||
| * - *trait("attr1")* |
There was a problem hiding this comment.
Can we add backticks around these, so that the rendered expressions can be copy-pasted? (Currently they're appearing with code-unfriendly smart quotes.)
There was a problem hiding this comment.
They will look rather long and squash the "meaning" column into a small column.
I could instead break this out into bulletins instead of trying to fit them in a table.
Happy to do this in a separate PR so not to block the release process.
There was a problem hiding this comment.
That could work. Right now, the rendered code can't be copy-and-pasted because of the smart quotes.
There was a problem hiding this comment.
I thought it was going to take me a while to get the formatting right. It did not take so long at the end: See #1140
|
This LGTM. There are some places where the wording could be tweaked, but I'm happy for that to happen in a separate PR. |
|
If this is good enough to go in, let's do tweaks in separate PRs so we don't block release preparations. |
corranwebster
left a comment
There was a problem hiding this comment.
Comments are in examples, so I am OK with it being merged.
|
Thank you both! Merging... |
| - Meaning | ||
| * - *attr1\.attr2* | ||
| - Matches a trait named *attr2* on an object referenced by a trait named | ||
| *item1* on the current object. Changes to *attr1* or *attr2* will |
There was a problem hiding this comment.
should this be "attr1", not "item1"
There was a problem hiding this comment.
Well spotted! Will fix.
This PR add user manual for the
observeframework.on_trait_changeis moved tolistening.rst. The first paragraph is extracted as an intermediate index page for notifications.observing.rstfor theobserveframework.traits.observation.apito the API reference for cross-referencing.examples/tutorials/doc_examplesEdited (this was the previous message:)
This is a draft PR for making theobserveuser manual visible (see #977).Much of the API cross-references are missing in this PR, as the PR would otherwise be too big. To see the documentation with styling and cross-referencing, checkoutobserver-framework-testbranch and build the documentation usingpython etstool.py docs.Checklist
Testsdocs/source/traits_api_reference)docs/source/traits_user_manual)Update type annotation hints intraits-stubs