Change Details

While reviewing our proof-of-concept code to change how the template dialog sidebar works, we've identified the current usage of BookletLayout as a risk to our project. There are three separate classes sharing responsibility for manipulating the sidebar and content panes, making any changes touching the sidebar unnecessarily complicated. We have some initial suggestions for simplification, [] Try not to change the ooui BookletLayout implementation at all. If changes are necessary, make them in a backwards-compatible way which will not break existing usages. [] Extract logic which directly manipulates the booklet panes into a separate class, and expose only the highest-level interface e.g. "add item" which manages both the sidebar and content pane transparently to the caller. [] Minimize knowledge required by callers.

While reviewing our proof-of-concept code to change how the template dialog sidebar works, we've identified the current usage of BookletLayout as a risk to our project. There are three separate classes sharing responsibility for manipulating the sidebar and content panes, making any changes touching the sidebar unnecessarily complicated. We have some initial suggestions for simplification, [] Try not to change the ooui BookletLayout implementation at all. If changes are necessary, make them in a backwards-compatible way which will not break existing usages. [] Extract logic which directly manipulates the booklet panes into a separate class, and expose only the highest-level interface e.g. "add item" which manages both the sidebar and content pane transparently to the caller. [] Minimize knowledge required by callers. See subtasks for more details.

While reviewing our proof-of-concept code to change how the template dialog sidebar works, we've identified the current usage of BookletLayout as a risk to our project. There are three separate classes sharing responsibility for manipulating the sidebar and content panes, making any changes touching the sidebar unnecessarily complicated. We have some initial suggestions for simplification, [] Try not to change the ooui BookletLayout implementation at all. If changes are necessary, make them in a backwards-compatible way which will not break existing usages. [] Extract logic which directly manipulates the booklet panes into a separate class, and expose only the highest-level interface e.g. "add item" which manages both the sidebar and content pane transparently to the caller. [] Minimize knowledge required by callers. See subtasks for more details.