Extending an existing IDO - Polymorphism?

My coding background is in a more traditional object oriented language (Java, C#) so it's taken me a while to adjust my way of thinking to properly use CSI/Mongoose methodologies. I'm currently reworking a project & it's looking much better but I'm now struggling with polymorphism & inheritance.

I'm working on code that allows a user to submit a request for stock items inside CSI. There are currently 3 types of requests I'm being asked to handle: Quantity Move, Job Material Issue and Misc. Issue. I have an IDO called "RequestFromStock". This contains all the common elements that every single request will have. I then created 3 extended IDO's, one each for each request type adding in the missing data for each request.

How would I go about displaying/accessing all of these requests from a Form? Would I have just the primary collection of the "requests from stock" or would I need to include sub-collections, one of each type, and then do some kind of 'trickery' to get the rest of the information our of the sub-collections?

Find more posts tagged with

Accepted answers

All comments

BradleyBrown

I've only ever worked with extended IDOs when they are set to replace, so that is the perspective I'm viewing this from.

If you set the extended IDO to Replace, then calls to the base IDO will be automatically re-routed through the extended version. But, this will only work with one extended IDO per base IDO.

If the key information for the 3 extended IDOs is the same and its just a difference of type, I would do one extension and add a Type property along with your other additions. Use the type property to differentiate your request data.

Unless I am missing something about your question?

Stephen Cena

You're close. I think it's the 'polymorphism' part that's mucking it it. I am going to be testing this today, but this is how I'm hoping it works in CSI/Mongoose: If you have a base IDO/class, and then you extend but not replace it then in your new extended IDO you should get everything the main IDO/class offers, plus whatever you add to the extended one. I am storing the types inside the table. That's how I was planning to future proof this. So if I get asked for another request type I just add the new type, create the newly extended IDO and keep going.

If the extended route doesn't work, then my next thought is I'd need to have subcollections for each request type with permanent filter rules in place to display the correct requests.

I'm trying to make CSI/Mongoose do the majority of the work rather than reinventing the wheel.

Legacy Contributor

I agree with Bradley - the multi-level IDO sounds over-complicated. I would have one IDO with a type that has inputs and outputs that support all types - so sometimes you are sending in or sending back empty values but you have one interface.

Copyright © 2025 Infor. All rights reserved.