There are only 3 numbers to a programmer: zero, one, and infinity.
Object Views in Object Explorer can accept sets of zero or one.
It would really be awesome if we could author Object Views that receive the entire selected or filtered set of objects in Object Explorer.
For example, filter to a Sales Region in OE, and then look at the Object View that displays Total Sales, etc.
While not explicitly in OE as a first-class feature, this is something that can definitely be done in Workshop with a bit of work (after all, the Object Views for a single object are also created in Workshop).
In Workshop, it shouldn’t be too difficult to recreate a similar view to the “Explore” page if the UI matters (otherwise, just use a filter list widget) and the downstream filtered object set variable can be used to create a customized dashboard that aggregates whatever metrics you need.
+1 to @joshOntologize’s suggestion of using Workshop to configure this
You can configure a Workshop to be able to receive a multi object module interface input like this in the variable “Settings” panel:
And then you can configure module discovery in Carbon.
Also see this bottom section for module discovery outside of Carbon if applicable.
So I totally get passing an object set into a Workshop module, and that is what I want to do in an Object View from Object Explorer.
I want to be able to filter an object class in Object Explorer, then tick the CheckAll box, and have that set of objects passed to a module configured as an Object View.
I get that Carbon is where this will likely end up, but in the case of the object class that drove me to write this question, just a few Object Views, a couple for singletons, and a couple for sets in Object Explorer itself would handle everything for everybody.
You should be able to filter in OE as you wish, select the objects you want to open (or use the select all checkbox), and then in the “Open in” menu this is where discoverable modules will appear.
As the docs mention, if you’re in a Carbon workspace then the discoverable modules for that workspace will apply, but outside of Carbon you can still get “Open in” modules from Carbon discoverable modules from promoted workspaces in the user’s org (see docs for more exact details on this).
Could you give this workflow a try and help highlight any remaining feature gaps from what you’d ideally like to do?
Just wanted to +1 the core idea here of “object view for object sets” as a first class thing. I’d like to be able to take my Workshop apps that are configured with the correct interface setup and “attach” them to an object type in the same way we can with single object views.
Could you give this workflow a try
You bet. A quick trip down Documentation Lane really helped.
Thanks evanj.
Cheers
To cap this off - I think this is exactly what Carbon’s “Discoverable modules” is attempting to be. Admittedly I think it’s strange that this happens through Carbon and not something that feels more like a central registry like perhaps in Ontology Manager. Perhaps if there was this central registry you could even configure something like a default module for an object set to open in instead of just a set of modules.
Now that Object View tabs are backed by Workshop modules, Object Views are essentially just acting as this “central registry” of “what Workshop modules should you see as tabs given a Foundry Object”.
We could extend this to something like “Objects Views” where you get a tabbed exploration of object sets with Workshop modules in various tabs - but I think it works just about as well to have separate Workshop modules (which themselves could have multiple tabs) that are individually named for the “Open in” action.
I think it would be nice to eventually move discoverable modules out of Carbon because:
This topic was automatically closed 12 days after the last reply. New replies are no longer allowed.
