Before using ShapeDiver, I typically would use groups to organise my script for easy viewing/categorisation. I know that ShapeDiver uses the groups/names within GH to create the UI interface sectioning within the Web Interface. Is there a possibility to ensure only groups that start with for example ‘SD’ in the name would be pulled through, instead of all groups?
A great example that comes to mind is the logic developed here - Automatically Create UI's from Grasshopper Scripts
At the moment, there are two ways to achieve what you want:
In a sense, this is the negative operation compared to your suggestion.
In practice, I agree that for some cases, it might be more convenient to use the prefix route and curate which parameters you do want to show in your model; that depends on the use case. And in general, I agree it is convenient to use traditional groups and ordering on the canvas to define your UIs, because it is Grasshopper-native and intuitive for designers.
However, note that this method has limitations: for example, it is not possible to hide, show, group or re-organize parameters based on the state of your definition. This is one of the reasons why we are slowly moving away from this legacy way to build models, towards a more widespread use of the App Builder framework. Therefore my suggestion would be to directly start building Apps using the App Builder components, for which the grouping and ordering logic is defined explicitly through the components.
That’s a great suggestion.
To your point about the ‘ignore’, I think that fixes the issue however is a little confusing if someone opens up the script and sees ‘ignore’ on a lot of the groups. I personally think if we flip that logic and add a prefix for the groups we want to use, it would be better no?
I am a little confused by the ‘Group1’ reference going into the Parameter reference. How is is picking up that it’s group 1? (I can’t see that you’ve named your groups that’s why I’m confused). Is it picking them based on the order you have them in the script? And if so, can it pick up based on the group name instead of the order they’re in?
I think the App Builder method would be the better route as you’ve mentioned, especially that I can configure various scripts to follow the same logic / control the order of parameters, etc. Do you mind directing me to a video/documentation of how to configure using the App Builder?
Thanks!
I completely agree that using the SD_ prefix would be more convenient in some use cases! We will keep this in mind. However, as I mentioned above, we are moving towards a different logic with the App Builder, which might make these considerations irrelevant in the future.
To answer your question: my screenshot might have been confusing, I just created groups on the canvas that do not have any influence on the actual grouping in the App, to show that this can all be overridden using the App Builder components. In my example, the two first parameters are sent in a first group (using the Parameter Reference component) and then the two next parameters in a second group. This is purely done using the ordering and grouping of the App Builder components. The result would be the same if there were no groups at all on the canvas, or completely different grouping.
That makes sense, thanks for clarifying! In this scenario, to avoid having the groups read at all, we would still have to write ‘ignore’ to ensure they don’t show up, is that correct?
In the App Builder, the groups on the canvas are not used at all, therefore you do not need to write “ignore” in their name. Only groups defined explicitly through App Builder components are represented.
