Editing ESRI GeoDatabases

Editing of ESRI GeoDatabases was not previously supported by the spatial editing extension.

If you are editing a database with Weave that has been enabled as a GeoDatabase then it is likely that the GeoDatabase metadata managed by ArcGis is now out of sync and this can result in the inability to create new records with ArcGis.

There is a hotfix available for the 2.5.27, 2.5.28 and 2.5.29 releases of Weave that resolves the issue (currently only for SQL Server) and should be applied as soon as possible, http://downloads.cohga.com/weave/.

The hotfix will stop the issue from occurring in the future but will not repair any feature datasets that are already out of sync, and additionally the hotfix will now make it more likely that Weave will no longer be able to create new records (since Weave now follows the same process as ArcGis when creating records).

To repair any feature datasets that have been edited with Weave they will need to be copied to a new feature dataset, the old feature dataset deleted, and the new feature dataset renamed to replace the old broken feature dataset (as this will reset the metadata for the feature dataset).

Update:

Postgis/Postgres and Oracle are not supported for editing an ESRI GeoDatabase at all, and in fact GeoDatabase enabling the database may make them unavailable to Weave as a spatial engine completely.

The spatial editing extension for Weave provides a means to edit geometry and attributes for an entity.

Features:

Simple to setup for basic operation
Configure the id, label and entity and Weave will do the rest.
Customisable for advanced operation
Refine geometry setting and input parameters, and provide pre-defined lists of values for input.
Supports editing on an entity with multiple spatial layers
A single entity that is composed of separate point, line and/or polygon tables is transparently handled by Weave.
Creation and updating on an entity in the client can be initiated from URL parameters
The Weave client can be started with parameters in the URL to immediately begin the editing process for a specific entity for the user.
Auditing of editing operations
Custom auditing can be setup to write a new log records to a database table for each edit operation performed by a user.
Snapping of geometry
Configurable snapping is available to help with drawing geometry.
I18n support
All of the text/labels for the editing components can be customized for multiple languages or even just having the default text changed.
"Identity" columns
It's possible to specify that an attribute for a new record is based on incrementing the previous highest value of the column, or that the column will be automatically generated by the underlying database system.
Read-only columns
It's possible to specify that an attribute can be displayed but not changed (readonly), can only be changed when the entity is created (readonlyonupdate) or can only be changed when an entity is updated (readonlyoncreate).
Hidden columns
It's possible to specify attributes that aren't visible to the user but are still written when an edit is performed, using either a fixed value or one of a number of supported functions.
Formula columns
It's possible to specify a number of in-built formulas as the value for a column, including things like userid(), datetime(), entity(), area() and length(). These can be used for both the spatial and audit tables.
Restrictions on the number and types of geometry
Geometry input can be constrained to indicate a minimum and maximum number of geometries that can be entered when creating an entity and the types of geometries can be specified.
Customization of client view
The display of the input panel can be customized via the configuration. Some things that can be customized are if text and/or icons are display in buttons, which buttons are displayed (hiding the polygon button for example) and the locations of some of the buttons.

Limitations:

Only attributes directly attached to the spatial table can be edited
Weave will only write to the spatial table when editing an entity, currently having some attributes written to the spatial table and other attributes written to separate database tables is not supported. Audit tables may provide enough functionality to support the required workflow though.
Spatial mapper for entity must have <dynamic> set to true and <cache> set to false
But this is generally the case for any entity that can have its underlying data altered on the fly.
A database table will require a primary key
If you're editing data in a database and are unable to edit the table, ensure that it has a primary key.
Does not support ESRI GeoDatabase enabled databases
Once you've edited a table with Weave the objectid generation might get out of sync with ArcGIS and stop you from being able to edit the table within ArcGIS. Non-geodatabase enabled databases are fine. Update: 2.5.27.14, 2.5.28.10 and 2.5.29.4 now support GeoDatabases editing on SQL Server (other databases to be supported in the future). Note: Versioned, Archived and Edit Tracking require special attention to setup in Weave, ensure you're familiar with these before attempting to editing them in Weave, and Branch Versioning is not supported at all.

Installation

Currently, the Weave editing sub-system is provided as a single bundle, com.cohga.spatial.edit. This bundle must be copied to the weave\platform\plugins directory and the server restarted for it to be available.

Requirements

Configuring Entities

Before you can edit an entity there are some criteria that need to be met.

The entity id must be unique within a spatial table. If an entity is composed of multiple spatial tables then it may be the case that the id may not be unique across all of the tables. If for example the entity is composed of more than one geometry type and the underlying spatial engine (e.g. ArcSDE, shapefiles) does not support different geometries in a single table, then the geometry would need to be spread over more than one table. In this situation, the entity id would have to be the same in all of the spatial tables, but it must at least be unique within each table. This is the only way that Weave can determine which row in the table that it needs to update as Weave determines which spatial table to update based on the geometry type stored in the spatial table.

The editing of multiple spatial tables is only fully supported when a different geometry type is stored in each table. That is, if an entity is linked to more than one spatial table then each spatial table should contain a different geometry type (point, line or polygon). This is so that Weave knows which table to write the appropriate geometries to. For example, if you were to have an entity linked to two spatial tables, both containing polygon geometry, then when an edit is submitted that contains a polygon, Weave would not know which table the geometry was supposed to be added to or updated in.

In the case of an entity represented by multiple spatial tables, the schemas for the tables should all be the same. This is a requirement because the same attribute values will be written to each table when an edit is submitted that contains different geometry types.

Spatial engines that do not differentiate between geometry types, (i.e. the spatial table stores "geometry" and not specifically points, lines or polygons) are not currently supported in multi-table configurations. This is because in these cases, Weave cannot determine which table to write the geometry to (they are supported in single table configurations). This may change in the future.

Additionally, the spatial mapping associated with any entities that are to be edited should be configured to be dynamic, see Spatial Mapper.

Configuration

Client Edit Plugin

Part of the client side editing sub-system is implemented as a 'plugin' for the map view, so the first thing that needs to be done when enabling the editing sub-system is to register the edit plugin with the map view in the client configuration.

Adding edit plugin to client

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" xmlns:client="urn:com.cohga.html.client#1.0">

  <client:config id="edit">
    <!-- more config items here -->

    <view id="com.cohga.html.client.map.mapView">
      <label>Map</label>
      <location>center</location>

      <!-- Register the edit plugin with the map view -->
      <plugin id="weave.edit"/>

      <!-- map config items here -->
    </view>

    <!-- more config items here -->
  </client:config>

</config>

The provides the edit sub-system with a hook into the map view so that it can provide access to the editing layer.

Client Edit View

When performing an edit a view panel is required to enter/change the attributes associated with the entity being edited. This view is provided by the com.cohga.client.panel.edit view and so also needs to be added to the client configuration.

Adding edit view to client

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" xmlns:client="urn:com.cohga.html.client#1.0">

  <client:config id="edit">
    <!-- more config items here -->

    <!-- Add the Edit panel to the client -->
    <view id="com.cohga.client.panel.edit">
      <label>Edit</label>
      <location>west</location>
    </view>

    <view id="com.cohga.html.client.map.mapView">
      <label>Map</label>
      <location>center</location>

      <!-- Register the edit plugin with the map view -->
      <plugin id="weave.edit"/>

      <!-- more config items here -->
    </view>

    <!-- more config items here -->
  </client:config>

</config>

This view also provides the actions required to initiate editing and the tools required to perform the spatial edit operations.

Client panel buttons

name	description
Create	Insert a new entity. Will be disabled if editing is in progress.
Update	Change the currently selected entity. Will be disabled if no entity is selected or if there is more than one entity selected or editing is in progress.
Delete	Remove the currently selected entity. Will be disabled if no entity is selected or if there is more than one entity selected or editing is in progress.
Reset	Reset the form fields back to their original values. Will be disabled if editing is not in progress.
Submit	Complete the edit process and save the current changes. Will be disabled when editing isn't in process or if the current state isn't value, for example if a polygon geometry is required but hasn't been added yet.
Cancel	Abort the edit process and abandon the current changes. Will be disabled when editing isn't in process.
Modify	Modify an existing geometry. Will be disabled if there is no geometry attached to the entity.
Point	Create a new point. Will be disabled if the entity doesn't support point geometry or if it only supports a single point and there already is a point attached to the entity.
Line	Create a new line. Will be disabled if the entity doesn't support line geometry or if it only supports a single point and there already is a line attached to the entity.
Polygon	Create a new polygon. Will be disabled if the entity doesn't support polygon geometry or if it only supports a single polygon and there already is a polygon attached to the entity.
Remove	Remove the currently selected geometry. Will be disabled if there is a) no geometry enabled or, b) if the entity requires some geometry and this is the last piece of geometry related to the entity.
Snap	Toggle the snapping function on and off.
Settings	Changes the snapping settings.
Import	The import button allows the user to import geometry from another entity.

Customising the client edit view

There are a number of customisation options available to alter the display of the edit view

name	type	default	description
enableCreate	boolean	true	Should the 'Create' button be displayed
enableUpdate	boolean	true	Should the 'Update' button be displayed
enableDelete	boolean	true	Should the 'Delete' button be displayed
enableModify	boolean	true	Should the 'Modify' button be displayed
enablePoint	boolean	true	Should the 'Point' button be displayed
enableLine	boolean	true	Should the 'Line' button be displayed
enablePolygon	boolean	true	Should the 'Polygon' button be displayed
enableRemove	boolean	true	Should the 'Remove' button be displayed
enableSnap	boolean	true	Should the 'Snapping' button be displayed
enableSettings	boolean	true	Should the 'Settings' button be displayed
enableImport	boolean	true	Should the 'Import' button be displayed
showText	boolean	false	Should the text label appear in the create, update, delete and reset buttons? This only applies to the default toolbar, if you replace the default toolbar with your own you'd need to set showText to the appropriate value for each button, also note that this value defaults to true in that situation. The default was changed from release 2.6.4, the default was previously true. This is removed from release 2.6.5, text will never be shown.
showIcon	boolean	true	Should the icon appear in the create, update, delete and reset buttons? Note that this only applies to the default toolbar, if you replace the default toolbar with your own you'd need to set showIcon to the appropriate value for each button. Setting this to false will set showText to true if it is not explicitly set. This is removed from release 2.6.5, icons will always be shown.
embedButtons	boolean	false	Should the 'Submit' and 'Cancel' buttons be embedded in the form (or remain in the toolbar) This is removed from release 2.6.4, the buttons will always be embedded in the input panel.

Button display based on showIcon and showText values

	showText unset	showText true	showText false
showIcon unset	icons/no text	icons/text	icons/no text
showIcon true	icons/no text	icons/text	icons/no text
showIcon false	no icons/text	no icons/text	icons/no text

Edit View with showText set to false and showIcon set to true

Server Edit Configuration

Before an entity can be edited it must have at least one edit configuration associated with it. The edit configuration enables editing for the particular entity and also allows for overriding the details about the way the user can edit the entity. Examples are what attributes the user can edit and or how the attributes are presented to the user.

You can have multiple edits associated with each entity. The user will be able to choose which edit to perform by selecting from a list.

Basic Server Edit Configuration

The most basic edit configuration interrogates the underlying spatial tables for the information it requires. (e.g. to determine what attributes are associated with the entity or what spatial geometries, point, line or polygon, the user is allowed to create)

Simple edit configuration example

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" xmlns:edit="urn:com.cohga.spatial.edit#1.0">

  <edit:config id="simple.edit">
    <entity>graffiti</entity>
    <label>Graffiti</label>
    <description>Report graffiti for removal</description>
  </edit:config>

</config>

This provides a simple way to setup editing for an entity and allow the user to directly edit the attributes attached to the entity in the underlying spatial table.

The edit configuration has a publish setting, which when set to false will stop the edit from appearing in the list of edits available for an entity. The edit will still be available but can only be initiated via code or a URL parameter, this provides for the creation of custom editing clients that do not have their edits listed in standard editing clients.

Default editing attributes

The basic edit configuration enables all attributes available for editing. Also, the basic configuration does not provide an option to customise how the user will be able to edit those values, which will be determined by the underlying column type in the spatial table and be limited to simple field types (e.g. text fields for string and numbers, calendar field for dates).

Default geometry requirements

The types of geometry the user will be able to create or edit will also be determined by the underlying spatial table. If the spatial table contains polygons then the user will only be able to create polygons and they will not be able to create points or lines. If however the entity is linked to two spatial tables, one containing polygons and the other containing points then the user will be able to edit both points and polygons.

There is differentiation between spatial layers that contain single instance geometry and those that contain multi-instance geometry. That is, if the spatial table contains multipolygons, as opposed to just polygons, then the user will be allowed to create more than one polygon shape when editing the entity. When the spatial table contains polygons the user will be limited to a single polygon object. The same differentiation applies to points or multipoints and lines or multilines.

The requirement for the user to create geometry is also determined by the underlying spatial table. If the spatial table allows nil geometry then the user will not be forced to create a geometry when creating a new entity however if the spatial table doesn't allow nil geometries then the user will be required to create a geometry before they will be able to complete the edit.

Customising Server Edit Configuration

If you need more control over the attributes and geometry for an edit then you need to override the values that the simple form is generating.

The things that you can override are the parameters that the user can edit, the maximum number of geometry items the user can create, the required number of geometry items the user must create, and if the user can create, update and/or delete an enitity.

Basic custom edit configuration example

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="urn:com.cohga.server.config#1.0" xmlns:edit="urn:com.cohga.spatial.edit#1.0">

  <edit:config id="custom.edit">
    <entity>graffiti</entity>
    <label>Grafitti</label>
    <description>Report graffiti for removal</description>
    <geometry>
      <point minimum="1" maximum="1"/>
    </geometry>
    <parameter id="description">
      <label>Description</label>
      <controlType>textarea</controlType>
      <column>DESCRIPTION</column>
    </parameter>
  </edit:config>

</config>

Please note that the <column> value is case sensitive. "DESCRIPTION" is not the same as "Description"

Custom geometry requirements

Unless explicitly set the types of geometry that a user can create for an entity, and also if the user can create an entity with no geometry, is defined by the underlying spatial tables, if you wish to override this then you do so with the geometry settings.

The geometry settings determine the minimum and maximum number of each geometry type (point, linestring and polygon) that the user can create, as well as the total number of geometry items (of any type) that the user can create.

This is done by specifying point, linestring, polygon and/or geometry items, and for each one specify the minimum and maximum value for each. If no point, linestring or polygon setting is specified then the user will not be able to create those geometry types, unless geometry is specified in which case the user can create all geometry types.

Some examples of why you would want to set these values are (these assume that you can't change the underlying spatial table):

Spatial table allows nil geometry but you wish to enforce geometry creation

<geometry minimum="1"/>

<geometry>
  <polygon minimum="1"/>
</geometry>

Spatial table allows multi part geometry but you wish to enforce creation of single part geometry

<geometry maximum="1"/>

<geometry>
  <polygon maximum="1"/>
</geometry>

The spatial engine supports multiple geometry types in a single table, for example Oracle Spatial, and you wish to limit the geometry

<geometry>
  <polygon/>
</geometry>

You want the user to specify 2 geometries, including 1 polygon and either a point or a line.

<geometry minimum="2" maximum="2">
  <polygon minimum="1" maximum="1"/>
  <linestring/>
  <point/>
</geometry>

You want the user to specify 2 geometries, including 1 polygon and either a point, line or polygon.

<geometry minimum="2" maximum="2">
  <polygon minimum="1"/>
  <linestring/>
  <point/>
</geometry>

You want the user to specify 1 or 2 geometries, including 1 polygon and optionally a point or line.

<geometry maximum="2">
  <polygon minimum="1"/>
  <linestring/>
  <point/>
</geometry>

You want the user to specify between 2 and four points.

<geometry>
  <point minimum="2" maximum="4"/>
</geometry>

As of version 0.38 it's possible to specify that multiple geometry types are supported, but only one should be used at a time. That is if the user creates a polygon then they can only create more polygons, even if the edit supports lines. This is done by setting the value for exclusive to true in the main geometry tag.

Setting the geometry type to 'exclusive'

<geometry maximum="2" exclusive="true">
  <polygon/>
  <linestring/>
  <point/>
</geometry>

If minimum is not specified it defaults to 0.
If maximum is not specified there will be no upper limit.

Restricting edit types

You can selectively disable a users ability to create, update or delete entities by setting create, update or delete to false in the edit config.

Create an edit where users can only create new entities

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:com.cohga.server.config#1.0" xmlns:edit="urn:com.cohga.spatial.edit#1.0">
  <edit:config id="simple.edit">
    <entity>graffiti</entity>
    <label>Graffiti</label>
    <description>Report graffiti for removal</description>
    <update>false</update>
    <delete>false</delete>
  </edit:config>
</config>

Custom attributes

If the default attribute editing setup isn't suitable you can directly specify the attributes that the user can edit and how they appear to the user.

When any parameters are specified they will completely replace any parameters that may have been created by Weave

This is done by adding one or more parameter items to the edit configuration, where each parameter specified one input parameter. The format of the parameter items in an edit config are an extension of those available for search parameters.

Name	Type	Required	Default	Description
id	string	yes		A unique identifier for the parameter
label	string	yes		The prompt text displayed when user input the parameter value
column	string	no		The name of the column within the table that this parameter references
helptext	string	no		Additional text to display for the parameter to explain how to use the parameter
hidden	boolean	no	false	Hides the parameter from the parameter UI
alignment	'left', 'center', 'right', 'auto'	no	'auto'	How the items should appear in the UI
controltype	'listbox', 'checkbox', 'radiobutton', 'textbox' or 'textarea'	no	'textbox'	The suggested type of UI control to use when displaying the parameter
datatype	'any', 'date', 'time', 'datetime', 'integer', 'string'	no	'string'	The data type for the parameter
allownull	boolean	no	false	Whether a null value is allowed for this parameter
allowblank	boolean	no	true	Give the user the choice of an empty value in the listbox (as opposed to a null value)
allownewvalues	boolean	no	false	Allow the user to enter values not in the listbox already
defaultvalue	any	no		The default value of the parameter
dataset	ref urn:com.cohga.server.data.database#1.0:datadefinition	no		Where to get the values for a listbox
labelcolumn	string	no		Column in the datadefinition that supplies the label of the value to show the user
valuecolumn	string	no		Column in the datadefinition that supplies the value of the value to use in the SQL
uppercase	boolean	no	false	Should the value be converted to upper case in the generated SQL
readonly	boolean	no	false	Can the user change the value
readonlyoninsert	boolean	no	false	Can the user change the value when a new entity is being created
readonlyonupdate	boolean	no	false	Can the user change the value when an entity is being edited
updatable	boolean	no	true	Can the underlying value ever be changed once set (implied readonlyonupdate if set to true)
value	any	formula or any		A value to insert into the database, provides a means of creating values beyond what the user enters (implied readonly if set
persisted	boolean	no	false	Should the value the user chooses for the field become the default value for the field?
minvalue	any	no		The minimum value allowed for a field. Available from 2.5.28.
maxvalue	any	no		The maximum value allowed for a field. Available from 2.5.28.
minlength	integer	no		The minimum length allowed for a field. Available from 2.5.28.
maxlength	integer	no		The maximum length allowed for a field. Available from 2.5.28.
increment	integer	no		The increment to use for fields that support it, the units are dependant upon the field type. Available from 2.5.28 and currently only for time fields.

A few things to note about the properties that can be applied to parameters:

column is optional, if not provided then the field will still appear, but an attempt to write the entered value into the underlying spatial table will not be made. The user entered value can still be used by other means that will be covered later.
The controltype now supports 'textarea' which isn't available for search fields, it provides a multi-line text input field.
readonly, readonlyoninsert and readonlyonupdate aren't available for search field either, they're special markers that allow you to alter the ability of the user to change the value in a field. These are client-side flags, and if set alters the display of the field so that the user cannot change the value, the field is still displayed, just not editable.
updatable specifies that one a value is set it can't be changed, this is similar to readonlyonupdate, and in fact readonlyonupdate will be set to true if updatable is set to false, but it also provides additional checks on the server to ensure that the value is not updated.
value can be used to set a value explicitly by directly supplying the value, or there are a number of formulas that are available.
- entity() The name of the entity type being edited.
- userid() The current username.
- ip() The current users IP address.
- datetime() The current date/time.
- operation() The type of operation being performed will be one of the strings 'create', 'update' or 'delete'.
- nextval() The value used for the column will be the previous largest value from the column plus one, the underlying column must be numeric.
- geometry() A WKT (Well Known Text) representation of the geometry if available, otherwise null.
- id() The value for the key field for the spatial table will be used if available, otherwise null.
- auto() The value for the field is auto-generated by the database.
- count() The number of geometry objects.
- area() The area of the geometry.
- length() The length of the geometry.
- guid() Generate a new globally unique id.

When geometry is being written to multiple spatial tables the count(), area() and length() functions will behave differently when used in an edit config item versus an edit audit item.
The value will only contain the count, area and length for the geometries that match the table that the geometry is being written to, not the total, when used in an edit config item. But, when used in audit config item then count, area and length will be the total of all the geometries (if there are more than one).

Custom parameter examples

Auditing changes

To record who created and who modifies an entity use:

Auditing changes example

  <edit:config id="custom.edit">
    <entity>graffiti</entity>
    <label>Grafitti</label>
    <description>Report graffiti for removal</description>
    <geometry>
      <point minimum="1" maximum="1"/>
    </geometry>
    <parameter id="description">
      <label>Description</label>
      <controlType>textarea</controlType>
      <column>DESCRIPTION</column>
    </parameter>
    <!-- Hidden parameters to record audit information -->
    <parameter id="createdby">
      <hidden>true</hidden>
      <column>CREATEDBY</column>
      <value>userid()</value>
      <updatable>false</updatable>
    </parameter>
    <parameter id="createdon">
      <hidden>true</hidden>
      <column>CREATEDON</column>
      <value>datetime()</value>
      <updatable>false</updatable>
    </parameter>
    <parameter id="modifiedby">
      <hidden>true</hidden>
      <column>MODIFIEDBY</column>
      <value>userid()</value>
    </parameter>
    <parameter id="modifiedon">
      <hidden>true</hidden>
      <column>MODIFIEDON</column>
      <value>datetime()</value>
    </parameter>
  </edit:config>

In this example the audit information is stored in the spatial table itself, so the table must already contain the CREATEDBY, CREATEDON, MODIFIEDBY and MODIFIEDON fields and they need to be character fields for the 'by' fields and timestamps for the 'on' fields.
Also, the about configuration assumes that there is an additional column that's used to identify the records, the id column, but that the column is auto-generated by the database and is not user editable.

Setting an id field

Specifying an field as an id field to be created by using the maximum value from the column.

Id column example

  <edit:config id="custom.edit">
    <entity>graffiti</entity>
    <label>Grafitti</label>
    <description>Report graffiti for removal</description>
    <geometry>
      <point minimum="1" maximum="1"/>
    </geometry>
    <parameter id="id">
      <hidden>true</hidden>
      <column>ID</column>
      <value>nextval()</value>
    </parameter>
    <parameter id="description">
      <label>Description</label>
      <controlType>textarea</controlType>
      <column>DESCRIPTION</column>
    </parameter>
  </edit:config>

This example sets an id field that's hidden from the user and it's created from the existing values in the table. This is not an optimal solution to generating new key values, and it would be much better to use the functionality provided by the underlying database (sequences, auto-generate, identity, etc).

Drop down lists

Specifying that the value for a field is chosen from a list. Here we have a static list, status, included directly in the configuration, and a dynamic list populated from a data definition, reporter.

Drop down list example

  <edit:config id="custom.edit">
    <entity>graffiti</entity>
    <label>Grafitti</label>
    <description>Report graffiti for removal</description>
    <geometry>
      <point minimum="1" maximum="1"/>
    </geometry>
    <parameter id="id">
      <hidden>true</hidden>
      <column>ID</column>
      <value>nextval()</value>
    </parameter>
    <parameter id="description">
      <label>Description</label>
      <controlType>textarea</controlType>
      <column>DESCRIPTION</column>
    </parameter>
    <parameter id="status">
      <label>Status</label>
      <controlType>listbox</controlType>
      <column>STATUS</column>
      <defaultValue>N</defaultValue>
      <list value="N" label="New"/>
      <list value="V" label="Verified"/>
      <list value="S" label="Scheduled"/>
      <list value="R" label="Removed"/>
    </parameter>
    <parameter id="reporter">
      <label>Reporter</label>
      <controlType>list-box</controlType>
      <dataSet>staff</dataSet>
      <allowNewValues>true</allowNewValues>
      <column>REPORTEDBY</column>
    </parameter>
  </edit:config>

Check Boxes and Radio Buttons

Check box and radio button example

  <edit:config id="custom.edit">
    <entity>graffiti</entity>
    <label>Grafitti</label>
    <description>Report graffiti for removal</description>
    <geometry>
      <point minimum="1" maximum="1"/>
    </geometry>
    <parameter id="id">
      <hidden>true</hidden>
      <column>ID</column>
      <value>nextval()</value>
    </parameter>
    <parameter id="checkbox">
      <label>Check Box</label>
      <controlType>checkbox</controlType>
      <column>CHECKBOX</column>
      <trueValue>Y</trueValue>
      <falseValue xsi:nil="true"/>
    </parameter>
    <parameter id="radiobutton">
      <label>Radio Button</label>
      <controlType>radiobutton</controlType>
      <column>RADIOBUTTON</column>
      <defaultValue>value2</defaultValue>
      <list>
        <label>Label 1</label>
        <value>value1</value>
      </list>
      <list>
        <label>Label 2</label>
        <value>value2</value>
      </list>
      <list>
        <label>Label 3</label>
        <value>value3</value>
      </list>
    </parameter>
  </edit:config>

Writing to other tables

Currently only writing new records to a separate database table is supported, that is you can not currently update an existing record in an external database table.

So far all attribute values entered by the user have been written directly to the underlying spatial table, but it's also possible to write values, including those entered by the user and those available via value formulas, to another database table. This can be done by creating an audit edit configuration item and attaching it to an existing edit configuration item.

The audit configuration specified a datasource and table to write the values to plus a list of parameters that correspond to the columns in the table.
The columns can derive their values either from the values entered by the user as a parameter in the original edit configuration or as a formula using a value tag or as a hard coded value.

Parameters in edit configurations can be setup with or without a column attribute. If there is a column specified then the value will be written to the corresponding column in the underlying spatial table, if there is no column specified then no value will be written during this phase. However, the value the user enters for the parameter, in both cases, is available to be written as part of an audit configuration.

Writing audit information to a separate table

  <edit:config id="custom.edit">
    <entity>graffiti</entity>
    <label>Grafitti</label>
    <description>Report graffiti for removal</description>
    <geometry>
      <point minimum="1" maximum="1"/>
    </geometry>
    <parameter id="id" hidden="true" label="Id" column="ID" value="auto()"/>
    <parameter id="description" label="Description" controlType="textarea"/>
  </edit:config>

  <edit:audit id="custom.audit">
    <mode>create,update,delete</mode> <!-- specify when audit records are written. create,update,delete is the default so this isn't really needed here -->
    <edit>custom.edit</edit>
    <datasource>datasource.main</datasource>
    <table>EDIT_AUDIT</table>
    <parameter column="ID" value="id()"/>
    <parameter column="DESC" parameter="description"/>
    <parameter column="GEOM" value="geometry()"/> <!-- at the moment this is text, not actual Geometry, in WKT format -->
    <parameter column="USER" value="userid()"/>
    <parameter column="MODIFIED" value="datetime()"/>
  </edit:audit>

Starting from a URL

The edit process can be started by including either a 'create' or an 'edit' parameter as part of the url when starting the client

http://localhost:8080/weave/edit.html?create=custom.edit

create will initiate the creation of a new entity, using the configuration specified by the value of the create parameter.

http://localhost:8080/weave/edit.html?edit=custom.edit&id=1234

edit will initiate the editing of an existing entity, using the configuration specified by the value of the edit parameter and using the entity identified by the id parameter. Also, the client will zoom to the extent of the selected entity.

Both of these URL's also allow you to specify values to be used for the parameter in the edit.

http://localhost:8080/weave/edit.html?create=custom.edit&description=Type%20your%20description%20here

Localisation

It's possible to localise the text used in the edit panels so they're displayed in the local language of the user, this localisation is performed using the standard localisation mechanism outlined at Internationalisation and Localisation.

The edit panel provides a set of resource id's that it understands and if they're set for the users locale they will be used instead of the defaults values.

id	default
edit.create.text	Create
edit.create.tooltip	Create a new entity
edit.create.notify	Entity successfully created
edit.update.text	Update
edit.delete.tooltip	Edit the selected entity
edit.delete.notify	Entity successfully edited
edit.delete.text	Delete
edit.delete.tooltip	Delete the selected entity
edit.delete.notify	Entity successfully deleted
edit.submit.text	Submit
edit.submit.tooltip	Submit changes
edit.cancel.text	Cancel
edit.cancel.tooltip	Cancel changes
edit.polygon.text	Polygon
edit.polygon.tooltip	Add a polygon
edit.line.text	Line
edit.line.tooltip	Add a line
edit.point.text	Point
edit.point.tooltip	Add a point
edit.modify.text	Modify
edit.modify.tooltip	Click on an item to modify it
edit.remove.text	Remove
edit.remove.tooltip	Remove the currently selected item
edit.reset.text	Reset
edit.reset.tooltip	Reset the form fields
edit.import.text	Import
edit.import.tooltip	Import geometry from another entity
edit.import.error.tooManyGeometries	There are too many geometries in the source
edit.import.error.tooManyPoints	There are too many points in the source
edit.import.error.tooManyLinestrings	There are too many lines in the source
edit.import.error.tooManyPolygons	There are too many polygons in the source

The following resources item can be used to replace the text for all of the items

<client:resources>
	<edit>
		<create>
			<text>Create</text>
			<tooltip>Create a new entity</tooltip>
			<notify>Entity successfully created</notify>
		</create>
		<update>
			<text>Update</text>
			<tooltip>Edit the selected entity</tooltip>
			<notify>Entity successfully edited</notify>
		</update>
		<delete>
			<text>Delete</text>
			<tooltip>Delete the selected entity</tooltip>
			<notify>Entity successfully deleted</notify>
		</delete>
		<submit>
			<text>Submit</text>
			<tooltip>Submit changes</tooltip>
		</submit>
		<cancel>
			<text>Cancel</text>
			<tooltip>Cancel changes</tooltip>
		</cancel>
		<polygon>
			<text>Polygon</text>
			<tooltip>Add a polygon</tooltip>
		</polygon>
		<line>
			<text>Line</text>
			<tooltip>Add a line</tooltip>
		</line>
		<point>
			<text>Point</text>
			<tooltip>Add a point</tooltip>
		</point>
		<modify>
			<text>Modify</text>
			<tooltip>Click on an item to modify it</tooltip>
		</modify>
		<remove>
			<text>Remove</text>
			<tooltip>Remove the currently selected item</tooltip>
		</remove>
		<reset>
			<text>Reset</text>
			<tooltip>Reset the form fields</tooltip>
		</reset>
		<import>
			<text>Import</text>
			<tooltip>Import geometry from another entity</tooltip>
			<error>
				<tooManyGeometries>There are too many geometries in the source</tooManyGeometries>
				<tooManyPoints>There are too many points in the source</tooManyPoints>
				<tooManyLinestrings>There are too many lines in the source</tooManyLinestrings>
				<tooManyPolygons>There are too many polygons in the source</tooManyPolygons>
			</error>
		</import>
	</edit>
</client:resources>

It's possible, as of version 0.38 of the edit bundle to specify when, on create, update and/or delete, the audit record is written by specifying a 'mode' value in the audit config as a comma separated list of those three values. e.g <mode>create</mode> would just write an audit record when an new entity is created.

The default, if not specified, is <mode>create,update,delete</mode>.

Create New Button

As of release 2.5.21 there is an additional button that can be added to a tool bar or status bar to immediately initiate the creation of a new object.

There's not much to it, it's just a button that can be added to a toolbar and when click immediately starts the creation of a new spatial object of a specific type, and is configured with the type of object to create so you don't have to switch the active entity.

It either takes and entity, in which case the default edit for the entity is used,

<item action="weave.edit.createNew" entity="grafitti"/>

or it takes an entity and a specific edit, in which can that edit will be used,

<item action="weave.edit.createNew" entity="graffiti" edit="grafitti.edit"/>

Overriding Edited Table

It's possible to override the table that Weave will update when the user submits an edit, rather than just using the table associated with the entity in the spatial mapper. This helps when working with views that can't be updated but the table that underlies the view can be.

To tell Weave to update a different table than the one specified in the spatial mapper you need to set a spatialEngine, table and key in the edit config.

 <edit:config id="edit.view">
    <entity>graffiti</entity> <!-- this entity is backed by a DB view that can't be edited directly -->
    <spatialEngine>oracle</spatialEngine> <!-- set the spatial engine that contains the table that should be edited instead, could be the same as the spatial mapper, but might not be -->
    <table>GRAFITTI</table> <!-- set the name of the table in the spatial engine that should be edited instead, this should be different than the spatial mapper, since that's the whole point of this -->
    <key>OID</key> <!-- set the column that uniquely identifies the rows in the table that should be used instead, generally this would be the same as the spatial mapper -->
    <label>Grafitti</label>
    <description>Report graffiti for removal</description>
    <geometry>
      <point minimum="1" maximum="1"/>
    </geometry>
    <parameter id="id" hidden="true" label="Id" column="ID" value="auto()"/>
    <parameter id="description" label="Description" controlType="textarea"/>
  </edit:config>

Browser not supported