OA Framework has one big limitation. There are others too but my article is going to focus on only one. That is the problem with Root AM Substitution. It really amazes me that everything sans the LOVs work okay after this. Can't visualize how the Lov is coming into picture as most of the LOVs have their own AMs. But I never was an expert of OA Framework internals and as expected of a lazy developer that I am, I never bothered to look inside.
Anyway, Not everytime I can convince the clients that you cannot have this because Oracle doesn't provide that. They want their functionalities, what else are consultants for. So I have come up with a workaround for the Root AM substitution case. Please note that your functionality still may not work if you follow this. But definitely this idea deserves a look.
Didn't I mention that you pay the copyright to me!!.
The idea is simple, create a standalone Class file and have the custom methods written therein. Custom methods for which you would have required another AM. Now to get the handle of the AM instance and the instances of the VOs inside it, we need to pass the pageContext and the webBean information from the Controller. This makes sure you get the handle of the same instance and do the required processing.
In a nut shell this idea is of extending the controller's code in a Custom Class. It gives a feel of having an AM, whereas everything is done still at the Controller level. Your controller remains clean and you are able to provide for some additional functionalities.