Plugin Interface to add Custom Data Types to Configurable Submission Forms
--------------------------------------------------------------------------

                 Key: DS-350
                 URL: http://jira.dspace.org/jira/browse/DS-350
             Project: DSpace 1.x
          Issue Type: Improvement
          Components: DSpace API, JSPUI, XMLUI
    Affects Versions: 1.6.0
         Environment: all
            Reporter: Larry Stone
            Assignee: Larry Stone
            Priority: Minor
         Attachments: ds-350-intfc.txt

The configurable submission forms still have a fixed set of data types, such as 
"name", "date", "onebox", "twobox", etc.  If very many other sites have also 
found it necessary to add custom data types, it would be handy to have a 
mechanism to add these cleanly in a separate customization layer, especially 
since it is very messy to do this by modifying the DSpace code (both the 
"reader" in dspace-api and the rendering class in the UI must be modified).  

Here is an example: Suppose your site administrator decrees the dc.date.issued 
field must only accept a 4-digit year, and furthermore that year is constrained 
to a range from 1700 to 2 years into the future.  You can borrow the rendering 
from the simple text box, but the reader must apply those constraints and 
normalize the value it stores in the Item's metadata.  Typical uses for custom 
fields:
- applying custom constraints to input values
- rendering inputs in the HTML form as a group of fields joined in the reader 
to create the value
- normalizing input values before storage

The interface to processing each data type is already modular and it is 
straightforward to factor it out to a plugin interface.  Three interfaces are 
actually required: First, a common "reader" to be called by 
org.dspace.submit.step.DescribeStep.  Second, when implemented for the XMLUI, a 
rendering interface that adds fields to the DRI model.  Third, peculiar to the 
JSPUI, a rendering interface that adds HTML to the JSP.  Of course, each site 
only has to implement the UI they are actually using.

Each plugin may also be written to "defer" to one of  the built-in types, so 
e.g. when the reader is custom but the rendering can borrow from the existing 
"text box", you can use deferment to save writing the renderer.  

The attachment has pseudocode for the sample interfaces.    If you are 
interested in using a customization mechanism like this, please vote for this 
issue (click on the "Vote" link under the Operations tab to the left).   Add a 
comment if there is anything you want to see changed. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to