Dear all,
I often have some troubles in managing the property datatypes in Perspective. In some cases, I need to convert them in python standard datatypes (list, dictionary, etc.), for example for using the “system.tag.configure()” function.
Is there the possibility to have an Ignition function, able to cast the Perspective datatypes to standard datatypes?
In my coding I have managed the following datatypes (with some difficulties!):
many “com.inductiveautomation.ignition.common.script.adapters”-like types
It would be great to be able to manage the “Object” graphical property as a dictionary and an “Array” graphical property as a list.
What do you think about?
This is a feature I’m actively working on. I’m hoping to do two things:
Make things that should act list lists, dictionaries, etc, act more like lists/dictionaries/etc. In general, that means supporting common Python methods like keys(), pop(), etc. In addition, “magic” methods like __iter__(), so that you can do for x in propertyTree or if x in propTree.
Make sure that these objects can be passed directly to the list() and dict() functions that already exist. That would be the idiomatic Python way to cast them to new objects of those types. That will break the ability to directly update them (currently, things like property trees at least attempt to be directly mutable) but allow you to work with them as native Python types.
Consider doing this entirely with the python wrappers. The resulting objects will retain their Java identity and function within Perspective but will be mutable and iterable as if they were native python objects. If you register the wrappers correctly in the Python subsystem, the wrapping will be entirely automatic anywhere python calls a java method to retrieve one of these objects. And anywhere you deliberately call java2py within perspective to expose one of these objects to a python interface. Please take a look at my experience with Vision's PyComponentWrapper:
Perspective's java objects treated this way will simply be python objects, too.
Currently Perspective is already using the adapter system you mentioned - I’m just piggybacking my work on existing (you’ll notice the class of something like view.container.custom is something like PropTreeScriptWrapper, not PropertyTree. It gets tricky when users expect these Python objects to behave in certain ways - internally, our systems development team requested a lot of dictionary-like methods on property trees, for instance, so they could do a safe tree.get("key", default) instead of tree['key'] and catching a KeyError. We also can’t expose them directly, because that kind of backend internal access would allow you to pretty easily break Perspective, or possibly the gateway itself, in a way that Vision scripting didn’t easily expose to you.
I’m making abstract classes for map/sequence-like ‘wrapper’ types to inherit from so that we can avoid having these problems with unexpected behavior in the future.
Heh, I've stayed out from under Perspective's hood so far... waiting for the churn to subside. /:
Ah, but you may be missing an opportunity here: when you provide a custom wrapper for a java type, you can also leave methods out. You can let jython work directly with these objects, but only in the ways you explicitly permit. This would be true even when accessing that object through other under-the-hood APIs. (:
Also, it's really no more risky than what we can already do with other gateway scripts. Especially with reflection. /: