EPrints3 Roadmap

2016 Community Roadmap

Goals

• Create a more comprehensive set of Unit tests for EPrints so community contributions can be accepted more easily
• Deprecate old subs from repository into BackCompatibility with a warning saying what version they will abort and what function should be used as an alternative (make_element, make_text, render_data_element, etc,etc)
• Remove references to these deprecated subs within the core code
• Start moving render functions for objects into the XHTML class in order to get all the rendering in one place (see section below)
• Start removing references to repository from objects where they should not occur.
• Create and maintain a comprehensive list of desired features/functionality in EPrints

Removing render functions

Many objects in eprints have render functions. For example $list->render_description and $dataset->render_description. This breaks the single responsibility principle for these objects. For example $list has to know about how to cache and retrieve lists of dataobjs and union and intersect with other lists but also has to know about how it is expected to appear in and XHTML page. This responsibility for $xhtml. Example $xhtml->list($list). These kind of changes would mean that many objects would no longer need a reference to $repository. List is currently instantiated with a reference to $repository. It uses this reference to get access to $database (which it actually needs), get access to $xhtml functions so it can render its description (should not be its responsibility) and $plugin_factory to instantiate a plugin from a string for export (probably the plugin should be passed in rather than the plugin_id).

Following this change to its logical conclusion means no objects in the EPrints core will have render methods. Once all XHTML is generated in one class it will become easier to make changes to aspects of rendering such as amalgamating citations, phrases and templates into one coherent language.

The proposed changes to list would allow us to remove its internal reference to repository but still expand the $list section of the core api from:

list

 $n = $list->count;
 $list->map( sub {
     my ( $repository, $dataset, $dataobj, $ctx ) = @_;
     # do something to the dataobj here
 }, $ctx );
 $dataobj = $list->item( $offset );
 @all_dataobjs = $list->slice 
 @dataobjs = $list->slice( $offset, $length ); 
 \@ids = $list->ids;

extended to:

list

 $n = $list->count;
 $list->map( sub {
     my ( $repository, $dataset, $dataobj, $ctx ) = @_;
     # do something to the dataobj here
 }, $ctx );
 $dataobj = $list->item( $offset );
 @all_dataobjs = $list->slice 
 @dataobjs = $list->slice( $offset, $length ); 
 \@ids = $list->ids;
 $list->export($plugin) # rather than plugin id 
 $list->description # string description of the list. This might not get added because im not actually convinced it is used...

XHTML

If rendering the description of list is important XHTML would gain

 $xhtml->list($list)