EPrints Technical Mailing List Archive

Message: #05320

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: Suggested changes to EPrints 3 in 2016

Hello Patrick et al,


Thank you for creating the Roadmap page on the wiki (https://wiki.eprints.org/w/index.php/EPrints3_Roadmap)

I personally think we could benefit from a roadmap/future directions for EPrints wiki page for 2016 and beyond. 

Unless this is already maintained elsewhere that I am not aware of (is it?) I suggest we open this Roadmap on the wiki to include a list of desired features/functionality for EPrints.


A couple of quick comments about your suggested goal of removing render functions:


1)       I added the source code tags to the code you added on that page on the Wiki <source lang="perl"> … </source>

I find that the benefit in readability (syntax highlighting) is great, so I vote that we agree to try to do this as a best practice.


2)      The benefit of removing the render functions as described would be impossible to understand by someone who doesn’t have a very high level of programming expertise.  It is good to include this, but it would be great if we could also try to include (and group) the more broadly understood rationale for the change on the Wiki page as well, which you describe in your email in this case as “Try and simplify EPrints to make future development and support more straight forward”.



Best wishes,






From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Patrick McSweeney
Sent: January-09-16 9:19 AM
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: Suggested changes to EPrints 3 in 2016


Yes your understanding is correct although the function in $xhtml  would not be prefixed with render_ because everything in that class has an implied render_ . Deprecating all the existing render functions will take years because its quite a large change but I think its a good idea to move in that direction.

How this fits in with EPrints 3.3 and 4 I have no idea. Every time i look at the git branch for EPrints 4 I do so with trepidation. It is a big fundamental change to EPrints which i dont feel time rich enough to start understanding. I had a demo of the code in action from Seb Francios a year (or maybe two) ago but it has no user interface so their is still a lot of work to be done there.

Hopefully Jiadi will be able to comment on this when he returns from his holidays. I think that his plans should be the bulk of what is on that roadmap page so we can all see what is coming up. My understanding from talking to Justin is that he has plans for EPrints 3.3 but I have no idea what the position on EPrints 4 is.

For the time being I will carry on quietly committing tests and wait to see how this unfolds.





On Thu, Jan 7, 2016 at 10:40 AM, Alan.Stiles <alan.stiles@open.ac.uk> wrote:

Hi Patrick,

Don’t want you to think we’re ignoring you!  Anything to simplify the structure of core EPrints seems like a step in the right direction.

if I understand your render_description example you’re suggesting that instead of calling $object->render_description(), we would call something like $XHTMLobj->render_obj_description($object)  and the XHTMLobj would get the description as a string from $object and then apply the necessary DOM structure to it?


One question about the roadmap is how does it fit with the EPrints 3.4 and Eprints 4.0 plans?


Hopefully I’m not alone in saying that it’s nice to see you more visibly involved in eprints ‘stuff’ again, and also that your Roadmap is probably looking at a much lower level of EPrints core than most of us community developers tend to get involved, up to now, but hopefully it can help with our understanding of how it all hangs together.






From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Patrick McSweeney
Sent: 05 January 2016 18:03
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Suggested changes to EPrints 3 in 2016


Hi ep-tech,

Sorry for the long silence. Since the community contributions day in December I have been playing more with EPrints. I was hoping to find a roadmap for EPrints 3 development but couldn't so I am proposing one. My aims are largely to try and simplify EPrints to make future development and support more straight forward. I would like participants of the list to take a look at the plan reply with

* Comments or questions about the plan

* Proposed changes or extensions to the plan

* Things I have not thought of

You can see the roadmap here https://wiki.eprints.org/w/index.php/EPrints3_Roadmap

So far I have started by implementing new unit tests for list and XHTML. This seems like a non-contentious part of the plan to start with. No one every complains about more tests.


Please let me know what you all think




'But your intentions are beside the point, It's the outcome of your actions that count...'

-- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302). The Open University is authorised and regulated by the Financial Conduct Authority.

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/


'But your intentions are beside the point, It's the outcome of your actions that count...'