View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011077 | MMW v4 | Framework: Scripts/Extensions | public | 2013-07-18 15:08 | 2013-07-24 21:47 |
| Reporter | zvezdan | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0011077: SQL queries as node properties for built-in and custom nodes needed | ||||
| Description | It would be nice if we could get the SQL query used to display tracks in the tracklist when some built-in or custom node is selected, and to get SQL query used to add sub-nodes when some node is expanded, something like this: ISDBTreeNode::SelectingQuery As String ISDBTreeNode::ExpandingQuery As String For built-in nodes those properties could be read-only, but for custom nodes they should be read/write. For custom nodes, when you write to those properties it would not start the execution of SQL queries since we already have events/methods for that (OnFillTracks/AddTracksFromQuery for selecting nodes and OnFillChildren/OpenSQL or QuerySongs for expanding nodes). Instead, they would have just informational nature which could help e.g. in multi-script communication. Here is one example. I have Export/Create Playlists script which creates playlist files for each sub-node of some selected node. Until recently it worked by expanding/selecting every sub-node to get tracklists for every one of those nodes as you would get by manually navigating through the Tree. With the latest version of the script I am using SQL to get the tracklist content which drastically fastens the execution of the script since it doesn't need to wait for OnTrackListFilled event for each node. Now, for built-in nodes from the Library (and collections) I could get the RelatedObjectID for each node and build the SQL string based on the corresponding branch (e.g. for Artist it would be WHERE IDArtist = RelatedObjectID, just simplified). I have done that for almost all nodes from the Library, but those SQL queries are hard-coded in my script. That means, if you decide to add some new node to the Library branch, e.g. Involved People, I need to update my script accordingly. However, if I have available the suggested SQL queries for nodes, I could write the script which would work without any modification even if you decide to add some new node. Speaking about custom nodes, I have implemented some kind of communication between Magic Nodes and Export/Create Playlists scripts using CustomData node property, but that single property is already used for many other things even within Magic Nodes, and I need to parse its value to get the right SQL string used to get tracks for selected nodes. It would help if we could have the new official properties for such purposes, e.g. which could tell one script how some another script have filled tracklist using SQL. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
