I’m utilizing a palette to dynamically load nodes (from a master data model) that are related to whatever is selection by the user in my main diagram. I have a working solution that inflates nodes within the palette based on user selection - but I quickly ran into an organizational problem. I have too many nodes for the user to choose from. They need organization.
The nodes in the palette are logically grouped based on what type of relation they have to the selected node. Example: if the selected node represents a Process, my palette pulls in information related to the process via relation types such as “owner”, “inputs”, “outputs”, etc.
The UX I was designing toward was going to utilize GoJS Groups to containerize the related nodes by which relation type they were. So, the palette would contain a collapsed group called “inputs” and another one called “outputs”, etc, that the user could then expand, and pull from. I can create these groups… however I realized I cannot create a working “SubGraphExpanderButton” in the Palette.
Playing around with the “Macros.html” example, I realized I am able to pull the full group onto my diagram, at which point the SubGraphExpanderButton does properly function.
I am starting to assume this is impossible - given the samples such as the BPMN editor and the https://gojs.net/latest/samples/planogram.html sample both utilize external libraries to achieve this same sort of effect.
My question is - is it possible to expand or collapse Groups inside the palette?
By default Palette.isReadOnly is true, and that is what prevents users from making changes to the nodes of that diagram. You could set that to false and set a bunch of other properties so that the palette allows the behaviors that you want and not the behaviors you don’t want to allow. https://gojs.net/latest/intro/permissions.html
$(go.Palette, . . .,
{
isReadOnly: false,
isModelReadOnly: true,
allowDelete: false,
allowGroup: false, // not needed if there's no CommandHandler.archetypeGroupData
allowInsert: false,
allowLink: false, // not needed if all ports are not linkable
allowMove: false,
allowRelink: false, // not needed if there are no Links
allowReshape: false, // not needed if the nodes are not reshapable
allowResize: false, // not needed if the nodes are not resizable
allowRotate: false, // not needed if the nodes are not rotatable
allowTextEdit: false, // not needed if all TextBlocks are not editable
allowUngroup: false, // not needed if no Groups are ungroupable
. . .
You probably don’t need to set all of those allow... properties, depending on the nature of the node and group templates that you use in the Palette.
Another possibility is to replace the palette’s model each time you want to show a different subset of nodes.
Another possibility is to use multiple Palettes: Planogram
In my case, I didn’t want to utilize the Planogram-style solution, as there are ~20 or so types of relations already and likely to be more added in the future. The replacing technique I hadn’t thought to extend down to the individual types of relations, which is silly because it seems obvious after you pointed it out.
Setting “isReadOnly: False,” will work quite well for my case, I believe. The Palette already uses different Node & Group Templates, and whatever changes they might make in it wont’ be propagated back to the data model behind the scenes. At worst, they’ll just make their view of the palette wrong, which will be corrected next time they select whatever node they currently have selected.
Reviving this topic to provide some context. I am currently trying to implement something similar to agillespie’s description in the initial post. As shown in the screenshot, I am implementing a palette that displays a list of nodes, grouped by a specific property and separated into collapsible/expandable groups.
The Planogram example is a potential solution but not ideal since there will be 15+ different groups. The ‘replacing the palette’ solution doesn’t work either because all groups need to be displaying at the same time (at least the first 5 nodes of each) instead of showing only one expanded group at a time.
Any recommendations for what would be the best structure for implementing the UX as shown in the screenshot? What would the setup look like if I were to somehow be able to include the header, the conditionally collapsed/expanded group of nodes for each type and the expander button all in one palette?
