Difference between revisions of "EPrints3 Roadmap"
m (Change category Developer to Contribute) |
|||
(24 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | + | [[Category:Eprints3.3]] | |
+ | [[Category:Contribute]] | ||
= 2016 Community Roadmap = | = 2016 Community Roadmap = | ||
+ | ==Goals== | ||
* Create a more comprehensive set of Unit tests for EPrints so community contributions can be accepted more easily | * 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) | * 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) | ||
Line 7: | Line 9: | ||
* Start moving render functions for objects into the XHTML class in order to get all the rendering in one place (see section below) | * 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. | * Start removing references to repository from objects where they should not occur. | ||
+ | * Create and maintain a comprehensive list of desired features/functionality for EPrints | ||
+ | |||
+ | ==EPrints API implementation== | ||
===Removing render functions=== | ===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 currently | + | 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 | + | 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 === | + | ==== list ==== |
+ | <source lang="perl"> | ||
$n = $list->count; | $n = $list->count; | ||
$list->map( sub { | $list->map( sub { | ||
Line 24: | Line 32: | ||
@dataobjs = $list->slice( $offset, $length ); | @dataobjs = $list->slice( $offset, $length ); | ||
\@ids = $list->ids; | \@ids = $list->ids; | ||
− | + | </source> | |
extended to: | extended to: | ||
− | === list === | + | ==== list ==== |
+ | <source lang="perl"> | ||
$n = $list->count; | $n = $list->count; | ||
$list->map( sub { | $list->map( sub { | ||
Line 40: | Line 49: | ||
$list->export($plugin) # rather than plugin id | $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... | $list->description # string description of the list. This might not get added because im not actually convinced it is used... | ||
+ | </source> | ||
+ | |||
+ | ==== XHTML ==== | ||
+ | If rendering the description of list is important XHTML would gain | ||
+ | <source lang="perl"> | ||
+ | $xhtml->list($list) | ||
+ | </source> | ||
+ | |||
+ | ==Open Repositories Conference 2016 UG Notes== | ||
+ | |||
+ | ===Source code management=== | ||
+ | * Bazaar contributors also deposit the plugin source code to GitHub | ||
+ | |||
+ | ===Development strategies & technology=== | ||
+ | * Integration of jQuery and Bootstrap (already listed on the Roadmap on the Wiki) | ||
+ | * Support full responsive design | ||
+ | |||
+ | ===Features to add to the core (or 3.4 ‘zero’?)=== | ||
+ | * review use of MySQL utf8 (probably should be using utf8mb4) | ||
+ | * ORCID | ||
+ | |||
+ | ===Other developments=== | ||
+ | * UKETD_DC export update (e.g. mapping ORCIDs) | ||
+ | * OAI-PMH access logger (to check you’re getting harvested) | ||
+ | * highlight snippets of text from each search result , for example: https://www.elastic.co/guide/en/elasticsearch/guide/current/highlighting-intro.html | ||
+ | |||
+ | ===Strategies for EPrints community=== | ||
+ | * Creation of "Best Practices" section in the Wiki (e.g.: recommended format of documentation in the EPrints source code, variable naming conventions, recommended classes/methods, deprecated or unsupported classes/methods, using session or repository?) | ||
+ | * Development of funding to allow for the creation of a community manager role | ||
+ | * Development of user interface in EPrints documentation and special interest events. |
Latest revision as of 23:54, 11 September 2018
Contents
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 for EPrints
EPrints API implementation
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)
Open Repositories Conference 2016 UG Notes
Source code management
- Bazaar contributors also deposit the plugin source code to GitHub
Development strategies & technology
- Integration of jQuery and Bootstrap (already listed on the Roadmap on the Wiki)
- Support full responsive design
Features to add to the core (or 3.4 ‘zero’?)
- review use of MySQL utf8 (probably should be using utf8mb4)
- ORCID
Other developments
- UKETD_DC export update (e.g. mapping ORCIDs)
- OAI-PMH access logger (to check you’re getting harvested)
- highlight snippets of text from each search result , for example: https://www.elastic.co/guide/en/elasticsearch/guide/current/highlighting-intro.html
Strategies for EPrints community
- Creation of "Best Practices" section in the Wiki (e.g.: recommended format of documentation in the EPrints source code, variable naming conventions, recommended classes/methods, deprecated or unsupported classes/methods, using session or repository?)
- Development of funding to allow for the creation of a community manager role
- Development of user interface in EPrints documentation and special interest events.