In regards to the handful of items in perspective that have properties for showing a list of instances like the flex-repeater, view canvas, accordian, etc.
Some of them have the ability to add an “instance” or “item” and it automatically create an entry in the list that has pre-defined characteristics. (i.e. when you create a new instance on a flex repeater it already has the instanceStyle and instancePosition dictionaries included). For that component its really easy to add a dynamic list of items because all you need to do is define two dictionaries for each item.
But for more complicated items like the Accordian, View Canvas, and XY Chart (Axes/series/etc.) is it possible to get that pre-defined dictionary in scripting via the methods on the property itself?
There are quite a few methods on the PropertyTreeScriptWrapper$ArrayWrapper, but I am unable to find any information in the javadocs or anywhere else that describe the arguments and functionality.
Has anyone managed to figure this out, or any chance a developer would know if any of those methods do what I am describing?
Hm. I can’t think of a good way to expose that information via scripting.
Internally, the JSON editor is a Java-level component that parses the ‘schema’ provided by the component to build its knowledge of the properties - expected types, enumeration of values, defaults, etc. A properly-constructed schema for an array property is parsed by the JSON editor so that it automatically adds the extra properties to the object when it’s created.
The most plausible way I could see to add this would be to expose a read-only schema property on the ComponentModel#SafetyWrapper class that you actually interact with in scripting; then you’d have to build your own implementation that walks through the JsonSchema and finds out what’s required/default…
Since the “required” list is in the component.schema.json that is parsed for the JsonSchema, than I would think it should be pretty easy to look at the required list from a read-only schema, determine the properties that are inside of the “items”/“instances” property and parse those into a template dictionary.
It wouldnt be the most obvious thing in the world, but the alternatives with either hard-coding the dictionary in python, or keeping a template copy of the dictionary in custom props, means that it could potentially break if a future version requires a property that previously didn’t exist.