Yeah why not.
Scripting in that sense is not diffcult! You just need to know where the information is within the library and some simple syntax rules of the language you choose (which is C# in that case)
Here is whats going on:
You input a (global unique) id of your ‘RhinoObject’ in Grasshopper and pass it to the input port of your ScriptComponent ->
RunScript(Guid id, ref object PageName)
In order to work with it you need to get the actual objects instance:
var obj = RhinoDocument.Objects.FindId(id);
Now any Rhino object consists of the actual geometry and some meta data (Layer, Color …).
To access the meta data you need to call the “Attributes” property of your Rhino object instance.
In there you find a ‘ViewportId’ property. If the ViewportId is set (so you have no empty GUID) it means it only shows up on a certain viewport. (This information is written down by the developers in the api documention. )
A layout view, is also a viewport. Now since we have a viewport id, we can use that to find the corresponding RhinoPageView instance on your active document.
Once we have this we just extract the page name and pass it to our output port called ‘PageName’.
PageName = view.PageName
Essentially any properties related to Rhinoobjects (Style, Layers, Meta data …) are somewhere in that object. Rhinoobjects are stored in (active) Rhinodocuments, such as other things to managed them better (Views, Layers) etc. Usually they are linked by ids, which is a bit unusual, but probably because of persistance (saving, loading) reasons.
Rhino uses inheritance quite extensive, that is why you need cast them from time to time. So if you choose to go for C# one day, it might be a good idea to understand this concept as well. And of course understanding where and what is in the holy grail of Rhino: https://developer.rhino3d.com/api/ helps a lot. Essential things like “baking” are quite simple features (= adding Rhinoobjects to the Document) .