1 –
findItemsMatchingMediaPath being an instance child of ClipProjectIem makes so sense.
Depending on original intent:
-
if
findItemsMatchingMediaPathis supposed to search the whole project → it should bestaticmethod, not an instance method.
… So one would write something like:const allMacthingClipForProject = ppro.ClipProjectItem.findItemsMatchingMediaPath(...); // maybe await depending on internals -
if
findItemsMatchingMediaPathis supposed to find element under the current node (would be most helpful IMO) → it should live underFolderItem- since aClipProjectItemcannot have children (technically it could also live onProjectItembut that is a bit confusing - as too broad).
… So one would write something like:const project = await ppro.Project.getActiveProject(); const folderItemRoot= await project.getRootItem(); const clipProjectItemList = await folderItemRoot.findItemsMatchingMediaPath(...);
But I see no use cases where the API living under ClipProjetItem as instance method would makes sense.
2 –
Also mention in another thread a while back, it make no sense to return a collection of ProjectItem since only clip have a MediaPath associated with them.
It should return a collection of ClipProjectItem.
Sure, user could cast each items received, but why the extra headache when it can be fixed in the API ?
3 – ideally we would have a “Folder” API as well to provide the same capability:
const project = await ppro.Project.getActiveProject();
const folderItemRoot= await project.getRootItem();
const folderProjectItemList = await folderItemRoot.findMatchingFolder(regex, recurse=true);
Many of use probably already have some kind of helper function that simulate that already - but would be a nice convenient API (to avoid everyone to reinvent the wheel).