Geodatabase Add-ins

Idea created by kirkktx on Mar 11, 2011
    • mtodd22895
    • kirkktx
    • 1_MarcBate
    • bruenis
    • bjclose
    • varunscool
    • mping
    • dknudsen
    Esri needs to provide an Add-in extensibility for the geodatabase.  The following describes use cases involving 4 actors: a geodb admin, an arcmap editor, a web editor, and an add-in developer.

    A developer downloads a geodatabase add-in SDK from Esri.  The SDK provides visual studio tools to create add-ins.  Add-ins are classes that respond to events similar to those in IEditEventsXXX.  It is where business logic is enforced.  Geodatabase Add-ins have no dependencies on the IEditor.  The add-in provides a way to abort an edit operation, and provide a verbose description for the user to see.

    The developer designs a abstact UI definition that can appear (similar to that of a Gp Tool) in either a web or desktop environment.

    The developer uses documentation that guides him though how to migrate ClassExtensions and Editor Extensions into geodatabase extensions.

    Alternatively, the developer provides a dll that can be consumed by a Silverlight Viewer Extension, thus providing client side validation.  The SL viewer extension makes a call to an SOE to retrieve a serialized assembly when editing begins.

    The developer sends a dll and a config xml file to the Geodb administrator.

    The geodb administrator saves the file to a temp folder.

    Using arccatalog, the geodb administrator opens a dialog and selects a geodatabase add-in.

    The add-in presents a UI for the administrator to configures it, for example by choosing a featureclass, and a date field. 

    The geodb admin closes the dialog.

    The add-in is added to the geodatabase - not the file system.  That way it travels with the geodatabase.

    The geodb then right clicks on a featureclass and chooses "triggers".  Arccatalog presents a dialog listing all the add-in triggers that have been configured.  The geodb admin moves triggers up/down to control the order in which they will get fired.

    Desktop Editing
    An arcmap user starts editing a featureclass.  When features are added to the featureclass both triggers are fired in the order configured by the geodb administrator.  Commands are added to the UI when the user starts to edit a geodatabase.

    Web Editing
    A web editor uses a featureservice (via REST) to edit a featureclass.  When features are added to the featureclass, both triggers are fired.  When business logic is violated (and the add-in aborts the edit operation) the user is presented with a descriptive message that originated from the add-in.

    When the user starts editing a mapservice, a UI for featureservices being edited is presented.

    There have been numerous requests to support Timestamper as a field type this could be done with an add-in. 

    It is best practice to use unique IDs as primary keys (not ObjectIDs), yet this requires custom coding or tricky SQL.  Primary keys could be populated by an add-in.

    Business logic needs to travel with the geodatabase and be triggered on the server to support web editing.  No COM registration should be needed.

    Class extensions are too restrictive - there can be only one of them.  A featureclass can have multiple triggers (special type of add-in), and the geodb admin can configure the order that those triggers fire. 

    Losing an IWorkspaceExtension dll prevents the workspace from being opened.  By storing the add-ins within the workspace, this would become a non-issue.