You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 29, 2019. It is now read-only.
Param and ParamBokeh were designed to support large, complex systems, with hierarchically organized options mirroring a class hierarchy that allows a clean separation between parameters for objects and any widgets that might be appropriate to display when those objects are used in a GUI context. Thus parameters are all currently declared as class attributes of Parameter type, independently of any package like ParamBokeh that will create GUI widgets from those definitions. For complex systems, separating the parameter declaration from the widget instantiation provides major benefits to the code even apart from any widgets, such as type and range checking that helps keep interactions between components manageable.
However, there are other contexts where it would be useful to have Bokeh-based widgets that don't involve complex hierarchical systems, and the class Parameter approach is not necessarily the best approach in those cases. For instance, when using a Jupyter notebook as a command prompt, it's often useful to create a widget explicitly for a particular local task, without designing a class hierarchy. The API from ipywidgets' interact() function is a good example of this alternative approach, which won't necessarily scale to larger projects, but can be very convenient in a single Jupyter cell or in a very basic dashboard.
Mirroring or nearly mirroring the interact() API specifically would also make it easier for people to switch between ipywidgets and param-based approaches, e.g. to evaluate Bokeh Server as a deployment mechanism. If we provide an interact() equivalent, we would need to be very clear in the documentation about its purpose, and to make its limitations clear.
The text was updated successfully, but these errors were encountered:
Strictly speaking, this might end up being implemented using Bokeh widgets directly, and need not necessarily involve ParamBokeh, but my guess is that it would be easier to do it using the lookup tables, etc. we already have in ParamBokeh.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Param and ParamBokeh were designed to support large, complex systems, with hierarchically organized options mirroring a class hierarchy that allows a clean separation between parameters for objects and any widgets that might be appropriate to display when those objects are used in a GUI context. Thus parameters are all currently declared as class attributes of Parameter type, independently of any package like ParamBokeh that will create GUI widgets from those definitions. For complex systems, separating the parameter declaration from the widget instantiation provides major benefits to the code even apart from any widgets, such as type and range checking that helps keep interactions between components manageable.
However, there are other contexts where it would be useful to have Bokeh-based widgets that don't involve complex hierarchical systems, and the class Parameter approach is not necessarily the best approach in those cases. For instance, when using a Jupyter notebook as a command prompt, it's often useful to create a widget explicitly for a particular local task, without designing a class hierarchy. The API from ipywidgets'
interact()
function is a good example of this alternative approach, which won't necessarily scale to larger projects, but can be very convenient in a single Jupyter cell or in a very basic dashboard.Mirroring or nearly mirroring the
interact()
API specifically would also make it easier for people to switch between ipywidgets and param-based approaches, e.g. to evaluate Bokeh Server as a deployment mechanism. If we provide aninteract()
equivalent, we would need to be very clear in the documentation about its purpose, and to make its limitations clear.The text was updated successfully, but these errors were encountered: