Skip to content

Adding metadata/styling from repr output #14

Open

Description

@jankatins

[edit]
Currently, without a change in the frontend, the best we can do is simple send the complete metadata to the frontend in the normal display data: If we manage the styling, we send the styling only once on the first exec of such code. But then the frontend (=Notebook) could reevaluate the cell which currently has the styling and we would no notice this and no send styling, and the notebook would end up without styling information.

See also jupyter/notebook#116 and jupyter/roadmap#9
[/]
It would be nice to be able to specify that something only needs to be displayed once, e.g. the styling for a table or an interactive plot.

The repr side probably only needs to document the way this should happen, the actually implementation needs to be in the display package.

From the old issue comment by @flying-sheep:


yeah, the point is that there needn’t be a new interface: we can simply add attributes to the character()/raw() returned, which avoids changing signatures.

an example where i loop a bunch of things, create their HTML reprs and only do setup once:

repr_html.stuff <- function(x, ...) {
    ...
    structure(html_markup, setup = list(stuff_setup_script = '<script>...</script>')
}

html_setups_seen <- character()
for (thing in things) {
    thing_repr <- repr_html(thing)
    thing_setups <- attr(thing_repr, 'setup')
    new_setups <- stuff_setups[intersect(html_setups_seen, names(thing_setups))]
    html_setups_seen <- c(html_setups_seen, names(new_setups))

    display_html_setups(new_setups)
    display_html(stuff_repr)
}

PS: for the implementation, we should have a list of seen setups, keyed by format and class. this way there will be less potential for name collisions. or we just us the passed code itself as key.

Activity

  1. changed the title [-]Adding metadata/styling to repr output[/-] [+]Adding metadata/styling from repr output[/+] on Mar 9, 2016
  2. flying-sheep commented on Mar 9, 2016

    @flying-sheep
    Member

    i wanted to wait for notebook itself to implement such functionality, but actually we could do this ourselves.

    anyway: can you find the notebook issue about this? there has to be one…

  3. jankatins commented on Mar 9, 2016

    @jankatins
    ContributorAuthor

    At least my search-foo didn't find one in jupyter_client and now notebook and the old ipython one.

    But for me, the pro/con list makes it pretty clear that this is not a thing which should happen in the notebook backend/frontend but on the kernel... Just imagine a plot library adding their own xxx kb css and js files to each call (maybe even 2x because html and markdown output?) and then having that in the ipynb file :-( In knitr, the stuff never reaches the final output file, so it's similar to an in-kernel-solution.

  4. takluyver commented on Mar 9, 2016

    @takluyver
    Member

    Tricky, because what if the output which has the styling is cleared later?

  5. jankatins commented on Mar 9, 2016

    @jankatins
    ContributorAuthor

    Oups, that the reverse "restart the kernel" problem... so reruns of all cells (or just the one which got the styling) do not work... So it seems we really need something in the notebook and do it there?

  6. rgbkrk commented on Mar 10, 2016

    @rgbkrk

    @jdfreder put together a proposal to help with this and it's generally unsolved.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions