[Gvsig_desarrolladores] Generar ejecutable gvSIG 2.0

[Joaquin del Cerro Murciano]

> Hola
> Tal y como me pediste te adjunto la clase DefaultFeatureStore
> 
> Por lo que me comentas, veo que tú también dudas bastante de cómo podemos
> hacer para que funcione sin tener que tocar esta clase
> 
> Lo dejo de momento pendiente hasta ver si se os ocurre la opción más
> fáctible
> 
> Saludos
> 

Hola Leticia,
pues efectivamente solo tienes comentarizada la linea
que invoca al exitEditingMode en el metodo finishEditing.

Eso no es suficiente para que se guarden los cambios cuando el
usuario termine de introducir una geometria sin darle a terminar
edicion. Seguramente tendras tocadas mas cosas a nivel del
plugin de forma, que como te comente en el correo anterior,
estes llamando al finishEditing cada vez que termine de introducir
una geometria.

Cuanto mas lo repaso menos entiendo como ese cambio consigue lo que
dices. Tienes que estar haciendo mas cosas a nivel del
plugin de edicion.


El eliminar la llamada al exitEditingMode tal como lo
has dejado puede acarrear muchos problemas. Los datos ya se han
escrito en el proveedor (BBDD o fichero), y sin embargo no has
limpiado los comandos y tampoco el featureManager. Esto puede
ocasionar incongruencias en los datos en como el usuario
interactue con las herramientas de hacer y deshacer, o como
intente modificar o eliminar una geometria que acaba de dar de
alta.

Ademas de esto se han disparado los eventos de que se ha terminado
la edicion. Al menos la tabla, la propia capa o el dialogo de
hacer/rehacer han recibido ese evento y actuaran como mejor crean.
No se que consecuencias puede tener eso una vez los datos estan
escritos pero a su vez figuren en el featureManager o el spatialManager
como que aun no han bajado a disco.

No se me ocurre forma de mantener la integridad de los datos
habiendolos escrito en la BBDD y a la vez intentado mantener el
historico de comandos tal como se encuentra actualmente, pero
sacrificando eso, si que se podria añadir un metodo al store
que guardase los datos manteniendose en edicion y sin avisar
a los observadores de ello. Esto mantendria la integridad de
datos y no interferiria con herramientas que esten pendientes de
los cambios de estado del store. Seria algo asi como invocar
a un finishEditing seguido de un edit para volver a entrar en
edicion pero sin que ninguno de los observadores se percate
del cambio de estados. Lamentablemente si se perderia el hacer/rehacer.

Podria ser algo como esto:

/**
 * Save changes in the provider without leaving the edit mode.
 * Do not call observers to communicate a change of ediding mode.
 * The operation's history is eliminated to prevent inconsistencies
 * in the data.
 *
 * @throws DataException
 */
synchronized public void commitChanges() throws DataException {
  LOG.debug("commitChanges of mode: {}", new Integer(mode));
  try {
    switch (mode) {
    case MODE_QUERY:
      throw new NeedEditingModeException(this.getName());

    case MODE_APPEND:
      this.provider.endAppend();
      exitEditingMode();
      invalidateIndexes();
      this.provider.beginAppend();
      hasInserts = false;
      break;

    case MODE_FULLEDIT:
      if (hasStrongChanges && !this.allowWrite()) {
        throw new WriteNotAllowedException(getName());
      }
      if (hasStrongChanges) {
        validateFeatures(Feature.FINISH_EDITING);
        provider.performChanges(featureManager.getDeleted(),
          featureManager.getInserted(),
          featureManager.getUpdated(),
          featureTypeManager.getFeatureTypesChanged());
      }
      invalidateIndexes();
      featureManager =
        new FeatureManager(new MemoryExpansionAdapter());
      featureTypeManager =
        new FeatureTypeManager(this, new MemoryExpansionAdapter());
      spatialManager =
        new SpatialManager(this, provider.getEnvelope());

      commands =
        new DefaultFeatureCommandsStack(this, featureManager,
          spatialManager, featureTypeManager);
      featureCount = null;
      hasStrongChanges = false;
      hasInserts = false;
      break;
    }
  } catch (Exception e) {
    throw new FinishEditingException(e);
  }
}

Si te sirve algo parecido podriamos ver de introducir ese metodo
en proximos builds. De hecho podria ser interesante de cara a
simplemente añadir una opcion al usuario que le permita guardar
y seguir en edicion.

...
Repasando un poco mas la primera aproximacion de commitChanges
igual tendriamos que ver de no dejar hacerlo si hay cambios en
la estructura del store. Probablemente tenga algun efecto secundario
poco deseado si sucede (por ejemplo la tabla se volvera majara si
esta abierta).

Pues eso ya comentas si te puede valer algo asi o no, o si tienes
alguna otra sugerencia sobre como abordarlo.

Un saludo
Joaquin

-- 
--------------------------------------
Joaquin Jose del Cerro
Development and software arquitecture manager.
jjdelcerro en gvsig.com
gvSIG Association
www.gvsig.com
www.gvsig.org