Monday, December 14, 2009

Pending changes in ADF application

So far I have seen 2 ways to check if there are pending changes in ADF application

1 is from ApplicationModule.getDBTransaction().isDirty();

2. is from DataControlFrame.isTransactionDirty();

Yet their functionality is not the same.
To demonstrate it I created a master –Detail, Departments - Employees test case with backing bean that return :

public String getAmChangesExist() {
BindingContext bc = BindingContext.getCurrent();
ApplicationModule am = bc.getDefaultDataControl().getApplicationModule();
return am.getTransaction().isDirty()?"True":"false";

public String getDcFramechangesExist() {
BindingContext bc = BindingContext.getCurrent();
String currentDataControlFrame = bc.getCurrentDataControlFrame();
return bc.findDataControlFrame(currentDataControlFrame).isTransactionDirty()?"True":"false";

If I change anything on department(except TransientAttribute) or employees and press submit then both methods show there are pending changes.

Yet if I change value of transient attribute only dataControlFrame.isTransactionDirty() shows there is a change, and am.getTransaction().isDirty() shows false

If I press button createInsert on Department or on Employees then again :
dataControlFrame.isTransactionDirty() shows there is a change, and am.getTransaction().isDirty() shows false
I feel that changes should not include transient attributes that dont exist in entities, since they are not used in transaction.
But it should include new rows created on views and entities.
In order to be sure i would chose dataControlFrame.isTransactionDirty() since it also keeps its value even with diferent application modules through task flows with shared data control scope.
Test case:


  1. The ADFM layer does not know what attributes are persistent or transient by design so it's isDirty implementation (used by the DataControlFrame, too) is going to be dirty if any attribute is set.

    The ADFBC layer knows this, and its isDirty() flag will dirty only if an EO-level transient attribute is modified, but won't dirty if a VO-level transient attribute is modified.

    See example #90 on my blog for some code to explicitly make the ADFM transaction pay attention to the ADFBC transaction dirty flag.

  2. Thanks Steve
    I do understand about the transient attribute.

    What i don't understand is why on CreateInsert even though Create method of Entity is executed and we have new entities in cashe, the ADFBC transaction does not show dirty.

    1. Hi Michael,

      Absolutely, isDirty() from ADFBc always returning False, when we call "CreateInsert" on VO using AMDataControl. So, is it recommended always use "dataControlFrame.isTransactionDirty()" ?

      Pls Suggest.


  3. The operations Create and CreateInsert make record status -1 (initialized), and maybe the new row is not hook to transaction.

  4. The operation Create, CreateInsert set row status to -1 (initialized) and are not included in transaction. The user can insert many empty records, and business rules will not executed.