Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Tuesday, December 4, 2012

ADF 11g: Lessons Learned in View Object refactoring

Though this is not a common usecase and a lot of you might think why someone will ever do that? But, while implementing solutions which are not tried earlier by developer there might be switches from creating a entity based view object to transient view object or other way round that is, starting with a transient view object and then later decide to make it entity based. Lets take the later case:

Converting a Transient View Object to Entity base View Object: Overall not a very commonly done activity but for those who may need to do it in future to save some efforts. It is just to go to 'Entity Objects' section on your view definition and then to shuttle the required entity object on which you want to base your view object. After this you may add required attributes from your entity using the option 'Add from entity' and can delete the transient attributes no longer needed.

So, what't the issue?

Well, if you go ahead with that view object definition and create a table based on a view instance of this view object you will see if coming nice. Try CRUD operations like create, update etc. and should be working as expected.  However, when I tried deleting a row it didn't work at all! So, I decided to debug it and one of the obvious way is set a debug point at remove() method of View object's row impl class and entity object's impl class. On debugging, what I found was: it was hitting the remove method in View Object's row Impl but was not stopping at entity object's impl. This indicated me some sort of configuration issues and I decided to create another view object based on the same entity object but this time in the natural expected way. On doing so in less than 2 minutes and spending some 5 minutes in comparing both the VO definitions carefully I found that in my original view object a property is set in the EntityUsages as follows:


    Name="CreditReceiverEO"
    Entity="myapps.model.entity.CreditReceiverEO"
    DeleteParticipant="false"/>

And this explained everything. So, this property was probably set during the transient view creation and didnt get removed when I switched the VO to base on an entity object.

Conclusions:  

1. Avoid shortcuts in creating ADF BC objects unless you really understand the in and out of xml files generated.

2. Whenever you see and awkward behavior try to do the things in natural way by keeping a backup of your existing app so that you can revert back later if needed.

3. If point 2 is not a valid option all the time then just to create a copy or sample project with the same setup but in the natural manner and compare the generated xmls to see if you can find a clue.

Post a Comment