Allow model id to be set externally on creation of the widget. #6194
Conversation
SylvainCorlay
changed the title
| # Create a comm, use self._model_id as comm_id | ||
| # if the comm is closed and re-opened, the same id will be used. | ||
| if self._model_id is not None: | ||
| self.comm = Comm(target_name=self._model_name, comm_id=self._model_id) |
There was a problem hiding this comment.
Should I check if there is already a comm with that id and raise an exception if it is the case? Or should I consider that people are responsible when externally setting model ids?
|
@SylvainCorlay what can you do in this PR that you can't do in @jasongrout 's PR #6151 ? He mentions you can create and pass in comms in the widget constructor. Doesn't that allow you to set the comm/model id too? @jasongrout 's comment:
|
That's a good point. However, it's sort of breaking the widget abstraction by requiring the user to know about and initialize the comm and pass it in. I imagine it's much nicer to just set a model id, if that's what you really want. |
|
It is convenient to pass a |
|
I cleaned up the branch a bit. |
|
@minrk could you take a quick look at the comm.py changes here? |
|
@SylvainCorlay I think @minrk 's on vacation, but this also needs a rebase. You may want to wait till he gets a chance to review the comm stuff... |
This will immediately create a model on the javascript side when a widget is created. This means that, for example, a widget that only interacts with its model can work without "displaying" it.
Instead of automagically instantiating a comm when it is accessed, require a call to open(). This makes the comm attribute much less magical, and hopefully more understandable.
|
Rebased |
Allow model id to be set externally on creation of the widget.
|
Thanks @SylvainCorlay and @jasongrout |
|
Thanks @jdfreder . |
Allow model id to be set externally on creation of the widget.
With this change, the
model_idof a widget to be set externally when creating the widget. (It is especially useful in cases where you want themodel_idto correspond to some other object's uuid that you don't control, and you don't want to rely on a lookup table. )Another feature is that if a widget is closed and reopened, the new model_id/comm_id will be the same as the previous one.