Skip to content

Add user manual for observe#1060

Merged
kitchoi merged 32 commits into
masterfrom
doc-observe-user-manual
May 22, 2020
Merged

Add user manual for observe#1060
kitchoi merged 32 commits into
masterfrom
doc-observe-user-manual

Conversation

@kitchoi
Copy link
Copy Markdown
Contributor

@kitchoi kitchoi commented May 1, 2020

This PR add user manual for the observe framework.

  • The documentation for on_trait_change is moved to listening.rst. The first paragraph is extracted as an intermediate index page for notifications.
  • Add observing.rst for the observe framework.
  • Add traits.observation.api to the API reference for cross-referencing.
  • Add examples to examples/tutorials/doc_examples

Edited (this was the previous message:)
This is a draft PR for making the observe user 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, checkout observer-framework-test branch and build the documentation using python etstool.py docs.

Checklist

  • Tests
  • Update API reference (docs/source/traits_api_reference)
  • Update User manual (docs/source/traits_user_manual)
  • Update type annotation hints in traits-stubs

Comment thread docs/source/traits_user_manual/observers.rst Outdated
Comment thread docs/source/traits_user_manual/observers.rst Outdated
Comment thread docs/source/traits_user_manual/observers.rst Outdated
@kitchoi kitchoi changed the title [WIP] Add draft user manual for observe Add user manual for observe May 20, 2020
@kitchoi kitchoi marked this pull request as ready for review May 20, 2020 17:51
Comment on lines +7 to +19
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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"])
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be made to use autodoc so that it doesn't get out of date if we change the API?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"])
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment about autodoc here

Notification Handler
--------------------

As soon as a change has occurred, the **handler** callable provided will be
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"As soon as" is vague. We should probably say something about:

  • dispatch usually being immediate, but dependent on the dispatch keyword (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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd bump this up, rather than have it in a note (see previous comments).

captured and logged.


Differences from |@on_trait_change|
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "migrating from on_trait_change"?

Copy link
Copy Markdown
Contributor

@corranwebster corranwebster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@kitchoi
Copy link
Copy Markdown
Contributor Author

kitchoi commented May 21, 2020

Thank you @corranwebster, all very good suggestions and I made quite a lot of changes:

  • Merged ‘observing’ and ‘notification’ so that observe is the main content for ‘Traits Notification’.
  • on_trait_change is moved to an Appendix and is referenced in the introduction for observe.
  • Regrouped some of the “differences from on_trait_change” into a section more like a migration guide
  • Rebranded some of the “differences from on_trait_change” as features/fixes, with as little mention of on_trait_change as possible.
  • Moved the expectations/rules about the change handler up
  • Mentioned the “dispatch” parameter and its effect on handler
  • Simplified migration-guide-like sections to make them easier to read at a glance.

@kitchoi kitchoi requested a review from corranwebster May 21, 2020 16:48
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:
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence and the paragraph above are changed. The rest are the same as the original documentation.

@kitchoi kitchoi removed the request for review from corranwebster May 21, 2020 16:51
@kitchoi
Copy link
Copy Markdown
Contributor Author

kitchoi commented May 21, 2020

I overlooked this important request change:

the example code should have module docstrings so that the TraitsUI demo code can display it properly

Will continue making changes for this. Removing review request for now. I am sorry for the noise.

Edited: Done.

@kitchoi kitchoi requested a review from corranwebster May 21, 2020 17:10

* - Expression
- Meaning
* - *trait("attr1")*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add backticks around these, so that the rendered expressions can be copy-pasted? (Currently they're appearing with code-unfriendly smart quotes.)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could work. Right now, the rendered code can't be copy-and-pasted because of the smart quotes.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mdickinson
Copy link
Copy Markdown
Member

This LGTM. There are some places where the wording could be tweaked, but I'm happy for that to happen in a separate PR.

@kitchoi
Copy link
Copy Markdown
Contributor Author

kitchoi commented May 22, 2020

If this is good enough to go in, let's do tweaks in separate PRs so we don't block release preparations.

Copy link
Copy Markdown
Contributor

@corranwebster corranwebster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments are in examples, so I am OK with it being merged.

@kitchoi
Copy link
Copy Markdown
Contributor Author

kitchoi commented May 22, 2020

Thank you both! Merging...
I am working on changes for addressing #1060 (comment)
That will be in a separate PR.

@kitchoi kitchoi merged commit d60b380 into master May 22, 2020
@kitchoi kitchoi deleted the doc-observe-user-manual branch May 22, 2020 09:44
- 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be "attr1", not "item1"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well spotted! Will fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component: documentation Issues related to the Sphinx documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants