Tuesday, August 5, 2014

Standard ADF BC Passivation/Activation for Transient View Object

If you want to implement transient View Object in ADF BC, you must make sure it will be passivation/activation ready, otherwise you may loose data. There are several ways how to achieve passivation/activation for such View Objects - override passivation/activation lifecycle and handle transient View Object rows programmatically or reinitialise transient View Object rows from Application Module prepareSession method. There is one more solution, I'm going to describe it in this post. It is based on dummy SQL based View Object, designed to to store transient attribute values.

Sample application - ADFTransientVOPassivationApp.zip, implements SQL based View Object with transient attributes. Instead of creating completely programmatic View Object, I have created SQL based with single Id attribute based on SQL expression and added transient attributes. This Id attribute is actually never used, it is there just for only reason - to simulate SQL based View Object. As a key attribute is selected one of the transient attributes:


SQL query doesn't fetch any rows, I'm using it only for a single reason - to simulate SQL based View Object. ADF BC knows how to passivate/activate SQL based View Objects automatically, so I'm going to use this feature and force passivation/activation for all transient attributes created for the same View Object:


Just make sure to select Passivate Including All Transient Values option, this will ensure all transient attributes will be passivates/activated automatically, without any coding intervention:


I'm going to test sample application with AM pooling off, this would simulate passivation/activation behaviour for each request:


On ADF UI side, I'm going to implement a table. To be able to enter rows successfully, for such SQL based View Object with transient attributes, I must enable ChangeEventPolicy = ppr option in Page Definition for the iterator:


Input components must be set with AutoSubmit = true option:


On runtime, when I enter rows, all data gets passivated - you can see this from the log. Three rows are entered, data for all attributes gets passivated/activated automatically:

2 comments:

AM said...

Hello Andrejus, could you please explain why we need the changeEventPolicy and autoSubmit settings for this test. The createInsert will submit a request to trigger activation/passivation. And since there is no business logic based on any attribute value change, even if ppr doesn't happen, the fields continue to show the correct value. Many Thanks in advance! AM

Andrejus Baranovskis said...

This sample is set with AutoPPR and ChangeEventPolicy to make sure values will be registered for passivation, when navigating between records in the table.

Regards,
Andrejus