EPrints Technical Mailing List Archive

Message: #05415

< 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

Hi Patrick and Jiadi,

                                                                                                                      

Thanks for starting the discussion on this important topic.  It looks to me like there are actually lot of different but related strategies in “rationalising” the configuration files.

I think I understand the concept, these strategies were mentioned:

 

·         Creating a rendering class like $xhtml

·         Moving all of the rendering settings/configurations into a central location

·         Retiring/converting EPC configuration settings to XSLT format

·         Moving repository type related code out of the core and into “flavour” packages

 

Patrick, what is the argument for leaving the rendering where it is?  The benefit to knowing the risks is that we can try to mitigate.

 

I understand the benefits of increased modularity; the maintainability and sustainability of the software development should benefit from that. 

We should consider the degree of difficulty for future upgrades of EPrints installs and ideally work towards changes that will result in  a long-term improvement in that respect.

In general, I think that an important consideration is the current install-scape for EPrints.

I suppose it would be ideal if the changes to configuration settings are done in a way that would be backwards compatible or more realistically, convertible. 

 

Best wishes,

 

Tomasz

 

 

 

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Patrick McSweeney
Sent: February-04-16 2:14 PM
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: Suggested changes to EPrints 3 in 2016

 

Hi Tomasz,

Yes sorry about the code formatting on the wiki, using <pre> tag is a bad a bad habbit i should get out of. In future I will endeavour to use syntax highlighting.

Broadly the intention of the change would be to try and simplify the objects in eprints and also start us on the road to rationalising the XML configuration files.

Currently phrase templates and citations are all subtly different implementations of templating in EPrints. That said we could rationalise the templating without moving the rendering into a central location. It has been suggested on github has been that maybe we should start thinking about how to start retiring the various EPC configuration in favour of XSLT which is less bespoke to eprints and would probably perform better. I guess i felt this was a big problem to tackle and maybe rationalising rendering might help make it less intimidating.

There is definitely an argument for leaving rendering where it is which i was hoping might get discussed on this thread.  Moving something as fundamental as rendering is a strategic change which I dont want to make without knowing some people support it. I have asked Jiadi to comment on this in his capacity as lead developer and he has said he will once he has had time to consider the implications.

Ultimately having a roadmap seems to be a popular idea so I am glad that is in the open. If I only have one good EPrints related idea this year than I'm happy for it to be that. So far no one has complained about me adding unit tests to things either :-)

Kind regards

Patrick

 

====

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Jiadi Yao
Sent: February-12-16 12:19 PM
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: Suggested changes to EPrints 3 in 2016

 

 

 

Hi Patrick,

More test scripts are always welcome. Thanks for taking this up. What kind of tests are you considering to cover?

Creating a rendering class like $xhtml is a good suggestion, and we can also think about all other classes that current have rendering function that generates xhtml from the core, for example,

*search result page and search form
*Input components, e.g. Plugin/InputForm/Component/Field/Multi.pm
*how would the screen plugins work?
*Metafields, e.g. Metafield/Compound.pm etc
*How does this affect multi language renderings, e.g. Language.pm
 
It would be ideal if we can render everything using this rendering class.

The primary focus of the next version of eprints (3.4) is to move repository type related code out of the core, so that the core is smaller, and the code that is only related to a publication repository stays in a package (we may call it flavour). This way, we can build other types(flavours) of repositories, e.g. data-repository, education resource repository(edshare) and micro-repositories more cleanly and easier to manage. This is also a step towards a generic core that is not based on publication.

Best
Jiadi

====

 

On Wed, Jan 13, 2016 at 5:06 PM, Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca> wrote:

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,

 

Tomasz

 

 

 

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.

Best

Patrick

 

 

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.

 

Cheers,

Alan

 

 

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

Regards

Patrick


--


'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...'


*** 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...'