# Meta-programming a window?

**URL:** <https://forum.inductiveautomation.com/t/meta-programming-a-window/32769>\
**Category:** Ignition\
**Tags:** ignition80, vision\
**Created:** [March 3, 2020, 3:38pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769 "2020-03-03T15:38:35Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [March 3, 2020, 3:38pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/1 "2020-03-03T15:38:35Z")

</div>

Kind of out of the realm of the typical questions there but I figure it's worth an ask. I created my own scripts that serializes/marshalls the form data from a window, and inserts/updates forms based on a naming convention I made for components. This is nice insofar as now my forms are all very standardized and the way I set an initial value, default value, and calculated vaule is pretty much the same for every single component less very tiny differences.

This led me to think about the next step in automating this process. If I could write a python script that would grab the `DESCRIBE tablename` info, get column types, then I know what all my component names would be, what my root container properties would have to be, what custom properties on components I would need to have etc. And if the window was built in XML or something similar, I could just then use that info to make the window, I don't care about making it pretty but if I had all the components already made it'd just be a matter of dragging/dropping for me at that point. This would not only be helpful for me for making new forms, but also refactoring old windows to my new methodology. Is there any way to make this possible?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 3, 2020, 3:58pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/2 "2020-03-03T15:58:18Z")

</div>

If you’re using Perspective, it would be currently possible via a gateway script to insert an appropriately formatted `resource.json` and `view.json` in a new resource folder in your project via direct file operations, which the gateway will automatically register as project resources after a short delay.

There’s also a separate singleton resource `page-config` with its own `config.json` that you’d theoretically have to override.

We’ve talked internally a few times about a ‘dynamic’ endpoint route - where you could mount a specific route, and then Perspective would just run some script that’s able to return correctly formatted JSON to build a view - similar to the idea of Webdev, but more limited in scope, and specific to Perspective. No idea if that’ll ever happen, but it’s a fun idea.

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [March 3, 2020, 4:04pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/3 "2020-03-03T16:04:03Z")

</div>

Ok, my question was actually for Vision unfortunately lol. I’m not sure where I thought I heard this but that the windows are all XML? Someway to make a XML file, then do something to it, so that I could import it into my project properly? I don’t know, I’m just hoping there’d be some way to do this, it would cut down most of the tedious parts of my refactoring process.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 3, 2020, 4:21pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/4 "2020-03-03T16:21:37Z")

</div>

So, yes, (far) under the hood, all Vision windows are technically XML. However, it’s basically impossible to work with in the same way as Perspective. I believe the `data.bin` for Vision windows is _essentially_ that XML, packed into a binary format - but even if you _could_ unpack the binary data into XML, it’s going to be very difficult to parse. There are a lot of disk-efficiency optimizations in place, so manually generating ‘compliant’ XML is going to require basically reinventing the Vision module, warts and all. There’s also a lot of non-obvious implementation details once you get to the low level; for instance, in Vision all bindings are actually “attached” to the root container, not individual components - so they’re stored in an entirely different segment of the XML, but still have to map 1:1 with the components or you’ll get deserialization errors.

What I’m trying to say is that, at least for Vision, at least with the current serialization, there’s basically no way I can see this working, let alone recommend it.

At some point in the future we _may_ improve the way Vision windows are serialized; human-readable diffing is a common request, and an improved serialization format is basically a requirement for that. But it’s a huge technical task, with a lot of regression potential, and limited upsides, so we’re not likely to do it anytime soon.

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [March 3, 2020, 4:23pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/5 "2020-03-03T16:23:48Z")

</div>

Ok, guess its time to program a Java robot to handle this 😉

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 3, 2020, 4:39pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/6 "2020-03-03T16:39:56Z")

</div>

If you want the Vision Window XML to be friendlier, I recommend changing the handler for the window itself to save encoding the InteractionController for last. You may also want to encode the root container first, or nearly first. Almost all of the misery in the existing file format is due to the ‘i’ of the interaction controller coming before the ‘r’ of the root container. (I suspect field serialization is alphabetical.) This one change should cause VisionComponent serialization to approximately follow the display order of the tree.

With this change, the bindings would have object references pointing into the display tree, instead of the display tree having object references into the InteractionController’s bindings.

The next major improvement would come from using window path object references for named components instead of numeric references.

Just these two changes would get you 95% of the way to a reasonably editable XML format.

Another optimization would be an XML shorthand for encoding netbeans-compliant properties without having to spell out all the method names.

{ Edit: I would argue that these are–or ought to be–relatively simple changes to the XML encoder/decoder pair, with very low regression risk. Especially the first one. I’ll bet deferring the InteractionController encoding would yield XML readable without change to the decoder at all.}

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 11, 2023, 11:31am UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/7 "2023-03-11T11:31:13Z")

</div>

Ooooooo!

> [@Nightly 8.1 Changelogs - 2023](https://forum.inductiveautomation.com/t/nightly-8-1-changelogs-2023/68524/30):
>
> Weekly Changelog: 8.1.27-b20230309 Swing 6991: Make plain-text XML format for serialized Vision Windows and Templates deterministic in order to have consistently diff-able files Made Vision's serialization of bindings and other elements consistent and deterministic, to improve VCS compatibility when the XML serialization format is specified.

When I get back from my current travels, I will have to explore how much of my advice was taken... 😁

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 11, 2023, 5:29pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/8 "2023-03-11T17:29:53Z")

</div>

Don't get too excited. Basically it's just that the nodes under the interaction controller are explicitly sorted. Nothing else exciting (yet).

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 11, 2023, 8:48pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/9 "2023-03-11T20:48:54Z")

</div>

> [@paul-griffith](#):
>
> yet

Hmmm. Another three years?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 13, 2023, 3:55pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/10 "2023-03-13T15:55:02Z")

</div>

😬

No guarantees on timeline. The more power users making a stink, the more compelling the argument is for more changes to Vision. Just bully Carl at ICC 🙂

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 13, 2023, 4:15pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/11 "2023-03-13T16:15:07Z")

</div>

> [@paul-griffith](#):
>
> Just bully Carl at ICC

Heh. You mean ply with adult beverages, I presume?

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [March 13, 2023, 4:17pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/12 "2023-03-13T16:17:49Z")

</div>

Going back to the question from years ago now, does this change mean it would be possible to write a pure XML window and bring that into Vision? Or is that still way off

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 13, 2023, 4:23pm UTC](https://forum.inductiveautomation.com/t/meta-programming-a-window/32769/13 "2023-03-13T16:23:07Z")

</div>

If my advice is implemented, I would be comfortable generating window XML from scratch. The key is the elimination of ref ids for components by using component names instead.
