Jump to content
Wiki Home
EPrints Home
Bazaar
Files
Main menu
Main menu
move to sidebar
hide
Navigation
Front Page
EPrints 3 Manual
EPrints Training Course
EPrints Glossary
Installing EPrints
How-to Configure EPrints
EPrints 3.2+ API
EPrints 3 Reference
EPrints Plugins
Wiki
All categories
Recent changes
Main Page
Help
EPrints Documentation
Search
Search
Appearance
Log in
Request account
Personal tools
Log in
Request account
Pages for logged out editors
learn more
Contributions
Talk
Editing
EPrints3 Roadmap
(section)
Page
Discussion
British English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==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 ==== <source lang="perl"> $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; </source> extended to: ==== list ==== <source lang="perl"> $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... </source> ==== XHTML ==== If rendering the description of list is important XHTML would gain <source lang="perl"> $xhtml->list($list) </source>
Summary:
Please note that all contributions to EPrints Documentation may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
EPrints Documentation:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)