I wish I could take a Perspective view and easily see which component properties have been customized.
The "simplest" approach I can think of would be to create another view with exactly the same component heirarchy but using all default/initial properties and then diff the two view.json files to highlight the non-default properties. But ... there is no nice and quick way of generating a new duplicate view like that, is there?
Alternatively, I wouldn't mind making an external utility which could ingest and scan a view.json file and only spit out the non-default portions, but I have no idea how that utility could know what the default properties for any particular component would be. I could spend time in Designer adding each component type one by one and copy-pasting the default property tree from each into my utility's source code, but it would be annoying to keep up to date every time IA made tweaks in new versions of Ignition.
I'm actually intrigued in the external utility idea since it is a big step towards making a tool which goes the other way: take a simplified view definition from a more-human-editable revision-controlled text file (maybe YAML?) and convert it back into a full-fleshed view.json. Very often our project has views that are nearly similar, but the bindings/scripts/etc are just different enough that copy-pasting inside Designer is still an all-day effort to adjust them. Coming from a programming background, I would love if I could do all of it in a text file, moving whole blocks in text format and using search-replace. I've tried doing this work in the full view.json, but I have trouble maintaining nesting and telling where I am. (I've actually recently tried running a full view through a JSON-to-YAML converter, editing that, then converting back to JSON and it was easier but still annoyingly verbose...)
I dunno... Like I said, this is all sort of wishful thinking and a bit of rambling. Anyone else out there ever ponder along this direction? Super-wishful thinking, it would be awesome if some future version of Ignition would save views to files in a only-non-default-human-editable format so an external utility wasn't needed.
The problem with that idea is unexpected changes.
If we change the "default" of something (or even completely change the property structure) - which we try not to, but still has to happen sometimes, then we need to be able to "know" - is this a legacy resource we should upgrade, or is this a brand new resource that never had the old behavior? If we only stored changed values, there'd be no way to differentiate. (Devil's advocate: we could, in theory, bump resource versions or something, but that is messy in its own way).
It might be possible to use the SDK to do this; I haven't tried so I don't know if it would work or not. There might be too much delegated to the frontend component's logic to do it "statically" from just the Java code.
It might be a "fun" exercise to create a DSL (or even just model classes) in Python to "express" a view, including bindings, that you could then 'hydrate' into an actual view config. There was a somewhat similar idea that floated around the office when Perspective was first introduced, but it didn't really go anywhere, mostly due to lack of demand.
That's what I was envisioning when I was talking about a "tool that goes the other way". But, if that tool were to be used and maintained over the long run, it would need to have internal knowledge of default properties per version if Ignition, and the view DSL would need a property to indicate which version's defaults to use when. There's no way to avoid fighting the resource versions issue...
It's probably not intractable if it's an Ignition module. Obviously any past version is a fixed target, and there's probably not actually much variation between versions for the vast majority of components. Keeping it up to date would be challenging, though.
Not actually an implementation of the "tool that goes backwards", but I got a smarter YAML library that allowed me to handle multi-line text blobs intelligently. I can now do:
json2yaml view.json > v.yml
edit v.yml in my favorite power editor including full script blocks
yaml2json v.yml > view.json
My editor doesn't recognize the scripts blobs as Python blocks, but ... I can do sane search-replace or other editing across all scripts in a view from one place and see what is happening w/o going crazy!
This has some promise...
The tricky bit was telling the YAML library which text blocks to force to the escaped multiline format:
import ruamel.yaml as yaml
def str_presenter(dumper, data):
if '\n' in data or '\t' in data: # check for complex or multiline strings
return dumper.represent_scalar('tag:yaml.org,2002:str', data, style='|')
return dumper.represent_scalar('tag:yaml.org,2002:str', data)
yaml.add_representer(str, str_presenter)
So, I will admit, I didn't read everything in this thread as its a lot.
But I started writing a vs code extension to allow easier viewing and editing of Ignitions html safe encoded python. I bet I could probably use some of it to show diffs of view contents easier?
Not immediately sure of the answer, really just thinking out loud
(Ignore how slow this is, I blame my .mov to .gif converter, it happens instantly.
e
I am open to ideas on what else to do with this extension, currently I just have a few developers who use it when reviewing pull requests.
Yeah, in my mind all the rambling on this post and the other one I linked about diffing views could be summarized under "I wish I could work on Perspective views using tools and methods like I'm used to from other programming", so your tool fits right in.
