References for a multiple windows app(apps?).

Hi,

I am trying to do an app with multiple browser windows but I cannot find much reference for it.

The idea is to have a central page/app tieh a table where the user can click a button and open a new window/app with details of a row. Similar to a tab, but in a new browser window.

The way I am doing so far is as follows:
I can start bokeh server with one app per page (bokeh serve app1/ app2/ app3./ …), then I could add a link to the hub page that opens an url of the form ‘localhost:5006/app2’.

I am not sure if that is a good idea, nor if Bokeh is suitable for that.

The reason to have a second window is to allow my user to ‘zoom’ in the rows of a table (in the app1) and move plots around without moving the table.
For example, sometimes the user will want to see rows 2 and 4 at the same time, some times he/she will compare rows 3,4 and 10 at the same time.
In App1 there would be checkboxes and buttons to open new windows so the user can move them around on the screen.

Any reference on this task?

It should be fairly simple given two apps running at the same time.

Thank you

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

Hi,

Getting two independent apps running at the same time is trivial. Getting two apps running at the same time that coordinate different pages on a per-user basis, is not. The basic problem is ensuring that two individual sessions from different apps are strongly tied to and can communicate with each other, and this would definitely be an advanced usage of Bokeh.

Bokeh has a client API that lets you create individual sessions programmatically from python. You can then also navigate browsers to URLs that open those specific sessions. I think to have any hope at actually coordinating rigorously and robustly, you'd have to do something like:

* have app1 use bokeh.client to create a session for the related app2
* have app1 present or open a URL directly to the app2 session

So far, not all that difficult. The last part is the interesting / open-ended pat

* make app1 and app2 sessions communicate somehow

This could be through sockets, web sockets, a database... lots of possibilities tho I am not sure any of them are completely trivial, and any callbacks from one to the other would probably need to put all document-modifying work on the ioloop with a next_tick_callback to ensure proper document locking is happening.

I would be happy to help more with this if you are interested in pursuing it, but would not really have any bandwidth until next week, after the next release is done.

Thanks,

Bryan

···

On Jun 4, 2017, at 19:47, [email protected] wrote:

Hi,

I am trying to do an app with multiple browser windows but I cannot find much reference for it.

The idea is to have a central page/app tieh a table where the user can click a button and open a new window/app with details of a row. Similar to a tab, but in a new browser window.

The way I am doing so far is as follows:
I can start bokeh server with one app per page (bokeh serve app1/ app2/ app3./ ...), then I could add a link to the hub page that opens an url of the form 'localhost:5006/app2'.

I am not sure if that is a good idea, nor if Bokeh is suitable for that.

The reason to have a second window is to allow my user to 'zoom' in the rows of a table (in the app1) and move plots around without moving the table.
For example, sometimes the user will want to see rows 2 and 4 at the same time, some times he/she will compare rows 3,4 and 10 at the same time.
In App1 there would be checkboxes and buttons to open new windows so the user can move them around on the screen.

Any reference on this task?

It should be fairly simple given two apps running at the same time.

Thank you

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0ad2b070-6dc6-430e-b9de-92756da6b4f5%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Thank you for the feedback.

On a second thought, what do I gain with two apps running together? Maybe I could do with only one app?

What if I have only one app that updates the document displayed after a click. Example:

Let’s say I want to display Summary Page, and Detailed Page:

On the click on summary page a global variable is updated, an open.window is called and a section is created.

On the Server_lifecycle the on_session_created function checks the global variable if needed, and also the main.py checks the global variable before adding plots to the document.

Depending on the global_variable state either the summary page is displayed (global_var is None), or the detailed page is displayed if global variable has any information.

The server keeps track of each page open and sends the data after every periodc call_back. After one session is closed the on_session_destroyed function removes that page/session from the server loop if needed.

The server could also send data according to a map of IPs in case there are multiple users.

What are the issues I am missing if I do all that as one single app displaying different layout on different sessions?

I could do two apps, but like you said, I would have to communicate. It shluld not be an issue, but also I can’t see any benefit.

Thank you

**PS: **For anybody else interested on this:

I found this reference that allows me to click on a table and process the data from the row clicked.

On this other reference Bryan from the past tells you how to open a page with an one line:

Puting both together, one can click on a table and open a page with the info in the row.

···

On Monday, June 5, 2017 at 10:01:40 AM UTC+9, Bryan Van de ven wrote:

Hi,

Getting two independent apps running at the same time is trivial. Getting two apps running at the same time that coordinate different pages on a per-user basis, is not. The basic problem is ensuring that two individual sessions from different apps are strongly tied to and can communicate with each other, and this would definitely be an advanced usage of Bokeh.

Bokeh has a client API that lets you create individual sessions programmatically from python. You can then also navigate browsers to URLs that open those specific sessions. I think to have any hope at actually coordinating rigorously and robustly, you’d have to do something like:

  • have app1 use bokeh.client to create a session for the related app2

  • have app1 present or open a URL directly to the app2 session

So far, not all that difficult. The last part is the interesting / open-ended pat

  • make app1 and app2 sessions communicate somehow

This could be through sockets, web sockets, a database… lots of possibilities tho I am not sure any of them are completely trivial, and any callbacks from one to the other would probably need to put all document-modifying work on the ioloop with a next_tick_callback to ensure proper document locking is happening.

I would be happy to help more with this if you are interested in pursuing it, but would not really have any bandwidth until next week, after the next release is done.

Thanks,

Bryan

On Jun 4, 2017, at 19:47, [email protected] wrote:

Hi,

I am trying to do an app with multiple browser windows but I cannot find much reference for it.

The idea is to have a central page/app tieh a table where the user can click a button and open a new window/app with details of a row. Similar to a tab, but in a new browser window.

The way I am doing so far is as follows:

I can start bokeh server with one app per page (bokeh serve app1/ app2/ app3./ …), then I could add a link to the hub page that opens an url of the form ‘localhost:5006/app2’.

I am not sure if that is a good idea, nor if Bokeh is suitable for that.

The reason to have a second window is to allow my user to ‘zoom’ in the rows of a table (in the app1) and move plots around without moving the table.

For example, sometimes the user will want to see rows 2 and 4 at the same time, some times he/she will compare rows 3,4 and 10 at the same time.
In App1 there would be checkboxes and buttons to open new windows so the user can move them around on the screen.

Any reference on this task?

It should be fairly simple given two apps running at the same time.

Thank you

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。


You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0ad2b070-6dc6-430e-b9de-92756da6b4f5%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

It's worth mentioning, Bokeh app sessions have access to any HTML query parameters in the URL that opened the session. So if probably would suffice to simple add different ?foo=bar parameters to the app URL to get different "views" of one app.

If you just want to open a brand new detail page every row click or whatever, and you don't mind new pages/tabs accumulating, then this might be all you need. Just encode enough information in the HTML parameter for each new detail page to load whatever view you want.

But if you want there to only ever be a single detail page, that updates whenever the summary page table is clicked, it seems to me you are back to needing to communicate between two different sessions. If you know there is only ever one viewer, then some approach with shared mutable state in a module that all sessions load (i.e. your global variable idea) might be workable. See the OHLC demo for a similar idea where one thread updates global data that all sessions view. But if you needs to support multiple users, I think this would become fragile fairly quickly. At least, I can think of several potential pitfalls in full generality, but YMMV depending on your specific circumstances.

Thanks,

Bryan

···

On Jun 4, 2017, at 21:24, [email protected] wrote:

Thank you for the feedback.

On a second thought, what do I gain with two apps running together? Maybe I could do with only one app?

What if I have only one app that updates the document displayed after a click. Example:

Let's say I want to display Summary Page, and Detailed Page:

On the click on summary page a global variable is updated, an open.window is called and a section is created.
On the Server_lifecycle the on_session_created function checks the global variable if needed, and also the main.py checks the global variable before adding plots to the document.
Depending on the global_variable state either the summary page is displayed (global_var is None), or the detailed page is displayed if global variable has any information.

The server keeps track of each page open and sends the data after every periodc call_back. After one session is closed the on_session_destroyed function removes that page/session from the server loop if needed.

The server could also send data according to a map of IPs in case there are multiple users.

What are the issues I am missing if I do all that as one single app displaying different layout on different sessions?

I could do two apps, but like you said, I would have to communicate. It shluld not be an issue, but also I can't see any benefit.

Thank you

PS: For anybody else interested on this:

I found this reference that allows me to click on a table and process the data from the row clicked.
python - How to add a Callback to Bokeh DataTable? - Stack Overflow

On this other reference Bryan from the past tells you how to open a page with an one line:
Why I can't use OperURL in widget callback (e.g. button callback)? · Issue #5819 · bokeh/bokeh · GitHub

Puting both together, one can click on a table and open a page with the info in the row.

On Monday, June 5, 2017 at 10:01:40 AM UTC+9, Bryan Van de ven wrote:
Hi,

Getting two independent apps running at the same time is trivial. Getting two apps running at the same time that coordinate different pages on a per-user basis, is not. The basic problem is ensuring that two individual sessions from different apps are strongly tied to and can communicate with each other, and this would definitely be an advanced usage of Bokeh.

Bokeh has a client API that lets you create individual sessions programmatically from python. You can then also navigate browsers to URLs that open those specific sessions. I think to have any hope at actually coordinating rigorously and robustly, you'd have to do something like:

* have app1 use bokeh.client to create a session for the related app2
* have app1 present or open a URL directly to the app2 session

So far, not all that difficult. The last part is the interesting / open-ended pat

* make app1 and app2 sessions communicate somehow

This could be through sockets, web sockets, a database... lots of possibilities tho I am not sure any of them are completely trivial, and any callbacks from one to the other would probably need to put all document-modifying work on the ioloop with a next_tick_callback to ensure proper document locking is happening.

I would be happy to help more with this if you are interested in pursuing it, but would not really have any bandwidth until next week, after the next release is done.

Thanks,

Bryan

> On Jun 4, 2017, at 19:47, mauricio....@sbibits.com wrote:
>
> Hi,
>
> I am trying to do an app with multiple browser windows but I cannot find much reference for it.
>
> The idea is to have a central page/app tieh a table where the user can click a button and open a new window/app with details of a row. Similar to a tab, but in a new browser window.
>
> The way I am doing so far is as follows:
> I can start bokeh server with one app per page (bokeh serve app1/ app2/ app3./ ...), then I could add a link to the hub page that opens an url of the form 'localhost:5006/app2'.
>
> I am not sure if that is a good idea, nor if Bokeh is suitable for that.
>
> The reason to have a second window is to allow my user to 'zoom' in the rows of a table (in the app1) and move plots around without moving the table.
> For example, sometimes the user will want to see rows 2 and 4 at the same time, some times he/she will compare rows 3,4 and 10 at the same time.
> In App1 there would be checkboxes and buttons to open new windows so the user can move them around on the screen.
>
> Any reference on this task?
>
> It should be fairly simple given two apps running at the same time.
>
> Thank you
>
> This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0ad2b070-6dc6-430e-b9de-92756da6b4f5%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/697c9fdc-c736-46e3-a484-03c314791bc2%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

I see. I am trying the option with one app and multiple views. With only one user it should be fairly simple.

But, what are some of the pitfalls you can see with multiple users? The pages do not alyter each other, They are only different views of data loaded and updated by the server.

Also, some reference/example on how to retrive info from HTML using bokeh? (is this info in the session_context?).

And since we are here, is there any way to get the IP from which the session is being requested?

(Should open a new thread for this?)

Thank you. It’s being really helpful

Mauricio

···

On Monday, June 5, 2017 at 11:57:12 AM UTC+9, Bryan Van de ven wrote:

It’s worth mentioning, Bokeh app sessions have access to any HTML query parameters in the URL that opened the session. So if probably would suffice to simple add different ?foo=bar parameters to the app URL to get different “views” of one app.

If you just want to open a brand new detail page every row click or whatever, and you don’t mind new pages/tabs accumulating, then this might be all you need. Just encode enough information in the HTML parameter for each new detail page to load whatever view you want.

But if you want there to only ever be a single detail page, that updates whenever the summary page table is clicked, it seems to me you are back to needing to communicate between two different sessions. If you know there is only ever one viewer, then some approach with shared mutable state in a module that all sessions load (i.e. your global variable idea) might be workable. See the OHLC demo for a similar idea where one thread updates global data that all sessions view. But if you needs to support multiple users, I think this would become fragile fairly quickly. At least, I can think of several potential pitfalls in full generality, but YMMV depending on your specific circumstances.

Thanks,

Bryan

On Jun 4, 2017, at 21:24, [email protected] wrote:

Thank you for the feedback.

On a second thought, what do I gain with two apps running together? Maybe I could do with only one app?

What if I have only one app that updates the document displayed after a click. Example:

Let’s say I want to display Summary Page, and Detailed Page:

On the click on summary page a global variable is updated, an open.window is called and a section is created.

On the Server_lifecycle the on_session_created function checks the global variable if needed, and also the main.py checks the global variable before adding plots to the document.
Depending on the global_variable state either the summary page is displayed (global_var is None), or the detailed page is displayed if global variable has any information.

The server keeps track of each page open and sends the data after every periodc call_back. After one session is closed the on_session_destroyed function removes that page/session from the server loop if needed.

The server could also send data according to a map of IPs in case there are multiple users.

What are the issues I am missing if I do all that as one single app displaying different layout on different sessions?

I could do two apps, but like you said, I would have to communicate. It shluld not be an issue, but also I can’t see any benefit.

Thank you

PS: For anybody else interested on this:

I found this reference that allows me to click on a table and process the data from the row clicked.
https://stackoverflow.com/questions/32321841/add-callback-to-bokeh-datatable

On this other reference Bryan from the past tells you how to open a page with an one line:

https://github.com/bokeh/bokeh/issues/5819

Puting both together, one can click on a table and open a page with the info in the row.

On Monday, June 5, 2017 at 10:01:40 AM UTC+9, Bryan Van de ven wrote:

Hi,

Getting two independent apps running at the same time is trivial. Getting two apps running at the same time that coordinate different pages on a per-user basis, is not. The basic problem is ensuring that two individual sessions from different apps are strongly tied to and can communicate with each other, and this would definitely be an advanced usage of Bokeh.

Bokeh has a client API that lets you create individual sessions programmatically from python. You can then also navigate browsers to URLs that open those specific sessions. I think to have any hope at actually coordinating rigorously and robustly, you’d have to do something like:

  • have app1 use bokeh.client to create a session for the related app2
  • have app1 present or open a URL directly to the app2 session

So far, not all that difficult. The last part is the interesting / open-ended pat

  • make app1 and app2 sessions communicate somehow

This could be through sockets, web sockets, a database… lots of possibilities tho I am not sure any of them are completely trivial, and any callbacks from one to the other would probably need to put all document-modifying work on the ioloop with a next_tick_callback to ensure proper document locking is happening.

I would be happy to help more with this if you are interested in pursuing it, but would not really have any bandwidth until next week, after the next release is done.

Thanks,

Bryan

On Jun 4, 2017, at 19:47, [email protected] wrote:

Hi,

I am trying to do an app with multiple browser windows but I cannot find much reference for it.

The idea is to have a central page/app tieh a table where the user can click a button and open a new window/app with details of a row. Similar to a tab, but in a new browser window.

The way I am doing so far is as follows:
I can start bokeh server with one app per page (bokeh serve app1/ app2/ app3./ …), then I could add a link to the hub page that opens an url of the form ‘localhost:5006/app2’.

I am not sure if that is a good idea, nor if Bokeh is suitable for that.

The reason to have a second window is to allow my user to ‘zoom’ in the rows of a table (in the app1) and move plots around without moving the table.
For example, sometimes the user will want to see rows 2 and 4 at the same time, some times he/she will compare rows 3,4 and 10 at the same time.
In App1 there would be checkboxes and buttons to open new windows so the user can move them around on the screen.

Any reference on this task?

It should be fairly simple given two apps running at the same time.

Thank you

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。


You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0ad2b070-6dc6-430e-b9de-92756da6b4f5%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。


You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/697c9fdc-c736-46e3-a484-03c314791bc2%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

For anyone in the future reference:

To query the “?attr=12” part of the HTML see the attributes of the request, i.e., in the on_session_created function the attributes passed by url are in the session_context.reques.arguments as mentioned by this Issue in Git: Use of the query string by SiggyF · Pull Request #4894 · bokeh/bokeh · GitHub

···

On Monday, June 5, 2017 at 1:20:20 PM UTC+9, [email protected] wrote:

I see. I am trying the option with one app and multiple views. With only one user it should be fairly simple.

But, what are some of the pitfalls you can see with multiple users? The pages do not alyter each other, They are only different views of data loaded and updated by the server.

Also, some reference/example on how to retrive info from HTML using bokeh? (is this info in the session_context?).

And since we are here, is there any way to get the IP from which the session is being requested?

(Should open a new thread for this?)

Thank you. It’s being really helpful

Mauricio

On Monday, June 5, 2017 at 11:57:12 AM UTC+9, Bryan Van de ven wrote:

It’s worth mentioning, Bokeh app sessions have access to any HTML query parameters in the URL that opened the session. So if probably would suffice to simple add different ?foo=bar parameters to the app URL to get different “views” of one app.

If you just want to open a brand new detail page every row click or whatever, and you don’t mind new pages/tabs accumulating, then this might be all you need. Just encode enough information in the HTML parameter for each new detail page to load whatever view you want.

But if you want there to only ever be a single detail page, that updates whenever the summary page table is clicked, it seems to me you are back to needing to communicate between two different sessions. If you know there is only ever one viewer, then some approach with shared mutable state in a module that all sessions load (i.e. your global variable idea) might be workable. See the OHLC demo for a similar idea where one thread updates global data that all sessions view. But if you needs to support multiple users, I think this would become fragile fairly quickly. At least, I can think of several potential pitfalls in full generality, but YMMV depending on your specific circumstances.

Thanks,

Bryan

On Jun 4, 2017, at 21:24, [email protected] wrote:

Thank you for the feedback.

On a second thought, what do I gain with two apps running together? Maybe I could do with only one app?

What if I have only one app that updates the document displayed after a click. Example:

Let’s say I want to display Summary Page, and Detailed Page:

On the click on summary page a global variable is updated, an open.window is called and a section is created.

On the Server_lifecycle the on_session_created function checks the global variable if needed, and also the main.py checks the global variable before adding plots to the document.
Depending on the global_variable state either the summary page is displayed (global_var is None), or the detailed page is displayed if global variable has any information.

The server keeps track of each page open and sends the data after every periodc call_back. After one session is closed the on_session_destroyed function removes that page/session from the server loop if needed.

The server could also send data according to a map of IPs in case there are multiple users.

What are the issues I am missing if I do all that as one single app displaying different layout on different sessions?

I could do two apps, but like you said, I would have to communicate. It shluld not be an issue, but also I can’t see any benefit.

Thank you

PS: For anybody else interested on this:

I found this reference that allows me to click on a table and process the data from the row clicked.
https://stackoverflow.com/questions/32321841/add-callback-to-bokeh-datatable

On this other reference Bryan from the past tells you how to open a page with an one line:

https://github.com/bokeh/bokeh/issues/5819

Puting both together, one can click on a table and open a page with the info in the row.

On Monday, June 5, 2017 at 10:01:40 AM UTC+9, Bryan Van de ven wrote:

Hi,

Getting two independent apps running at the same time is trivial. Getting two apps running at the same time that coordinate different pages on a per-user basis, is not. The basic problem is ensuring that two individual sessions from different apps are strongly tied to and can communicate with each other, and this would definitely be an advanced usage of Bokeh.

Bokeh has a client API that lets you create individual sessions programmatically from python. You can then also navigate browsers to URLs that open those specific sessions. I think to have any hope at actually coordinating rigorously and robustly, you’d have to do something like:

  • have app1 use bokeh.client to create a session for the related app2
  • have app1 present or open a URL directly to the app2 session

So far, not all that difficult. The last part is the interesting / open-ended pat

  • make app1 and app2 sessions communicate somehow

This could be through sockets, web sockets, a database… lots of possibilities tho I am not sure any of them are completely trivial, and any callbacks from one to the other would probably need to put all document-modifying work on the ioloop with a next_tick_callback to ensure proper document locking is happening.

I would be happy to help more with this if you are interested in pursuing it, but would not really have any bandwidth until next week, after the next release is done.

Thanks,

Bryan

On Jun 4, 2017, at 19:47, [email protected] wrote:

Hi,

I am trying to do an app with multiple browser windows but I cannot find much reference for it.

The idea is to have a central page/app tieh a table where the user can click a button and open a new window/app with details of a row. Similar to a tab, but in a new browser window.

The way I am doing so far is as follows:
I can start bokeh server with one app per page (bokeh serve app1/ app2/ app3./ …), then I could add a link to the hub page that opens an url of the form ‘localhost:5006/app2’.

I am not sure if that is a good idea, nor if Bokeh is suitable for that.

The reason to have a second window is to allow my user to ‘zoom’ in the rows of a table (in the app1) and move plots around without moving the table.
For example, sometimes the user will want to see rows 2 and 4 at the same time, some times he/she will compare rows 3,4 and 10 at the same time.
In App1 there would be checkboxes and buttons to open new windows so the user can move them around on the screen.

Any reference on this task?

It should be fairly simple given two apps running at the same time.

Thank you

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。


You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0ad2b070-6dc6-430e-b9de-92756da6b4f5%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。


You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/697c9fdc-c736-46e3-a484-03c314791bc2%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

But just to mention, the full request is not available, only the HTML arguments.

We had originally returned the entire request but this falls over badly as soon as you run multiple Bokeh servers behind a load balancer, for example. In that case it's possible / common for the server that handles to initial HTML request to not be the same process that gets the websocket connection request in which case the request information is missing. We found a way to tunnel just the HTML arguments, but that's it.

Basically this scenario is one of the potential pitfall cases. As I said if you are just running a single Bokeh server for this app, it's more likely you can get away with this approach.

Bryan

···

On Jun 5, 2017, at 01:21, [email protected] wrote:

For anyone in the future reference:

To query the "?attr=12" part of the HTML see the attributes of the request, i.e., in the on_session_created function the attributes passed by url are in the session_context.reques.arguments as mentioned by this Issue in Git: Use of the query string by SiggyF · Pull Request #4894 · bokeh/bokeh · GitHub

On Monday, June 5, 2017 at 1:20:20 PM UTC+9, mauricio....@sbibits.com wrote:
I see. I am trying the option with one app and multiple views. With only one user it should be fairly simple.

But, what are some of the pitfalls you can see with multiple users? The pages do not alyter each other, They are only different views of data loaded and updated by the server.

Also, some reference/example on how to retrive info from HTML using bokeh? (is this info in the session_context?).
And since we are here, is there any way to get the IP from which the session is being requested?
(Should open a new thread for this?)

Thank you. It's being really helpful

Mauricio

On Monday, June 5, 2017 at 11:57:12 AM UTC+9, Bryan Van de ven wrote:
It's worth mentioning, Bokeh app sessions have access to any HTML query parameters in the URL that opened the session. So if probably would suffice to simple add different ?foo=bar parameters to the app URL to get different "views" of one app.

If you just want to open a brand new detail page every row click or whatever, and you don't mind new pages/tabs accumulating, then this might be all you need. Just encode enough information in the HTML parameter for each new detail page to load whatever view you want.

But if you want there to only ever be a single detail page, that updates whenever the summary page table is clicked, it seems to me you are back to needing to communicate between two different sessions. If you know there is only ever one viewer, then some approach with shared mutable state in a module that all sessions load (i.e. your global variable idea) might be workable. See the OHLC demo for a similar idea where one thread updates global data that all sessions view. But if you needs to support multiple users, I think this would become fragile fairly quickly. At least, I can think of several potential pitfalls in full generality, but YMMV depending on your specific circumstances.

Thanks,

Bryan

> On Jun 4, 2017, at 21:24, mauricio....@sbibits.com wrote:
>
> Thank you for the feedback.
>
> On a second thought, what do I gain with two apps running together? Maybe I could do with only one app?
>
> What if I have only one app that updates the document displayed after a click. Example:
>
> Let's say I want to display Summary Page, and Detailed Page:
>
> On the click on summary page a global variable is updated, an open.window is called and a section is created.
> On the Server_lifecycle the on_session_created function checks the global variable if needed, and also the main.py checks the global variable before adding plots to the document.
> Depending on the global_variable state either the summary page is displayed (global_var is None), or the detailed page is displayed if global variable has any information.
>
> The server keeps track of each page open and sends the data after every periodc call_back. After one session is closed the on_session_destroyed function removes that page/session from the server loop if needed.
>
> The server could also send data according to a map of IPs in case there are multiple users.
>
> What are the issues I am missing if I do all that as one single app displaying different layout on different sessions?
>
> I could do two apps, but like you said, I would have to communicate. It shluld not be an issue, but also I can't see any benefit.
>
>
> Thank you
>
>
> PS: For anybody else interested on this:
>
> I found this reference that allows me to click on a table and process the data from the row clicked.
> python - How to add a Callback to Bokeh DataTable? - Stack Overflow
>
>
> On this other reference Bryan from the past tells you how to open a page with an one line:
> Why I can't use OperURL in widget callback (e.g. button callback)? · Issue #5819 · bokeh/bokeh · GitHub
>
> Puting both together, one can click on a table and open a page with the info in the row.
>
>
>
> On Monday, June 5, 2017 at 10:01:40 AM UTC+9, Bryan Van de ven wrote:
> Hi,
>
> Getting two independent apps running at the same time is trivial. Getting two apps running at the same time that coordinate different pages on a per-user basis, is not. The basic problem is ensuring that two individual sessions from different apps are strongly tied to and can communicate with each other, and this would definitely be an advanced usage of Bokeh.
>
> Bokeh has a client API that lets you create individual sessions programmatically from python. You can then also navigate browsers to URLs that open those specific sessions. I think to have any hope at actually coordinating rigorously and robustly, you'd have to do something like:
>
> * have app1 use bokeh.client to create a session for the related app2
> * have app1 present or open a URL directly to the app2 session
>
> So far, not all that difficult. The last part is the interesting / open-ended pat
>
> * make app1 and app2 sessions communicate somehow
>
> This could be through sockets, web sockets, a database... lots of possibilities tho I am not sure any of them are completely trivial, and any callbacks from one to the other would probably need to put all document-modifying work on the ioloop with a next_tick_callback to ensure proper document locking is happening.
>
> I would be happy to help more with this if you are interested in pursuing it, but would not really have any bandwidth until next week, after the next release is done.
>
> Thanks,
>
> Bryan
>
> > On Jun 4, 2017, at 19:47, mauricio....@sbibits.com wrote:
> >
> > Hi,
> >
> > I am trying to do an app with multiple browser windows but I cannot find much reference for it.
> >
> > The idea is to have a central page/app tieh a table where the user can click a button and open a new window/app with details of a row. Similar to a tab, but in a new browser window.
> >
> > The way I am doing so far is as follows:
> > I can start bokeh server with one app per page (bokeh serve app1/ app2/ app3./ ...), then I could add a link to the hub page that opens an url of the form 'localhost:5006/app2'.
> >
> > I am not sure if that is a good idea, nor if Bokeh is suitable for that.
> >
> > The reason to have a second window is to allow my user to 'zoom' in the rows of a table (in the app1) and move plots around without moving the table.
> > For example, sometimes the user will want to see rows 2 and 4 at the same time, some times he/she will compare rows 3,4 and 10 at the same time.
> > In App1 there would be checkboxes and buttons to open new windows so the user can move them around on the screen.
> >
> > Any reference on this task?
> >
> > It should be fairly simple given two apps running at the same time.
> >
> > Thank you
> >
> > This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> > To post to this group, send email to bo...@continuum.io.
> > To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0ad2b070-6dc6-430e-b9de-92756da6b4f5%40continuum.io\.
> > For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
>
>
> This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/697c9fdc-c736-46e3-a484-03c314791bc2%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).本メッセージに記載および添付されている情報(以下、総称して「本情報」といいます。)は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/b8b3faa8-1ea8-4d0c-8c6c-49a3d6458e90%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.