[udig-devel] Re: 3 issues to be discussed/fixed/considered/..

[Jesse Eichar <jeichar@xxxxxxxxxxxxxxx>]

I would have guessed that the FeatureStore would batch the events.  I can work on the fix.  But for now you can start your operation by doing:

Layer layer;

layer.eSetNotify(false);

// do edits

layer.eSetNotify(true);

layer.getFeatureEvents().add(new FeatureEvent( ... the bounds of the change ... ) );

That should work around the issue until we fix the bug.  Also check out other Datastores to see if other datastores have this problem.

Jesse

On 8-Jan-07, at 10:21 AM, Vitali Diatchkov wrote:

2) Imagine there is a filter based on BBOX in the layer from shapefile. When

I call FeatureStore.modifyFeatures(..., Filter) where I put new values for

the set of features filtered by Filter it causes rendering problems later

on. The reason: ShapefileDataStore (actually TransactionStateDiff) sends a

notification for every changed feature and this notification comes to the

Layer class through FeatureListener and causes re-rendering of the layer.

Shouldn't it be a batch notification from GeoTools stuff? Or should events

be collected at the Layer's class level?

The first way constraints low level events making them batched that is not

appropriated for all cases where GeoTools is used. The second approach needs

a special event from low level GeoTools stuff that all modifications are

done and the Layer is able to send batched event to notify listeners

including re-rendering of the layer.  

See boxselection_after.jpg where described effect of not batched

re-rendering is displayed as a result of current behavior.