El jue., 22 oct. 2020 a las 12:07, Francisco Puga (<fp...@icarto.es>)
escribió:
> Hola,
>
> No tenía claro si el sitio adecuado para este mensaje era alguna de las
> listas o el tracker, así que lo envío por aquí por si hubiera más opiniones.
>
> He encontrado que tras insertar una geometría salta un formulario, y el
> comportamiento de esta funcionalidad tiene varios problemas para mi:
>
>
> - El ancho generalmente está mal ajustado
>
> Por defecto saca un ancho fijo, pero este se puede indicar en el gestor de
columnas para cada tabla en concreto.
>
> - Los campos no editables como la geometría deberían ser gráficamente
> distintos (color de fondo, ...)
> - El texto que sale en la zona de abajo que puede ser el nombre del
> campo con el foco, o un mensaje de error del campo con foco me parece
> confuso. Yo lo quitaría. Es redundante con la modal de error cuando pinchas
> en el campo.
>
> Los datos de una columna, un FeatureAttributeDescriptor, tienen
"descripcion", "etiqueta" y "nombre". En la barra de mensajes de abajo, se
trata de mostrar la descripcion. Si no tiene, la etiqueta, y si no el
nombre. Normalmente si el usuario no ha configurado nada en el gestor de
columnas acaba no teniendo descripcion ni etiqueta y muestra el nombre.
Podriamos evaluar la posibilidad de que si no tiene descripcion no saque
nada; pero tiene mas complicacion de la que parece ya que hemos perdido el
acceso al metodo hasDescription del FeatureAttributeDescriptor en el punto
en el que lo necesitariamos y habria que ver como hacerselo llegar.
>
> - Los nombres de los campos no aparecen directamente si no que a veces
> son "traducidos", pero no se donde están esas traducciones ni cómo
> modificarlas, y son incorrectas.
>
> Pues parece un error, que habria que corregir. Solo deberia tratar de
traducir las etiquetas, no los nombre de campo; pero corregirlo supondria
hacer llegar a donde toca el metodo hasLabel, igual que pasaba con el
hasDescription. Tomo nota para hacerlo cuando tengamos un rato, y de paso
hariamos llegar el hasDescription tambien.
> - El tema de la validación de campos está guay, pero es peligrosa. Por
> ejemplo no tiene en cuenta claves foráneas. Así que puedes rellenar un
> formulario que pase todas las validaciones y aún así dar error al llegar a
> la base de datos.
>
> Actualmente verifica que los campos que en la BBDD estan marcados como
"not null" esten rellenos.
Otra cosa es que hayan mas restricciones que gvSIG no sea capaz de leer de
la BBDD (que pueden ser muchas, claro).
(mas a delante comento mas sobre la validacion de campos).
>
> - Si se pulsa ok, con "campos en rojo" se vuelve a abrir el
> formulario. Si se pulsa cancelar se cierra el formulario pero la nueva
> feature también es eliminada de la capa. El funcionamiento de cancelar para
> mi no tiene sentido. Tienes que tener la opción de introducir varias
> geometrías seguidas, y rellenarlas a posteriori, por ejemplo mediante la
> calculadora de campos.
>
> Una cosa es que te guste o no el tema de que te deje meter features con
campos "obligatios" sin rellenar, que puede
ser discutible e ingluso ir con gustos. Lo que hace me parece correcto. O
aceptas la entrada o la cancelas. Si la aceptas
es por que corriges los errores, y si la cancelas, pues eso, la has
cancelado y la nueva feature no se introduce.
(mas a delante comento mas sobre la validacion de campos).
> Desde mi punto de vista que salga siempre el formulario es muy molesto
> para algunos workflows, y debería poder desactivarse esa opción. Sería
> discutible cual debería ser el valor por defecto. Si me indicáis por donde
> tirar puedo preparar un parche añadiendo esa opción en las preferencias o
> el sistema que veáis.
>
> También estaría bien que esta opción del formulario pudiera habilitarse o
> deshabilitarse por código bajo demanda. Alguna idea de como hacer esto.
>
> Si que creo que debiese poder desactivarse aunque con matices que no tengo
claros, y por codido se pueden hacer cosas para hacerlo, aunque no hay GUI
para ello, bueno, gui de verdad, pruebas si que hay. Te cuento lo que hay
para que puedas probar y ver codigo que lo hace, y luego te resumo.
Los matices... no termina de gustarme que se pueda desactivar para
cualquier capa que tengas cargada. Por un lado creo que deberia poderse
desactivar selectivamente, por otro lado entiendo que haya usuarios
avanzados que prefieran pasar de todas las validaciones. No tengo claro
cual seria el comportamiento deseado.
Los mecanismo que hay para hacerlo permiten ser selectivos para todas las
capas.
El "ejemplo".
Esta la herramienta algo como "Herramientas->desarrollo->Monitor de
edicion" (EditingListenerPanel).
Prueba a jugar con ella.
Se trata de un panel que instala un observador sobre el
EditingNotificationManager. Este manager es el encargado de permitir
atrapar las inserciones de registros desde la tabla o las herramientas de
edicion. Si lo activas veras los distintos eventos de edicion que puedes
atrapar, y desde el tienes la opcion de desactivar la validacion de
features. Ojo que es solo con propositos de desarrollo, con lo que cuando
cierras el panel quita el observer y vuelve a estar activa la validacion.
Pero puedes ver el codigo para ver que/como lo hace.
El resumen podria ser algo como:
EditingNotificationManager editingNotificationManager =
DALSwingLocator.getEditingNotificationManager();
observer = new Observer() {
@Override
public void update(Observable observable, Object notification) {
EditingNotification n = (EditingNotification) notification;
if( saltarValidacionEnEsteEstore(n.getStore()) ) {
n.setSkipFeatureValidation(true);
}
}
};
editingNotificationManager.addObserver(observer);
Ten cuidado que es responsabilidad tuya mantener una referencia al
observer, el EditingNotificationManager no la mantendra (se queda una
weakreference), con lo que si no lo haces simplemente el obserbador se
destruira cuando salgas del ambito de la variable. Por ejemplo, podrias
quedartela en un propiedad de una Extension.
Espero que te sirva algo de lo que te cuento.
Si tienes mas dudas intetaremos ir resolviendotelas.
Un saludo
Joaquin
> Saludos.
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores@listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
--
--------------------------------------
Joaquin Jose del Cerro Murciano
Development and software arquitecture manager at gvSIG Team
jjdelce...@gvsig.com
gvSIG Association
www.gvsig.com
_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores@listserv.gva.es
Para ver histórico de mensajes, editar sus preferencias de usuario o darse de
baja en esta lista, acuda a la siguiente dirección:
https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
