Recently I had a wonderful observation while I was trying to pass Parameters in OA Framework from One Page to another. The difference here was that I had tried to create an icon through Personalization and wished to do no coding at all and still be able to achieve my requirement.

The very obvious approach was to use SPEL expressions and pass parameters just as we do in case the parameters were being created on the Page itself (Remember we set ActionType as fireAction and set SPEL expressions for passing parameters !). So I created an image using Personalization and set the Destination URL as the following: OA.jsp?OAFunc=Function_Name&Param1={${oa.VO_Name.VO_Attribute}}

Very strangely this does not work. So I had to come for some other way of getting around the problem. This is the expression that had to be used to get this working: OA.jsp?OAFunc=&Param1={$VO_Attribute}

Hope this information helps for the readers of this post.

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.

Hi all,
Welcome to my World