I created a view with a pump graphics, overlay, and a label to use a widget. The parameters of this view control the overlay and populate the label’s text field.
I placed several copies of this view on my main page and passed the corresponding values for the parameters and everything works fine. I added a new parameter to my original view/widget and saved and updated my project, but none of the copies of the view/widget on my main page inherited the new parameter.
These are the parameters for the view/widget. Originally I had Name and Status. The Mode parameter was added after instances of this view/widget were placed on the overview.
After saving, updating, closing, and reopening the project, the instances of this view still only show the original 2 parameters.
Shouldn’t changing the original view change all the instances of that view?
params are not automatically added to props.pararms of an instantiated view. When an instance of a view is originally created, the params must be added to the instance. Any new params added to the view must also be manually added to all instances of the view.
We do not automatically add params to instances of a view, and there are multiple reasons. One reason which many people don’t think about is propagation of values.
Consider you’ve added a new property called “Mode” and set a default value of “Mode”. Would we automatically assign this default value to all instances? The answer is no, because that would result in us applying values were you might not want them. Think about the Embedded View where you’re instancing your “template”; if we had added the new param and value to this Embedded View’s instance, then that template now has a value for “Mode”. If you then change your default value in the template to “off”, this Embedded View’s instance would still have a value of “Mode”. At this point, our heavy-handed application of your properties has resulted in an instance of your View where a value in place is not one you supplied or calculated.
I think there are two separate issues here, passing a new parameter and passing the default value for that parameter. The default value is usually just a placeholder for real data and almost always gets overwritten. Your example is about values of a new parameter, not the parameter itself.
I don’t have much experience with Vision other than the videos on your site, but according to this video, changes made to a template are propagated to all the instances. If you claim change propagation is problematic, then Vision has been doing it incorrectly.
The Vision method makes sense to me because if you had 100 motor instances derived from a template and decided to a label that keeps track of runtime, you would make the change the template and have it propagate to all the instances with a default value of 0. You can bind that value to the PLC tag and you’re done.
In Perspective, it sounds like you would have to go to each instance, delete, and embed a new view.
Why not have an option in the embedded view to inherit or ignore changes to the original view?
But if we put that new parameter in place in the Embedded View, it WILL have a value, whether that value is null or an empty string ("") or the default value. Perspective does not support any instance where a property has no value; there is no avenue for Perspective to supply a property but not also supply a value for that property.
Which is exactly what you're seeing in your example. The default value IS being used, without you needing to specify it as a param. If you do decide to supply "Mode" as a param, then your Embedded View will no longer supply the default value and will instead supply whatever value you supply in EmbeddedView.props.params.Mode.
The link you supplied is for Vision, and we are discussing Perspective. You should not expect claims in a Vision video to also be true in Perspective. That being said, "change" propagation does get passed down; your Embedded View WILL use the default value you have in place without you needing to add it. If you change the default value, the instance in the Embedded View will use the new default value. If you add a new label to the instanced view (Perspective template), then the Embedded View will also have that new Label present.
I understand the video is for Vision and I mentioned it in my message. The point I was making was the behavior of template/instance is different in Vision than Perspective. If the behavior in Vision in acceptable to the user, why is it so different in Perspective?
Maybe there is a better way that I'm not aware of as this is my first real project in Ignitino. This is what I'm trying to accomplish in Perspective. I would appreciate any guidance of how to do it better.
I want to create a master object that I can derive instances from. If somewhere down the line the project changes and requires a change to that object, I want to make the change in the master object and have it affect all my instances. Is there another way to add instances of the master object to my project that would allow that?
The harm is that it would be nearly impossible to do accurately without potential serious negative consequence.
Let’s back up a little bit here:
A view is in control of its own configuration and definition. So, it controls the names and default values of its parameters. It also defines all of its components and their configuration.
An instance of an embedded view is just part of another component’s configuration, which can come in many forms. It could be an embedded view component. It could be in a flex repeater or tab container or even map component. These components have various properties, some of which are then interpreted as “view params” and passed into the sub-view by the embedding component. These view parameters aren’t anything special, really, they’re just properties like any other. They might be configured in the designer by a human, or they might be generated by a binding, or they might be derived by a script and applied.
The point is, it isn’t safe for us, while you’re altering one view, to attempt to reach down into all other views and try and analyze and manipulate their properties.
A) We wouldn’t even know which properties to manipulate, because there isn’t anything truly special about view parameter properties.
B) We wouldn’t be able to know which properties were safe to manipulate, and which ones should be considered dynamically regenerated
C) When exactly would we do this? when you alter the param keyname? when you save the view? It is unclear
D) How about parent/child project relationships? We can’t manipulate other projects when you alter a view configuration.
Now, for the good news:
A) It isn’t strictly necessary to do this, as Cody has pointed out. You may add parameters to your view all you want: you don’t strictly need them to be present in the instance’s params object unless you actually want to specify a different value for that parameter.
B) We are working on a feature to make it more more convenient to deal with these view params in the designer. Two things:
We are going to use the schema system to allow the property editor to understand what viewParam objects are for, and this will allow the UI to suggest any Input or In/Out parameters that are missing
In the same area, we are going to add a “Sync Params” option that will allow you to sync up the params object on an embedded view component in a view that you have open for editing more easily.
Going back to my Vision example though… what’s the difference in Perspective? Don’t these exact things that you brought up affect Vision as well, and if so, why are new template properties synchronised in Vision?
Also, for Perspective, we create the properties specifically as params and these are the only props that are visible from in the embedded view, so don’t you already know what params to look for? If a param exists in the definition View that doesn’t exist in the embedded version, simply add it in
Ok, so, your Vision example is somewhat flawed. In reality, we don't "synchronize" the parameters like you're suggesting we do in Vision. Try it yourself. Make a template. Put that template in a window. Save your project. Now, go and alter the template by adding a parameter. Notice how the window that used that template does not change. Now, when you open up the Window and select your template, it appears like the new parameter is there, but it's really an illusion. In reality, until you opened up the window, the window's instance of that template did not specify the value for the new parameter: look in the XML, you'll see it's missing.
I realize this must sound like a very fine hair to split, so, what's the difference? How is this illusion easy to pull off in Vision but not in Perspective? The answer is that in Vision, the property model is dramatically more constrained. The template parameters are defined by the template instance component. In Perspective, the property model is dramatically more malleable, and fundamentally the user is in control of the property model's shape and form. The components merely suggest its initial form through the JSON schema. I suppose that a template instance could write back to its param property shape upon loading the sub-view, but it'd open a rats nest of issues with bidirectional binding write-backs or conflicting with a property shape being supplied by a binding or script.
If a param exists in the definition View that doesn’t exist in the embedded version, simply add it in
^ The trick is, when, and by whom
Stay tuned here, we've got some solutions brewing that I think are going to alleviate this pain point significantly ( I hope! )
Time for some feedback. As Carl mentioned previously, he’d already been working on a feature which directly relates to this, although it’s not 100% in-line with the requests in this thread.
The feature which is wrapping development works like this:
When the relevant params object of an Embedding component is interacted with by selecting “Add Object member” or clicking the + icon, the context menu where a user would currently select the datatype to add now has an additional slide-over option called “Parameters”. This Parameters slide-over contains two sections: the first section is a list of all of the parameters for the selected View which are NOT currently supplied in this instance, and the second section contains options for adding all of the missing parameters, syncing all parameters to their default values, and syncing all to default values and removing parameters from this instance which are not part of the View’s definition.
Provided a View at Perspective/Views/Instances/MyInstance, with params like this:
A user who then clicks the “Add Object Member” option would expect to see a params option menu like so, where the arrows indicate the “write direction”:
Selecting any of the available parameters adds it to the params object with the default value in place. Selecting “Add All” adds all of the missing parameters with their default values in place. “Sync Params” adds any missing parameters and removes any parameters which are not defined in the View being instanced. “Sync & Reset” adds all missing parameters, removes all extraneous parameters and sets all parameters to their default values, even if those parameters were already in place and had a different value.
So while this feature does not “automatically” update existing instances with new params, it does allow for easily seeing what params might be missing from an instance and it provides a way to synchronize the instance to the “template”.
This feature is still in development and it must still eventually go through QA so it will not make the 8.1.3 release. This is an opportunity to provide feedback on why this might be helpful or unhelpful, or how this might speed development or get in the way.
I like that it doesn’t break existing setups. (Missing params still get default at runtime.) I like that it exposes available view parameters at the point of use. Looks awfully good to me. Kudos.
Thank you @Carl.Gould and @cmallonee for the explanation and preview of the new feature!
I think the ability to see what params are available and the ability to “Add All” are great. I also like that you can quickly see if the Parameter is an input, output, or both.
Excellent. I actually removed “add all” for brevity’s sake - I think “Sync” is going to be the most commonly used option - sync won’t remove any properties that have bindings, change scripts, or are schema-defined.
This makes it SO much more efficient when making changes to ‘templates’ in perspective, especially when one adds numerous params, saving one from the tedious task of manually typing every single one in every single instance.
Thanks for this feature, @Carl.Gould and @cmallonee . And thanks for the explanation!
I'm finding some problems in the way the 'parameter' list is being populated from the embedded view, however. I've removed some of the parameters, but they are still being shown in the list.
Current parameters:
Visible parameters:
Do you have any information on how the list is populated?
Could you send me the view.json file for the Components/AHU/AHU_... view you are embedding? What do you see if you search ALL Views (not just open Views) with the Find/Replace tool for “timeRange”? I just tried adding/removing several params from a view myself and everything worked as expected, even after multiple save events and restarts.
