Hi Angela,
You are correct in your original post that the information needs to be extracted from the eventData variable. It seems that there is usually at least a TypeId and an IdList property on this variable though it does change a bit depending on the event type.
Is there a specific use case you had in mind?
Chris
I made some progress. Thanks for the hint regarding the TypeId! I
I currently use a onAfterAdd Version 2 Method and try to add 3 Part Document relationships at once.
[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:f2b3d95b-df7c-4b58-a91f-afc4bfe0f6b1:type=csharp&text=string%20idlist%20%3D%20eventData.IdList.First%28%29%3B%0Astring%20typeId%20%3D%20eventData.TypeId%3B%0A%0A%2F%2F%20Alternate%20approach..%0AIEnumerable%20enumerable%20%3D%20eventData.IdList%3B%0Astring%20idtest%3D%20string.Join%28%22%2C%22%2C%20enumerable.Cast%3Cobject%3E%28%29.Select%28x%20%3D%3E%20x%3F.ToString%28%29%29%29%3B]
Current result: TypeId works, but I only get one item id. I checked the eventData object. It looks like it only contains the first ID of my three new 'Part Document' items.
---
My use case would be all kind of indicators and something related to ECO Affected Items.
Typically I use onAfterAdd/onAfterDelete server events to update the tab counters and an unicode "has BOM" indicator in the grid. Solution is loosely based on the PE files flag concept.
Let´s assume user import a BOM via batch loader with 429 elements. The same Method would be triggered 429 times. This is currently no problem. Systems runs smooth and fast since years.
Occasionally, I refactor legacy code to enhance long-term maintainability and stability. The current solution to update these indicators with version 1 events just feels super wrong and inefficient.
With the above code at least the BOM indicator would work with version 2 events, as I don´t need to count the elements for this use case. But without the amount of relationships it will not work for the tab indicators.
I'm right now questioning whether this approach can actually work, or if V2 events were designed for a completely different purpose.
----------
Some side notes to the use case.
Eli once helped me to get the tab indicator idea running. End users would start a riot if I remove the feature.[emoticon:0f36700dfeb3494fa10d47dd9e1f90a1] But I still rate the concept as too experimental to promote it on a larger scale.
I have a rough concept to improve the overall feature with CUI in I14. Unfortunately I still use 12SP7. For my idea I need a few of the new CUI features, especially relationship accordions.
The current solution use a combination of server methods and a Form onLoad event. I want to get rid of both to achieve the ultimate fast and efficient tab indicator solution. It´s not as revolutionary as "something with AI", but I still believe it adds value.[emoticon:44a8a53ad3364ea78a16c5a3229f75bb]
I think I see the issue you're running into. I believe the batch loader runs all of the applies that it does in sequence one by one, and Version 2 events are only intended to work differently if you specify an idlist or where attribute where multiple items are being returned/updated/deleted at once. So I'm not sure these V2 events will work for this specific use case.
I think your current solution of just updating these counts each time might be the best as inefficient as it is. If you run into slow downs in the future or you ever need to start loading thousands or tens of thousands of items, I can think of a couple other solutions though they would be imperfect.
1. Move the logic that updates item counts to a scheduled event
2. Have the client-side logic that displays the item counts actually perform a count query. The best way to do this would be to set both the page and pagesize to 1 and then look at the itemmax attribute of the returned item to get the full count while limiting the information returned from the database.
page, pagesize and itemmax were the perfect trigger words!!!
Last year I spent a lot of time to integrate paging into my federated ItemTypes. I learned a lot about how Innovator assembles the data in the main grid, form and relationship grids and the paging system itself.
There is already somebody who does the counting and is only triggered once! The countOnly return mode!
I'm not sure what to do with this idea yet. But whatever updates the page counter, can maybe also update my indicators. (if it will work in combination with a batch loader is another question, lol...)
The code that updates the built in page counter is likely only called once you actually click on the relationships tab, so you'd be better off implementing your own custom logic to get the total item count client side if you decide to go that route.
And yes, countOnly does work, but at least in my testing of Release 33, it seems that has now been deprecated. You may want to hold onto the idea of of setting page and pagesize to 1 in the event that you upgrade to the newest open release later this year. It works similarly to the countOnly returnMode except that the data you get back can be accessed more easily through the item attributes.
