Creating plug-ins for SobekCM

 

Information on how to create plug-ins. Much of this is just quick notes for now, but this page (and subpages) will be developed here over time.

In addition, examples will full source code can be found from the Plugins & Commonly Used Tools page.

General process for creating all plug-ins

Below are some notes on how to develop those custom plug-ins easily, and then how to make them stand-alone DLLs.

1. Generally, I create the code within the main SobekCM code until it works in test
2. Create a new Visual Studio solution/project with Class Library selected
3. Create a DLLs folder and copy over the Core, Engine_Library, Tools, and Resource_Object.  If you are adding features for the web, you will likely need to add the Library as well.  Copy these from the latest version you are running in production.
4. Reference those DLLs in your solution
5. Review the solution/project properties, in particular the .NET version
6. Copy the files you wrote for the plugin from the main code
7. Compile to DLL
8. Create the configuration file, and include your namespace in the referenced class names
9. Drop into your plug-ins foler
10. Enable and test.

If it is not loading correctly, debug the ProcessRequest method in the Engine_Library/MicroservicesHandler.

 

Requirements for new Engine API endpoint plug-ins

Adding a new engine API endpoint to expose data, or change the way an existing endpoint works, is one of the easiest plug-ins to create. To create a plug-in like you must:

• Create a class that includes a method with the same signature as the other endpoints. You don't necessarily need to extend or implement any existing classes or interfaces.
• Add a reference to your component, class, and method name in your plug-in configuration.

 

Requirements for Item Viewer plug-ins

To create a custom item viewer, there are three main portions that must be covered:

• The new item viewer must be added into the SobekCM_Item_Viewer_Types table, which is how items will be linked to the item viewers. We may eventually make this be automatic if a new item viewer is saved from the database. This is generally done with an installation SQL script.
• The item viewer and item viewer prototyper classes must be created, which are the C# classes that actually render the views and tell when the viewer should manifest itself
• The link between the viewer code (from the database) and the custom classes is in the viewer configuration file. This links the viewer code ( like 'RTI' for example) with the item viewer prototype class ( like RTI_ItemViewer_Prototyper for example ). Then, the prototyper clss is what generates the actual item viewer class when the user requests that view.

NOTE: For item view plug-ins, if using a javascript based viewer inside SobekCM that is not working try this.  if the whole web page is posting back, you may need to disable onsubmit on the form.  This was done in the RTI viewer, using the following:

 

Requirements for adding new custom metadata via a plug-in

This process actually takes quite a bit of work, since all metadata is saved in the standard METS/MODS metadata files in the digital resource folders. We will be working on a tool to perform as much of this as possible for developers implementing custom metadata modules.

The current components that must be completed for this are:

1. The metadata must be saved to the METS, so a METS Section Reader/Writer class must be created for this purpose
2. A metadata module class must be created which stores the metadata in memory. This class will be instantiated by the METS section reader class. The metadata module class also handles how the metadata is saved to the database for searching and other purposes.
3. A brief item mapper class must be created which maps between the metadata module class and the BriefItem object, which is created in the engine from the full SobekCM_Item object and is passed via the rest API to the web application for display. Generally, the brief item viewer is much less comprehensive and the data is displayed in a flattened structure.
4. Metadata template elements must be created to display and allow editing of the fields via the online templates.
5. The plug-in configuration file must be created and should include:
   • A reference to the reader/writer class (#1 above) must be added to the metadata config section
   • A reference to the brief item mapper class (#3 above) must be added to the brief item mapper section

While much of the elements necessary above can be highly customized, it is also true that most metadata added will be simpler in nature and a tool could easily generate much of this code and configuration for you.  We expect to have the tool ready by late April 2017.