How to detect if a view is 'dirty'?

[Former Member]

Hi,

I'm just developing a Web Dynpro application with which the user can edit product information. The view has a lot of input fields and drop-downs. The view also has a Save button that should only be active if the user has modified at least one piece of data. Is there a generic way to detect user modifications or do I have to add an action to each widget? Is there something like an isModified method or a kind of property change mechanism?

Regards.

[Qualiture · Accepted solution]

When running inside a portal, you have the option to use the WorkProtect feature (WDPortalWorkProtectMode, see http://help.sap.com/javadocs/nwce/ce71/wdr/com/sap/tc/webdynpro/clientserver/portal/WDPortalWorkProt..., but this only works when navigating away from your application...

In your specific case, unfortunately there is no dirty indicator... The only feasible thing I can think of is capture the context upon entering the form, and upon saving compare the current context with the captured context

[Former Member · Accepted solution]

Hi Robin,

thanks for your answer. At least I now have an idea, how to handle unsaved changes in the portal. Meanwhile I have discovered the methods

isChanged

and

isChangedByClient

. I think I have to play around with these to solve my problem...

[former_member182372 · Accepted solution]

Torsten, in wdDoModifyView you can traverse through your UI elements tree and assign same event handler to input fields' onEnter and drop down's onSelect. In that event handler you can compare existing and changed data and set Enabled attribute bound to the button property.

[Qualiture · Accepted solution]

Hi Torsten,

You are right, totally forgot about these methods! However, as of yet I haven't been able to have them working in a way I would expect, but that might be just me

Maksim,

It is generally a bad practice to perform lots of value checks in wdDoModifyView, since this method will be called on each server roundtrip, thus resulting in more overhead.

If you need to check values, always perform these in an event handler (no need to iterate through UI fields, just use the context)

[former_member182372 · Accepted solution]

> If you need to check values, always perform these in an event handler (no need to iterate through UI fields, just use the context)

>  In that event handler you can compare existing and changed data and set Enabled attribute bound to the button property.

[Former Member · Accepted solution]

You are right, totally forgot about these methods! However, as of yet I haven't been able to have them working in a way I would expect, but that might be just me 

I agree with you: These methods do behave a little bit strange and the Javadoc doesn't really help either. The main problem with these methods seems to be that they need a server roundtrip which won't occur if the user just types something into an input field.

Torsten, in wdDoModifyView you can traverse through your UI elements tree and assign same event handler to input fields' onEnter and drop down's onSelect. In that event handler you can compare existing and changed data and set Enabled attribute bound to the button property.

Maybe I have to do it the way Maksim proposed and assign an event handler to each input field and drop-down, although this doesn't look like an elegant solution. Thanks to you both for your suggestions.

[former_member182372 · Accepted solution]

Well, why is it not elegant ?

  public static void wdDoModifyView(IPrivatePEDisplayView wdThis, IPrivatePEDisplayView.IContextNode wdContext, com.sap.tc.webdynpro.progmodel.api.IWDView view, boolean firstTime)
  {
	if(firstTime)
	{
		IWDViewElement root = view.getRootElement();
		traverse(root, wdthis);		
	}
}

public void onActionValidate(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent )
{
IWDELement element = wdContext.<GET_ELEMENT_BOUND_TO_THE_INPUT_FIELDS_AND_DROPDOWNS>;
if(element.isChngedByClient())
{
wdContext.<SET_ENABLED_ATTRIBUTE_BOUND_TO_BUTTON_UI_ELEMEN_TO_TRUE>
}
}

  private static void traverse(IWDViewElement element, IPrivatePEDisplayView wdThis)
  {
  	if(element instanceof IWDUIElementContainer)
  	{
  		IWDViewElement[] children = ((IWDUIElementContainer)element).getChildren();
  		
  		for (int i = 0; i < children.length; i++)
		{
			traverse(children<i>, wdThis);
		}
  	}
  	
  	IWDAction validationAction = wdThis.wdGetValidateAction();
  	
  	if(element instanceof IWDInputField)
  	{
		((IWDInputField)element).setOnEnter(validationAction);
  	}
	if(element instanceof IWDDropDownByIndex)
	{
		((IWDDropDownByIndex)element).setOnSelect(validationAction);
	}
	if(element instanceof IWDDropDownByKey)
	{
		((IWDDropDownByKey)element).setOnSelect(validationAction);
	}
  }

[Former Member · Accepted solution]

Well, why is it not elegant  ?

Well, let's say it is only kind of elegant The problem is, that I need some of the onSelect handlers for dependent fields/widgets. So I have to write handler methods that delegate to handlers that were already set. And that also means handling the parameter mapping correctly. That looks like I have to use all my grey matter for this.

But okay, Web Dynpro has its limitations and one has to get around them 😮