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