When @Ivan whas in Berlin we already taked about this a littl bit, but I still wanted to put this out here to maybe have some additional voices.
Right now there is no good way of diccerning what a COMP actually is. A COMP is just an assortment of subnodes, but by now we all have our own small collections, but more importantly, other peoples toxes.
I would wish for a way defined by derivative to give a COMP some kind of fixed indicator what this component is. We could do it ourself using CustomPars, Storage, a dat, you name it. The problem is that we all would have to implement it ourself resulting in non-standardized actions making it only usabl in their own frameworks/family of COMPs.
My proposal would either be a prameter in the Common-Page or a readOnly Property that can be set via CustomizeComponent-Screen/A defined function call.
We then can use
to get a string representation. All ops should have the identity attribute. In case of regular OPs they woul just return the stringRepr of the OP-Type.
+1, it seems that Derivative themselves adopted the ‘About’ custom page pattern for versioning and other metadata in their own tox tools. There are good reasons to push for these fields to become normalized / standardized for everyone instead of being just a good practice.
Useful data:
COMP name / id
Author(s)
Version
URI
(Inspectable) TD verison used to create it.
This is coming for sure, but we’re figuring out exactly what it looks like. Until then, I recommend using custom parameters to track the info you want! Even if it looks different for different developers, it’s important information to have on your components.
I use a somewhat modified version of this for most of my work. The og repo version needs a couple tweaks to behave correctly in the current version of TD. I think a lot of the RFEs mentioned so far on this thread could be addressed by adding base_save to the palette (if it isn’t in there already)
And i am managing it via the PI and someone else also has their own tooling etc. A third party app is not the answer. Also this is not just aimed at toxes bur comps in general.
This is what i meant with and specifically aimed at with this rfe that ot is impossible to define a Standart from a third parzy.
Yes I agree that ultimately Derivative needs to provide a standardized system for this. I am suggesting using 3rd party or roll your own because once we settle on a design internally, it will be a simple script to transfer all your info over if you are tracking it.
What I meant is that putting these things into the palette where, among other things, they can be maintained to properly work with current releases, is a way of standardizing them.
One of my favorite things about TD is that it is fundamentally a fairly minimal and simple set of first principles out of which complex things can be constructed. I’m generally reticent about broadening the complexity of the underlying system when a solution can be derived from the current system.
The palette has many standardized workflow tools (ie: stoner) that are good examples of this.
I think both @alphamoonbase and I know where you’re coming from, nonetheless, we have not seen such standardization take place broadly, even within Derivative’s tooling itself, after many years.
Big +1, this would be a great step towards better tox workflows and TD usage within more complex pipelines (like mentioned here for example).
Each year when new TD experimental branch rolls out, I first search for two things within release notes - linux support (I know chances are low, but I am still optimistic ) and new tox workflow improvements
I also feel like it might be important to note that this RFE is not about external tox workflows.
It can of course be used for the functionality, but the aim is aimed at programming.
The aim is to have a standartised unified, and always existing way, of identifying any Operator.
For example I can give UI-Components specific names depending on their function. Depending on the identity I can programitcaly call functions. I do not have to worry about additional checks if certain parameters exist or similiar.
Similiar for searching OPs. When using a customPar I can of course pass the parName and value to findChildren. But now I need to know what this parameter was called etc.
I could imagine that in the backend a fixed attribute could be hashMapped to do quicker searches.
To add to this, a unique identifier (GUID or UUID) should also be part of this metadata, preferably not one assigned by the container author, but rather TD itself.
I suppose I tend to solve the ‘finding out what type of object I made’ problem currently using the Operator Tagging feature. Tag - Derivative
In networks where I have replicators that can create variants of OPs depending on other data I usually add these programmatically and then, just as you say, do find-children searches and perform operations based on how they match to different tags.
What part of your proscribed workflow (determining custom op type and applying conditional logic) isn’t met by this?
It seems like the process of adding tags is even quite similar to your initially described behavior and, default operators have no tags.
It’s also cool that the tags field is a list which means that rather than an OP having a single ‘identity’ it can belong to multiple relevant classes.
My understanding, and what I think is being proposed, is to have something similar to a “class name”. If you see a custom component as a sort of class, you want a unique identifier for that class. The trouble is that you build a nice custom component meant to be used in multiple places and you copy it… and suddenly a component is both a class and an instance, and has a “name” per instance. So, this unique id or “identity” is a name of the class.
Tags and searches for internal children are great for figuring out a components’ capabilities, but I think it’s still important to have the equivalent of a “class name”
I regret using the term ‘class’ to describe the association with Tags in my previous post because I suppose the way I tend to use them, as you say to describe capabilities, is more analogous to ideas like Traits in rust, wherein they can be used to describe implemented interfaces.
Something that seems cognitively dissonant in this context is that the ‘identity’ needs to be explicitly added as an additional step. If an additional property like “identity” would be used as you describe it, it would be really cool if it automatically persisted through operations like cloning, replication and external tox loading. This makes them potentially valuable outside the context of extensions exclusively. If, instead, adding a unique identity tag is automated during initialization of extension classes, it sort of seems redundant since extensions for a given OP are already accessible through op.extensions
Thats kind of the whole idea, except it does not need to be added, but the property already exists, it needs to be set to aspecific value, but then persists as you describe above. It seems that was not entirely clear.
) and new tox workflow improvements 