How can I get a collection of the nodes having data.color = ‘pink’ ?
Is there a function such as FindNodesForDataProp(‘color’, ‘pink’) that can feed an iterator ?
The other topics I saw where this was asked received the answer that the developer should code their own search. Does that suggest a for - next loop or iterator combined with an ‘if’ ? Seems a bit low tech for the venerable gojs, imho.
Just to bend my example slightly away from a ‘proper’ node property…let us assume that I’m not using ‘color’ but some property of the model - say ‘theColor’.
I want to find nodes for which the data contains a specific property with a specific value. So I want to find all nodes with a ‘theColor’ parameter in their model data having a value of ‘pink’.
I could iterate as per your suggestion, but with all the great capabilities of gojs I was assuming that I was failing to find such a useful function. I thought diagram.findNodeForData(data) was it but it is not.
As an aside, and the reason I am asking this question, popular JS libraries offer means to store data against HTML elements and provide very useful filter & iteration functions to make simple work of retrieving elements based on such data values. But hey, it’s your product ;-)
“color” is an app-specific property of the model data, so it has precisely the same significance as “theColor” would. In other words, nothing in GoJS expects there to be a “color” property on any model data.
There are several interpretations that I can imagine given your request. Could you be more specific about what you were looking for? Did you want to do pattern matching of a given Object with each Node.data object (i.e. the model data)? Did you just want a predicate to be passed to a function that gathered such Nodes? Under what circumstances did you want to do this?
I’m asking so that I have can get an idea of what we might want to implement next.
It is about finding the collection of nodes for which the model data contains a specific property with a specific value. So a set-based requirement which I believe falls toward your iterators / collection functions.
Just to be clear I think you have the concept of retrieving a single node covered with Diagram.findNodeForKey().
If I can give you a parallel, which might explain why some folks, and I, got muddled in their expectations of Diagram.findNodeForData(). A lot of web developers who moved into client-side dev in the last 5 years or so would have used one of the libraries such as JQuery. I grant you that JQuery and gojs have different purposes but you have to accept that your audience / revenue is partly coming from such a background. JQuery has a use-pattern that allows a developer to easily get collections of elements via a load of selectors (see Selectors | jQuery API Documentation). The point is that this use-pattern engenders an expectation that ‘good’ libraries will support a similar use-pattern. JQuery particularly allows operations on the entire set in the returned collection, or the user can use an iteration for further processing. The result is that a novice developer can modify an html element based on a class, type, parent, or arbitrary data (previously stored) with one or two lines of code.
So when I came to gojs and realised the power of the model / data binding + functions / myDiagram.nodes + iterators / etc I was pre-disposed to expect a means to get a collection of nodes with specific modal properties matching specified values.
When I found Diagram.findNodeForData() I jumped to the conclusion that this was what I needed. However it is not - it requires the node data and I guess it extracts the key and uses that to get the node. That feels like an obscure requirement, at least in my early days with gojs.
What I expected was
Diagram.findNodeForData({: })
So if you were looking for something to develop it would be
Diagram.findNodeForDataProp({: })
which internally iterates over all nodes in the diagram and returns an iterable collection of all nodes where the nodes model data includes prop_name with value = prop_value.
From a function design perspective you need to walk the line between making something simple to use for the majority of cases, then give it the power to meet those tougher needs later. I would argue that the simple property=value search is not a pattern-match but you might be talking with a specific approach you have in mind.
Probably the second most common search would be where the property value is one of a given list of values. That accommodates OR without being overbearing in the call syntax. After that I would put logic in the iteration loop for anything more challenging.
If you think about it, when you know you can grab a collection based on a single function that searches model-node data, then you can pre-build into the model the data that you expect to want to search on.
I think that would cover 75% of use-cases, improve performance (I don’t need to iterate the entire node set of the diagram), and fit the expectations of folks coming to gojs from the light-end of some of the frameworks.
Taking a deep breath…I would suggest that the simple search I am thinking about would be more likely to be a success if you left the need to specify a Regexp out of version 1 ;-) I just looked at the sample you linked to.
I know you guys have plenty of capability and I can see from the results that you do good work so I’ll leave it to you to do the design, just remember to keep it simple !
Could I suggest that you include some explanation in the samples for regexps such as starts with, contains, and ends with as these would cover a good set of use-cases. I have found your samples very useful and cut & pasting usable code is a great accelerator.
Thanks for considering the request and acting so swiftly.