[
https://jira.duraspace.org/browse/DS-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26894#comment-26894
]
Pascal-Nicolas Becker commented on DS-1390:
-------------------------------------------
It is not a real solution but I think nevertheless helpful would be to seperate
the JSPUI-specific properties and the the XMLUI-specific properties even more.
There are a lot of properties that affect only the JSPUI while the same things
in XMLUI get managed by the theme. If you start with DSpace and decide for one
of the UIs it is still hard to recognize which property is important and which
one you can ignore if you deactivate either JSPUI or XMLUI. It does not solve
the problem you target with this ticket, but its a quick step in the same
direction which can be done while the other things you propose gets implemented.
> DSpace has too many configurations
> ----------------------------------
>
> Key: DS-1390
> URL: https://jira.duraspace.org/browse/DS-1390
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Reporter: Mark H. Wood
> Fix For: 4.0
>
>
> DSpace has two separate places to go for configuration: ConfigurationManager
> and ConfigurationService. While very similar, they do work differently, and
> they generate extra work to keep them similar. I recently wanted to answer a
> question on dspace-tech concerning configuration of uninstalled webapp.s run
> from the IDE during development, and realized that *the situation was too
> complex to describe*. I'd like to simplify things quite a bit.
> I suggest several phases:
> 1. ConfigurationManager contains a number of methods that have nothing to do
> with simple configuration properties, but rather deal with license texts and
> news items and the like. These should be moved to classes directly concerned
> with representing them. In particular, XMLUI has its own way of handling
> news, so JSPUI should house the one currently in dspace-api, which is only
> used by JSPUI.
> Removing methods not dealing with serialized Properties will align the
> signatures of ConfigurationManager and ConfigurationService much more closely.
> 2. Review the overall design of access to configuration data. Each
> configuration source has grown a number of handy features over the years, but
> I think it's time to do another design pass over the whole issue of how we
> find bits of DSpace that the JVM doesn't inherently know about, and then
> implement a single model which well serves both development and production.
> 3. Gut ConfigurationManager, replacing the existing code with wrappers for
> the most closely corresponding ConfigurationService methods. Deprecate all
> ConfigurationManager methods.
> 4. See whether there are useful things only in ConfigurationManager which
> should be ported to ConfigurationService.
> 5. As time permits, replace ConfigurationManager uses.
> I recall that there are proposals to change the way that configuration data
> are stored and manipulated. I think that this simplification and refactoring
> should at the very least not impede such efforts, and may complement them
> nicely. The current (near) duplication of function OTOH does somewhat impede
> those efforts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
