Basexgui Feature suggestion
It would be handy if there was a way to bind results to current context for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results. That binding would be available from editor or input bar. Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter. — Steve Majewski
Hi Steven, To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path. let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml') Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore. This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists! -Tamara On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
It would be handy if there was a way to bind results to current context for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results. That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
-- Tamara Marnell Program Manager, Systems Orbis Cascade Alliance (orbiscascade.org <https://www.orbiscascade.org/>) Pronouns: she/her/hers
Reading the docs closer https://docs.basex.org/wiki/Graphical_User_Interface#Editor <https://docs.basex.org/wiki/Graphical_User_Interface#Editor> It looks like the best shortcut would be saving the results to an .xml file, and using the feature of right clicking on the file to bind to ‘.’ , however that doesn’t appear to work as described. I get a shorter menu of options that what’s shown in that doc: Open Open Externally Run Tests (greyed out and inactive) Refresh Copy Path No “set as context” option. I’m running BaseX 9.7 on a Mac. Is this difference from the docs due to a Mac / PC difference, or has this capability changed and the docs not updated? I’ve also realized, after thinking about some more use cases, that due to the fact that results could be things other than nodes, like maps or arrays, or could be serialized differently, that there may be more issues than I had initially thought with simply binding results to context. I would say that for my use cases, a few extra clicks is less trouble than managing temporary edits to files and reverting them back again. — Steve M.
On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org> wrote:
Hi Steven,
To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml')
Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
-Tamara
On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) <sdm7g@virginia.edu <mailto:sdm7g@virginia.edu>> wrote:
It would be handy if there was a way to bind results to current context for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results. That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
--
Tamara Marnell Program Manager, Systems Orbis Cascade Alliance (orbiscascade.org <https://www.orbiscascade.org/>) Pronouns: she/her/hers
Hi Steven, Just another small tip for this:
I would say that for my use cases, a few extra clicks is less trouble than managing temporary edits to files and reverting them back again.
In the BaseX GUI you can make changes on the fly in the Editor window and click the Run query button, then just close the XQ file without saving. You don't need to save the file, run it, then revert your changes and save again. -Tamara On Thu, Apr 7, 2022 at 1:20 PM Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
Reading the docs closer https://docs.basex.org/wiki/Graphical_User_Interface#Editor It looks like the best shortcut would be saving the results to an .xml file, and using the feature of right clicking on the file to bind to ‘.’ , however that doesn’t appear to work as described.
I get a shorter menu of options that what’s shown in that doc:
Open Open Externally Run Tests (greyed out and inactive) Refresh Copy Path
No “set as context” option.
I’m running BaseX 9.7 on a Mac. Is this difference from the docs due to a Mac / PC difference, or has this capability changed and the docs not updated?
I’ve also realized, after thinking about some more use cases, that due to the fact that results could be things other than nodes, like maps or arrays, or could be serialized differently, that there may be more issues than I had initially thought with simply binding results to context.
I would say that for my use cases, a few extra clicks is less trouble than managing temporary edits to files and reverting them back again.
— Steve M.
On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org> wrote:
Hi Steven,
To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml')
Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
-Tamara
On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
It would be handy if there was a way to bind results to current context for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results. That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
--
Tamara Marnell Program Manager, Systems Orbis Cascade Alliance (orbiscascade.org <https://www.orbiscascade.org/>) Pronouns: she/her/hers
-- Tamara Marnell Program Manager, Systems Orbis Cascade Alliance (orbiscascade.org <https://www.orbiscascade.org/>) Pronouns: she/her/hers
Hi Steven, Thanks to Hans-Jürgen, the "Set as context" menu item was introduced just recently. And thanks to Tamara: Creating intermediate databases is exactly what I do, too. If the query output is a valid XML document, it can also be stored by clicking on the “Save” icon in the result view panel.
I get a shorter menu of options that what’s shown in that doc:
The OS shouldn’t matter. I have Windows, but I’ve just been forwarded a 9.7 Mac screenshot (attached to this mail), and it looks correct. Can anyone else confirm that the menu is not completely shown on a Mac? Do you possibly get output some unexpected errors when starting the BaseX GUI from command line? There is another built-in option to bind the result of a query to the context. It works if you have a database opened and if the query results are nodes from that database. We called the feature “Filter” (the possibly suboptimal term is because this feature was added 15 years ago; at that time, BaseX was limited to a simple XPath implementation). If you open a database and run a query that yields database nodes as results, you can press the filter icon: Your next queries will be based on these results, and all visualizations will adapt to show the result nodes on top level. With the arrow buttons in the menu bar, you can navigate between the previous and next result sets, or you can jump one level up (the parent::node() step will then be applied to all nodes in the result set) or back to the root nodes. Maybe we can generalize the filter feature to work on arbitrary results, no matter what data type they have. One challenge here is that intermediate results can get fairly large, so we shouldn’t include them in the history. Next, if the results belong to arbitrary database nodes, we’d need to create main-memory copies from these nodes or ensure that the context is invalidated once a referenced database will be updated or deleted. Next, we’ll have to take care of … Alright, I’ll stop ;) Further suggestions are welcome. Best, Christian
On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org> wrote:
Hi Steven,
To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml')
Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
-Tamara
On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
It would be handy if there was a way to bind results to current context
for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results.
That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
Thanks, Christian--somehow I had missed the "Set as context" feature, and haven't taken advantage of the filter feature before, even though I work a lot in the BaseX GUI. One small UI change that would make a big difference (to me) would be to provide a drop-down option for files in the Editor (à la oXygen XML Editor), instead of scrolling or stacked tabs. I tend to have many tabs open at once, and neither of the available options is ideal for switching back and forth. I should probably just use the project view, but I like to have more space for the Editor window. Finally, one small issue using the GUI on a MacBook M1 Pro: when I try to change the interface language from the Preferences menu, it doesn't take effect after I restart. I have to manually change the .basex config file to change the language. All best, Tim -- Tim A. Thompson (he, him) Librarian for Applied Metadata Research Yale University Library On Fri, Apr 8, 2022 at 10:20 AM Christian Grün <christian.gruen@gmail.com> wrote:
Hi Steven,
Thanks to Hans-Jürgen, the "Set as context" menu item was introduced just recently.
And thanks to Tamara: Creating intermediate databases is exactly what I do, too. If the query output is a valid XML document, it can also be stored by clicking on the “Save” icon in the result view panel.
I get a shorter menu of options that what’s shown in that doc:
The OS shouldn’t matter. I have Windows, but I’ve just been forwarded a 9.7 Mac screenshot (attached to this mail), and it looks correct. Can anyone else confirm that the menu is not completely shown on a Mac? Do you possibly get output some unexpected errors when starting the BaseX GUI from command line?
There is another built-in option to bind the result of a query to the context. It works if you have a database opened and if the query results are nodes from that database. We called the feature “Filter” (the possibly suboptimal term is because this feature was added 15 years ago; at that time, BaseX was limited to a simple XPath implementation). If you open a database and run a query that yields database nodes as results, you can press the filter icon: Your next queries will be based on these results, and all visualizations will adapt to show the result nodes on top level. With the arrow buttons in the menu bar, you can navigate between the previous and next result sets, or you can jump one level up (the parent::node() step will then be applied to all nodes in the result set) or back to the root nodes.
Maybe we can generalize the filter feature to work on arbitrary results, no matter what data type they have. One challenge here is that intermediate results can get fairly large, so we shouldn’t include them in the history. Next, if the results belong to arbitrary database nodes, we’d need to create main-memory copies from these nodes or ensure that the context is invalidated once a referenced database will be updated or deleted. Next, we’ll have to take care of … Alright, I’ll stop ;)
Further suggestions are welcome.
Best, Christian
On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org> wrote:
Hi Steven,
To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml')
Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
-Tamara
On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
It would be handy if there was a way to bind results to current context
for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results.
That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
Thanks! It looks like using the filter button gets me most of what I wanted. I can run commands from an editor file, click filter button ( assuming it’s XML results ), And make further queries on that output as the context item. I’m building a series of complicated queries to generate a report from subsets of my database. Database is about 25K EAD files from various sources, so the encoding standards and conventions vary, so I’m having to check some of my assumptions as I go along ( like, for example, that IDs are correct and no duplicated within a single source/institution ). I’ve also been trying to figure out how to use unit tests to embed some assertions into the module. It was a little confusing initially as the test button on the editor tab didn’t seem to work. Eventually, I discovered that I had to save the file before it would function properly. I suppose I’m trying to use the unit module in a rather untraditional manner. Since running the tests is a completely different operation from running the query, it wasn’t initially clear that the other operations in the prologue are evaluated, but that does appear to be the case, so it looks like I can use that to test assertions on my various subsets of data before running queries. ( At least, I hope this is how it works! ) BTW: Here’s what I get with 9.7 on my Mac (OS v11.6.4), selecting an .xml file.
On Apr 8, 2022, at 10:19 AM, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Steven,
Thanks to Hans-Jürgen, the "Set as context" menu item was introduced just recently.
And thanks to Tamara: Creating intermediate databases is exactly what I do, too. If the query output is a valid XML document, it can also be stored by clicking on the “Save” icon in the result view panel.
I get a shorter menu of options that what’s shown in that doc:
The OS shouldn’t matter. I have Windows, but I’ve just been forwarded a 9.7 Mac screenshot (attached to this mail), and it looks correct. Can anyone else confirm that the menu is not completely shown on a Mac? Do you possibly get output some unexpected errors when starting the BaseX GUI from command line?
There is another built-in option to bind the result of a query to the context. It works if you have a database opened and if the query results are nodes from that database. We called the feature “Filter” (the possibly suboptimal term is because this feature was added 15 years ago; at that time, BaseX was limited to a simple XPath implementation). If you open a database and run a query that yields database nodes as results, you can press the filter icon: Your next queries will be based on these results, and all visualizations will adapt to show the result nodes on top level. With the arrow buttons in the menu bar, you can navigate between the previous and next result sets, or you can jump one level up (the parent::node() step will then be applied to all nodes in the result set) or back to the root nodes.
Maybe we can generalize the filter feature to work on arbitrary results, no matter what data type they have. One challenge here is that intermediate results can get fairly large, so we shouldn’t include them in the history. Next, if the results belong to arbitrary database nodes, we’d need to create main-memory copies from these nodes or ensure that the context is invalidated once a referenced database will be updated or deleted. Next, we’ll have to take care of … Alright, I’ll stop ;)
Further suggestions are welcome.
Best, Christian
On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org <mailto:tmarnell@orbiscascade.org>> wrote:
Hi Steven,
To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml')
Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
-Tamara
On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) <sdm7g@virginia.edu <mailto:sdm7g@virginia.edu>> wrote:
It would be handy if there was a way to bind results to current context for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results. That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
<mac.jpg>
Hi Tim,
One small UI change that would make a big difference (to me) would be to provide a drop-down option for files in the Editor (à la oXygen XML Editor) It would be good, but seemed to run into some Java Swing issues when suggested before [1]
/Andy [1] https://github.com/BaseXdb/basex/issues/1378#issuecomment-345750203 On Fri, 8 Apr 2022 at 18:37, Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
Thanks!
It looks like using the filter button gets me most of what I wanted. I can run commands from an editor file, click filter button ( assuming it’s XML results ), And make further queries on that output as the context item.
I’m building a series of complicated queries to generate a report from subsets of my database. Database is about 25K EAD files from various sources, so the encoding standards and conventions vary, so I’m having to check some of my assumptions as I go along ( like, for example, that IDs are correct and no duplicated within a single source/institution ).
I’ve also been trying to figure out how to use unit tests to embed some assertions into the module. It was a little confusing initially as the test button on the editor tab didn’t seem to work. Eventually, I discovered that I had to save the file before it would function properly. I suppose I’m trying to use the unit module in a rather untraditional manner. Since running the tests is a completely different operation from running the query, it wasn’t initially clear that the other operations in the prologue are evaluated, but that does appear to be the case, so it looks like I can use that to test assertions on my various subsets of data before running queries. ( At least, I hope this is how it works! )
BTW: Here’s what I get with 9.7 on my Mac (OS v11.6.4), selecting an .xml file.
On Apr 8, 2022, at 10:19 AM, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Steven,
Thanks to Hans-Jürgen, the "Set as context" menu item was introduced just recently.
And thanks to Tamara: Creating intermediate databases is exactly what I do, too. If the query output is a valid XML document, it can also be stored by clicking on the “Save” icon in the result view panel.
I get a shorter menu of options that what’s shown in that doc:
The OS shouldn’t matter. I have Windows, but I’ve just been forwarded a 9.7 Mac screenshot (attached to this mail), and it looks correct. Can anyone else confirm that the menu is not completely shown on a Mac? Do you possibly get output some unexpected errors when starting the BaseX GUI from command line?
There is another built-in option to bind the result of a query to the context. It works if you have a database opened and if the query results are nodes from that database. We called the feature “Filter” (the possibly suboptimal term is because this feature was added 15 years ago; at that time, BaseX was limited to a simple XPath implementation). If you open a database and run a query that yields database nodes as results, you can press the filter icon: Your next queries will be based on these results, and all visualizations will adapt to show the result nodes on top level. With the arrow buttons in the menu bar, you can navigate between the previous and next result sets, or you can jump one level up (the parent::node() step will then be applied to all nodes in the result set) or back to the root nodes.
Maybe we can generalize the filter feature to work on arbitrary results, no matter what data type they have. One challenge here is that intermediate results can get fairly large, so we shouldn’t include them in the history. Next, if the results belong to arbitrary database nodes, we’d need to create main-memory copies from these nodes or ensure that the context is invalidated once a referenced database will be updated or deleted. Next, we’ll have to take care of … Alright, I’ll stop ;)
Further suggestions are welcome.
Best, Christian
On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org> wrote:
Hi Steven,
To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml')
Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
-Tamara
On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
It would be handy if there was a way to bind results to current context
for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results.
That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
<mac.jpg>
Thanks, Andy for fishing out the old issue on this; I remember you’ve once come up with a similar proposal. We’re indeed using the standard Swing component for the tabs, and it’s always a bit risky to modify those (due to the different OS renderings). It migh be easier to add support for the Ctrl-F6 shortcut and provide a sorted list of all file names. In addition, we could add a drop-down component in the menu bar of the editor. Does anyone of you use the shortcut, which is available in Eclipse, oXygen and some other IDEs? Best, Christian On Fri, Apr 8, 2022 at 7:49 PM Andy Bunce <bunce.andy@gmail.com> wrote:
Hi Tim,
One small UI change that would make a big difference (to me) would be to provide a drop-down option for files in the Editor (à la oXygen XML Editor) It would be good, but seemed to run into some Java Swing issues when suggested before [1]
/Andy [1] https://github.com/BaseXdb/basex/issues/1378#issuecomment-345750203
On Fri, 8 Apr 2022 at 18:37, Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
Thanks!
It looks like using the filter button gets me most of what I wanted. I can run commands from an editor file, click filter button ( assuming it’s XML results ), And make further queries on that output as the context item.
I’m building a series of complicated queries to generate a report from subsets of my database. Database is about 25K EAD files from various sources, so the encoding standards and conventions vary, so I’m having to check some of my assumptions as I go along ( like, for example, that IDs are correct and no duplicated within a single source/institution ).
I’ve also been trying to figure out how to use unit tests to embed some assertions into the module. It was a little confusing initially as the test button on the editor tab didn’t seem to work. Eventually, I discovered that I had to save the file before it would function properly. I suppose I’m trying to use the unit module in a rather untraditional manner. Since running the tests is a completely different operation from running the query, it wasn’t initially clear that the other operations in the prologue are evaluated, but that does appear to be the case, so it looks like I can use that to test assertions on my various subsets of data before running queries. ( At least, I hope this is how it works! )
BTW: Here’s what I get with 9.7 on my Mac (OS v11.6.4), selecting an .xml file.
On Apr 8, 2022, at 10:19 AM, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Steven,
Thanks to Hans-Jürgen, the "Set as context" menu item was introduced just recently.
And thanks to Tamara: Creating intermediate databases is exactly what I do, too. If the query output is a valid XML document, it can also be stored by clicking on the “Save” icon in the result view panel.
I get a shorter menu of options that what’s shown in that doc:
The OS shouldn’t matter. I have Windows, but I’ve just been forwarded a 9.7 Mac screenshot (attached to this mail), and it looks correct. Can anyone else confirm that the menu is not completely shown on a Mac? Do you possibly get output some unexpected errors when starting the BaseX GUI from command line?
There is another built-in option to bind the result of a query to the context. It works if you have a database opened and if the query results are nodes from that database. We called the feature “Filter” (the possibly suboptimal term is because this feature was added 15 years ago; at that time, BaseX was limited to a simple XPath implementation). If you open a database and run a query that yields database nodes as results, you can press the filter icon: Your next queries will be based on these results, and all visualizations will adapt to show the result nodes on top level. With the arrow buttons in the menu bar, you can navigate between the previous and next result sets, or you can jump one level up (the parent::node() step will then be applied to all nodes in the result set) or back to the root nodes.
Maybe we can generalize the filter feature to work on arbitrary results, no matter what data type they have. One challenge here is that intermediate results can get fairly large, so we shouldn’t include them in the history. Next, if the results belong to arbitrary database nodes, we’d need to create main-memory copies from these nodes or ensure that the context is invalidated once a referenced database will be updated or deleted. Next, we’ll have to take care of … Alright, I’ll stop ;)
Further suggestions are welcome.
Best, Christian
On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org> wrote:
Hi Steven,
To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
let $results := <results>{ [Your original return in here] }</results> return db:create('my_results_db', $results, 'my_results.xml')
Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
-Tamara
On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) < sdm7g@virginia.edu> wrote:
It would be handy if there was a way to bind results to current
context for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results.
That binding would be available from editor or input bar.
Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
— Steve Majewski
<mac.jpg>
Yes, I do use Ctrl-F6 (in oXygen) On 11.04.2022 08:37, Christian Grün wrote:
Thanks, Andy for fishing out the old issue on this; I remember you’ve once come up with a similar proposal.
We’re indeed using the standard Swing component for the tabs, and it’s always a bit risky to modify those (due to the different OS renderings). It migh be easier to add support for the Ctrl-F6 shortcut and provide a sorted list of all file names. In addition, we could add a drop-down component in the menu bar of the editor.
Does anyone of you use the shortcut, which is available in Eclipse, oXygen and some other IDEs?
Best, Christian
I decided to revise the existing “Recently opened files” popup menu button: • Up to now, a fixed number of recently opened files were listed. A currently opened file was highlighted. • As of now, all opened files will be listed and highlighted. Additionally, files that had recently been opened will be listed (if there are any). • The popup menu can now be addressed with Ctrl-F6 / ⌘-F6. A new snapshot is online [1]. Hope this helps, Christian [1] https://files.basex.org/releases/latest/ On Mon, Apr 11, 2022 at 8:49 AM Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de> wrote:
Yes, I do use Ctrl-F6 (in oXygen)
On 11.04.2022 08:37, Christian Grün wrote:
Thanks, Andy for fishing out the old issue on this; I remember you’ve once come up with a similar proposal.
We’re indeed using the standard Swing component for the tabs, and it’s always a bit risky to modify those (due to the different OS renderings). It migh be easier to add support for the Ctrl-F6 shortcut and provide a sorted list of all file names. In addition, we could add a drop-down component in the menu bar of the editor.
Does anyone of you use the shortcut, which is available in Eclipse, oXygen and some other IDEs?
Best, Christian
BTW: Here’s what I get with 9.7 on my Mac (OS v11.6.4), selecting an .xml file.
I see. The menu item for setting the context had not been embedded in the search panel yet. Things have changed [1]. Best, Christian [1] https://files.basex.org/releases/latest/
participants (6)
-
Andy Bunce -
Christian Grün -
Imsieke, Gerrit, le-tex -
Majewski, Steven Dennis (sdm7g) -
Tamara Marnell -
Tim Thompson