Meta-programming a window?

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?

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.

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.

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.

1 Like

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

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.}

3 Likes