Renaming Target

[philippjfr]

With the Lumen 0.5.0 release finally coming up we've got one last chance to fix naming mistakes in Lumen. One major sticking point has always been the Target component. This name came about as a natural pair to the data Source, where data would flow from source to target. However, even then it never really made sense and since there's been quite a lot of refactoring that more cleanly separates views, filters and transforms (which used to be grouped together on a target).

This means that now a Target is defined as a component consisting of one or more view components that consume data from a pipeline and render the views into a layout. Therefore I suggest I finally pull the trigger and simply rename Target -> Layout. Alternatively I could also consider LayoutGroup as the name of the Python class but keep the YAML key as layouts.

I'd like to collect everyone's opinion so please chime in @Hoxbro, @maximlt, @jbednar, @droumis, @jlstevens and @eli-pinkus.

[jlstevens]

Layout does make it clearer to me in a Lumen context than Target but across HoloViz Layout is already horribly overloaded!

Just brainstorming for alternatives with no attachment to any of them: Cards, Tiles, Grid, Panes, Slots, Grouping, Places, Positioning,Arrangement, ViewGroup, Collection, Placement, Template (this one, only if you can also do custom positioning with some sort of template)?

[jbednar]

The name Layout makes good sense to me if it's truly comparable to the HoloViz and Panel Layout concepts. I.e., if a Lumen Layout (lumen.Layout?) is used for the same things as a Panel Layout and a HoloViews layout are, i.e. as fundamentally a grouping of items displayed together. If that's true, Layout. If not, it needs a different name. From your description above I can't tell if that's an accurate way to describe a Lumen Target.

[droumis]

+1 for Layout

I'm just going to throw out Dashboard as another option, given that this is the final (and required) step that produces the components that the user interacts with. But it somewhat implies that data is already flowing into it

[eli-pinkus]

Could Tab work? I know targets aren't always represented as tabs, but they are by default and it makes it clear that there can by multiple Tabs per Dashboard and multiple Views per tab

[jlstevens]

If Dashboard makes sense, I quite like that suggestion.

[eli-pinkus]

I think Dashboard is a bit unclear for two reasons:

1. I would typically think of a Dashboard as the entire app, so it may not make sense that Lumen app can have multiple dashboards. Not to mention that if you serve multiple yamls with a home page, you would end up with this renamed Dashboard class as the third level of structural hierarchy which feels odd.
2. There is also this Dashboard object already that refers to essentially the entire app (w/ potentially several Targets)

[Hoxbro]

Another candidate could be something like mainarea. I like the idea of being able to say that "all the views are located in the main area". Also, have some common ground with panel templates.

[philippjfr]

Really appreciate everyones input, especially the alternative naming suggestions. I've tried a few of them by doing a search and replace in the docs and seeing if they make sense in that context. Doing that made it pretty obvious that Layout is the only one that really works. There may have been an argument to let the class name (Layout) to diverge from the key name in the specification (layouts) and use something like ViewGroup but on balance I think keeping them aligned is clearest and simplest.

[jlstevens]

I suppose that is probably best...we already need to qualify all our uses of layout: 'holoviews layout', 'panel layout', 'bokeh layout' and now we would have 'lumen layout'.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.