Re: Lookup on table cells

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Lookup on table cells

Benjamin Ducke
[Sorry, the last message bounced. I hope this one will get
through.]

Hi Flavio,

I think this would make a wonderful addition to gvSIG that many
users could benefit from!

The great thing about gvSIG is that it can also manage non-spatial
tables as part of a GIS project, so designing look-up tables is
actually easy for users.

I would suggest the following:

1. Modify the "Table->Manage fields" dialog. In addition to the
usual data types (String,Double,Integer), the user should be
able to choose type "Look-up". Internally, the Look-up type
could be managed as an Integer of size 9 (the largest that
DBase files can handle).

2. If the user chooses a field of type "Look-up", then (s)he
must also provide:
(a) the name of a table present in the Table section of the current
gvSIG project, to use as a look-up table
(b) the name of an Integer type index field in the look-up
table, to use as the look-up index, and
(c) a field in the look-up table to use as a look-up value.

3. The information entered in (2) needs to be saved as part
of the gvSIG .gvp project file. When loading the project file,
gvSIG should check if all tables used as look-up tables (and
their index and value fields) exist in the Tables section.
If not, it could either just throw an error or attempt to
re-load the table automatically (and then throw an error when
that fails).

4. When editing a table with a look-up field, gvSIG should
display a drop-down box for that field and fill it with the list
of look-up values. The chosen look-up value should be displayed
as field content, not the "raw" integer value of the index field.

5. Modify the "Delete" function for Tables in the Project Manager.
The user should be prevented from deleting a table which still
serves as a look-up table for another table in the project.

6. Modify the "Table->Export" functions (DBase and Excel)
slightly: Upon export, the user should be able to choose
to "hard-link" the look up table values. Instead of the
integer index values, the output table should have the
look-up field types changed to the type of the look-up
value and its contents should be set to the look-up values.
This is to make sure that other people can make full use of
the exported table, without the need to have the look-up tables
also available.

One more thought: the next GSoC is being planned right now.
Maybe adding these and other enhancements to the gvSIG table
features might be an idea for a little GSoC-sponsored project?

Best,

Ben


----- Original Message -----

> Hi to all,
> I have to modify the behaviour of gvSIG tables: I'd like to configure
> some cells as a combobox (whose values are taken from a certain column
> of another table).
>
> I know that this is possible (somehow) and, thus, I would like to know
> if somebody could suggest me the best way to do it..
>
> Best regards,
> Flavio
> _______________________________________________ gvSIG-desktop-devel
> mailing list
> [hidden email]
> https://lists.forge.osor.eu/listinfo/gvsig-desktop-devel


------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

_______________________________________________
gvSIG-desktop-devel mailing list
[hidden email]
https://lists.forge.osor.eu/listinfo/gvsig-desktop-devel
Reply | Threaded
Open this post in threaded view
|

Re: Lookup on table cells

Jorge Sanz (gvSIG)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 10/02/2011 15:01, Benjamin Ducke escribió:

> [Sorry, the last message bounced. I hope this one will get
> through.]
>
> Hi Flavio,
>
> I think this would make a wonderful addition to gvSIG that many
> users could benefit from!
>
> The great thing about gvSIG is that it can also manage non-spatial
> tables as part of a GIS project, so designing look-up tables is
> actually easy for users.
>
> I would suggest the following:
>
> 1. Modify the "Table->Manage fields" dialog. In addition to the
> usual data types (String,Double,Integer), the user should be
> able to choose type "Look-up". Internally, the Look-up type
> could be managed as an Integer of size 9 (the largest that
> DBase files can handle).
>
> 2. If the user chooses a field of type "Look-up", then (s)he
> must also provide:
> (a) the name of a table present in the Table section of the current
> gvSIG project, to use as a look-up table
> (b) the name of an Integer type index field in the look-up
> table, to use as the look-up index, and
> (c) a field in the look-up table to use as a look-up value.
>
> 3. The information entered in (2) needs to be saved as part
> of the gvSIG .gvp project file. When loading the project file,
> gvSIG should check if all tables used as look-up tables (and
> their index and value fields) exist in the Tables section.
> If not, it could either just throw an error or attempt to
> re-load the table automatically (and then throw an error when
> that fails).
>
> 4. When editing a table with a look-up field, gvSIG should
> display a drop-down box for that field and fill it with the list
> of look-up values. The chosen look-up value should be displayed
> as field content, not the "raw" integer value of the index field.
>
> 5. Modify the "Delete" function for Tables in the Project Manager.
> The user should be prevented from deleting a table which still
> serves as a look-up table for another table in the project.
>
> 6. Modify the "Table->Export" functions (DBase and Excel)
> slightly: Upon export, the user should be able to choose
> to "hard-link" the look up table values. Instead of the
> integer index values, the output table should have the
> look-up field types changed to the type of the look-up
> value and its contents should be set to the look-up values.
> This is to make sure that other people can make full use of
> the exported table, without the need to have the look-up tables
> also available.
>
> One more thought: the next GSoC is being planned right now.
> Maybe adding these and other enhancements to the gvSIG table
> features might be an idea for a little GSoC-sponsored project?
>
> Best,
>
> Ben
>

Pretty well detailed functionality, but I wouldn't recommend to modify
so many of the gvSIG core code, it's just a question of maintenance.
Instead of doing so many changes to gvSIG code, IMHO it would be better
to extend it in a new pluggin with as many extensions or libraries as
needed.

Regarding the GSoC, there's a new page for 2011 ideas[1] that I created
some days ago to start gathering ideas and mentors. The process is
slowly starting and as I'm the contact with OSGeo, I'll post here any
update or important info.

Best
[1] http://wiki.osgeo.org/wiki/GvSIG_GSoC_2011_Ideas

- --
Jorge Gaspar Sanz Salinas
gvSIG Team at Prodevelop
Technical Collaborations Manager
http://www.gvsig.org
http://www.gvsig.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEbBAEBAgAGBQJNVAG6AAoJEAOYD75lvHdB4aIH9RcJ3EU0fG9ZwDhR6KLskC1K
UdnfpJPgWZN41U4Yrb3IIjddZ8aUjByvrVEYUg8ffKPa6IRqNhdtD3SvUQcKT7DU
TqLvrQncq+H8Tq/BKZYiXJXeneLD648gqWPGj4HrM5JQIJdwcjaw8yVRl1XBOlLA
p6DcCmJ957/8cMFsCeKjwTKt6CkhU+2bCaKT+kzV8PAwrUivBHYfyoF8hlxarjD4
w2M/APP2B/xOAGSjv96CfHFTVw/V/r3rP2HSa7Xwm+8tmF7dYM5w8gL2+YVmLJI6
ff02plL+QPndmPirhPpLmW+l1DtFdPRxHRxNJAqvh4klQjroF4VYjk7SXqXk7w==
=ZpAh
-----END PGP SIGNATURE-----
_______________________________________________
gvSIG-desktop-devel mailing list
[hidden email]
https://lists.forge.osor.eu/listinfo/gvsig-desktop-devel