If somebody still have some ideas how to solve the original use case with "version 2" events, I still would be grateful for any hints!!!
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.
