8000 Updated Card and Accordion docs by jbednar · Pull Request #1267 · holoviz/panel · GitHub
[go: up one dir, main page]
Skip to content

Updated Card and Accordion docs #1267

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.

Sign up for GitHub

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

Merged
philippjfr merged 1 commit into from
Apr 14, 2020
Merged

Updated Card and Accordion docs #1267

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions examples/reference/layouts/Accordion.ipynb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,21 +14,21 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"``Accordion`` layouts allow switching between multiple objects by clicking on the corresponding card header. The labels for each card may be defined explicitly as part of a tuple or will be inferred from the ``name`` parameter of the card's contents. Like ``Column`` and ``Row``, ``Tabs`` has a list-like API with methods to ``append``, ``extend``, ``clear``, ``insert``, ``pop``, ``remove`` and ``__setitem__`` (to replace the contents), which make it possible to interactively update and modify the cards.\n",
"``Accordion`` layouts are a type of ``Card`` layout that allows switching between multiple objects by clicking on the corresponding card header. The labels for each card may be defined explicitly as part of a tuple, and otherwise default to the ``name`` parameter of the card's contents. Like ``Column`` and ``Row``, ``Tabs`` has a list-like API that allows interactively updating and modifying the cards using methods ``append``, ``extend``, ``clear``, ``insert``, ``pop``, ``remove`` and ``__setitem__`` (to replace the contents).\n",
"\n",
"#### Parameters:\n",
"\n",
"* **``active``** (list, default=[]): The indexes of the currently displayed cards. Updates when a card is expanded or collapsed and may also be set to programmatically control which cards are shown.\n",
"* **``objects``** (list): The list of objects to display in the Column. Should not generally be modified directly except when replaced in its entirety.\n",
"* **``toggle``** (bool): Whether to toggle between active cards or allow multiple cards to be expanded simultaneously.\n",
"* **``toggle``** (bool): Whether to toggle between the available cards, activating only one at a time (if True), or (if False) whether to allow multiple cards to be expanded simultaneously.\n",
"\n",
"Styling related parameters:\n",
"Styling-related parameters:\n",
"\n",
"* **``active_header_background``** (str): The background color of the header when the `Card` is expanded.\n",
"* **``button_color``** (str): The color of the collapse button.\n",
"* **``header_background``** (str): The background color of the header.\n",
"\n",
"For further layout and styling related parameters see the [customization user guide](../../user_guide/Customization.ipynb).\n",
"For further layout and styling-related parameters see the [customization user guide](../../user_guide/Customization.ipynb).\n",
"\n",
"___"
]
Expand All @@ -44,7 +44,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"A ``Accordion`` layout can either be instantiated as empty and be populated after the fact, or using a list of objects provided as positional arguments. If the objects are not already Panel components they will each be converted to one using the ``pn.panel`` conversion method. Unlike other panel ``Accordion`` also accepts tuples to specify the title of each tab, if no name is supplied explicitly the name of the underlying object will be used."
"An ``Accordion`` layout can either be instantiated as empty and populated after the fact, or by using a list of objects provided on instantiation as positional arguments. If the objects are not already Panel components they will each be converted to one using the ``pn.panel`` conversion method. Unlike other panel types, ``Accordion`` also accepts tuples to specify the title of each tab; if no name is supplied explicitly the name of the underlying object will be used."
]
},
{
Expand All @@ -69,7 +69,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"The ``Accordion.objects`` parameter should never be modified directly. Instead, it is recommended to modify tabs using the provided methods, except when replacing the list of ``objects`` entirely. Using the methods ensures that the rendered views of the ``Accordion`` is rerendered in response to the change, but even more importantly it ensures the card titles are kept in sync with the objects. As a simple example we might add an additional widget to the ``Accordion`` using the `append` method:"
"The contents of the ``Accordion.objects`` list should never be modified individually, because Panel cannot detect when items in that list have changed internally, and will thus fail to update any already-rendered views of those objects (and their card titles!). Instead, use the provided methods for adding and removing items from the list. The only change that is safe to make directly to ``Accordion.objects`` is to replace the list of ``objects`` entirely. As a simple example of using the methods, we might add an additional widget to the ``Accordion`` using the `append` method:"
]
},
{
Expand Down Expand Up @@ -125,7 +125,7 @@
"source": [
"#### ``toggle``\n",
"\n",
"When toggle is enabled only one card can be active at the same time, i.e. expanding one card will collapse the other active cards."
"When toggle is enabled only one card can be active at the same time, i.e., expanding one card will collapse the other active cards (much like a Tabs layout)."
]
},
{
Expand Down
16 changes: 8 additions & 8 deletions examples/reference/layouts/Card.ipynb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,16 +14,16 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"The ``Card`` layout allows arranging multiple panel objects in a collapsible, vertical container with a header bar. It has a list-like API with methods to ``append``, ``extend``, ``clear``, ``insert``, ``pop``, ``remove`` and ``__setitem__`` (for replacing the cards contents), which make it possible to interactively update and modify the layout.\n",
"The ``Card`` layout allows arranging multiple Panel objects in a collapsible, vertical container with a header bar. It has a list-like API with methods for interactively updating and modifying the layout, including ``append``, ``extend``, ``clear``, ``insert``, ``pop``, ``remove`` and ``__setitem__`` (for replacing the card's contents).\n",
"\n",
"`Card` components are very helpful for laying out components in a grid in a complex dashboard to make clear visual separations between different sections. Additionally the ability to collapse them can be very useful save space on a page with a lot of components.\n",
"`Card` components are very helpful for laying out components in a grid in a complex dashboard to make clear visual separations between different sections. The ability to collapse them can also be very useful to save space on a page with a lot of components.\n",
"\n",
"#### Parameters:\n",
"\n",
"* **``collapsed``** (bool): Whether the `Card` is collapsed.\n",
"* **``collapsible``** (bool): Whether the `Card` can be expanded and collapsed.\n",
"* **``header``** (Viewable): A Panel component to display in the header bar of the Card.\n",
"* **``objects``** (list): The list of objects to display in the Card, which will be formatted like a `Column`, should not generally be modified directly except when replaced in its entirety.\n",
"* **``objects``** (list): The list of objects to display in the Card, which will be formatted like a `Column`. Should not generally be modified directly except when replaced in its entirety.\n",
"* **``title``** (str): The title to display in the header bar if no explicit `header` is defined.\n",
"\n",
"Styling related parameters:\n",
Expand All @@ -46,7 +46,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"A ``Card`` layout can either be instantiated as empty and populated after the fact or using a list of objects provided as positional arguments. If the objects are not already panel components they will each be converted to one using the ``pn.panel`` conversion method. Unlike the `Row` and `Column` layouts the `Card` has an explicit `title` which will be shown in the header bar alongside the collapse button (if the `collapsible` parameter is enabled):"
"A ``Card`` layout can either be instantiated as empty and populated after the fact, or by using a list of objects provided on instantiation as positional arguments. If the objects are not already Panel components they will each be converted to one using the ``pn.panel`` conversion method. Unlike the `Row` and `Column` layouts, a `Card` has an explicit `title` that will be shown in the header bar alongside the collapse button (if the `collapsible` parameter is enabled):"
]
},
{
Expand All @@ -66,7 +66,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"In general it is preferred to modify layouts only through the provided methods and avoid modifying the ``objects`` parameter directly. The one exception is when replacing the list of ``objects`` entirely, otherwise it is recommended to use the methods on the ``Card`` itself to ensure that the rendered views of the ``Card`` are rerendered in response to the change. As a simple example we might add an additional widget to the ``column`` using the append method:"
"The contents of the ``Card.objects`` list should never be modified individually, because Panel cannot detect when items in that list have changed internally, and will thus fail to update any already-rendered views of those objects. Instead, use the provided methods for adding and removing items from the list. The only change that is safe to make directly to ``Card.objects`` is to replace the list of ``objects`` entirely. As a simple example of using the methods, we might add an additional widget to the card using the append method:"
]
},
{
Expand All @@ -83,7 +83,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"On a live server or in a notebook the `card` displayed above will dynamically expand in size to accomodate all three widgets and the title. To see the effect in a statically rendered page, we will display the column a second time:"
"On a live server or in a notebook the `card` displayed after the previous code cell (above) will dynamically expand in size to accomodate all three widgets and the title. To see the effect in a statically rendered page, we will display the column a second time:"
]
},
{
Expand Down Expand Up @@ -118,7 +118,7 @@
"source": [
"### Header\n",
"\n",
"Instead of using a `title` a `Card` may also be given an explicit `header` which can contain any component, e.g. in this case the Panel logo:"
"Instead of using a `title`, a `Card` may also be given an explicit `header` that can contain any component, e.g. in this case the Panel logo:"
]
},
{
Expand Down Expand Up @@ -148,7 +148,7 @@
"source": [
"### Layout\n",
"\n",
"In general a ``Card`` does not have to be given an explicit ``width``, ``height`` or ``sizing_mode``, allowing it to adapt to the size of its contents. However in certain cases it can be useful to declare a fixed-size layout, which its responsively sized contents will then fill, making it possible to achieve equal spacing between multiple objects:"
"In general a ``Card`` does not have to be given an explicit ``width``, ``height``, or ``sizing_mode``, allowing it to adapt to the size of its contents. However in certain cases it can be useful to declare a fixed-size layout, which its responsively sized contents will then fill, making it possible to achieve equal spacing between multiple objects:"
]
},
{
Expand Down
0