If you identify any potential areas where the DSpace code/architecture could do with some cleaning up, please add them here.
Stuff that definitely needs doing
wrapper scripts for all command-line tools
Remove calls to
from any method that isn't
- Remove commented-out code, especially when there's no explanation as to why it's been commented out
Eliminate business logic from
(and any other offending JSPs)
- Ensure all classes and methods have Javadoc comments
- Abstract out SRB support to be a plug-in rather than intertwined with file system storage code
- Oracle support: Make a build switch as opposed to having to copy over files. Also documentation cleanup.
- Cleanup Messsages.properties
- It now has nearly 1400 lines with many redundancies.
- More use of general tags for things like edit, remove, delete, cancel, id, action group, user and so on.
- Ensure consistent and appropriate logging throughout. Possible need to define a vocabulary of possible log statements for statistics/analysis etc.
- Abstract out the use of Handle System into a persistent identifier plugin
- Pay attention to redirects. For example, the following sequence is a little disorienting: Item page -> edit -> cancel -> Edit Items admin page.
Stuff that we should consider doing now we require JDK 1.5
Using enums instead of
- Make all Collections (Lists etc) use generics (where appropriate)
Stuff that might be pointless given the imminent incorporation of Manakin
- Fix use of CSS
- Fix formatting of JSPs
Stuff that is debatable
- Remove itemsByXXX tables - bad normalization. They can be replaced by a couple of small mods to Metadatum and Item.
(Best check first – I think some processing may be done on the contents of those. You might not simply be able to normalise them. E.g. 'The Book of Silly Things' may appear in itemsByTitle as 'Book of Silly Things, The' for sorting/ordering purposes.)
, but is directly used by JSPs. This isn't following the usual DSpace servlet/JSP idiom; in general, all database access activity should be complete before control of a request passes to a JSP, so that an error is unlikely to occur halfway through rendering a page.
Creative commons licenses go in the
bundle, but a deposit license (the license that a depositor grants the host institution to redistribute/migrate an item) goes in the
bundle. Why not just
(Wouldn't it be better to be as granular as possible - can always go from granular to general easily but the inverse not true. If we are able to distinguish between different license bundle types institutions can treat CC and site license differently if they want, and others can generalise if they wish. If you generalise all license types up front you can't go the other way without looking at filenames and content --SY)
why do the stylesheet include
? If we need, we can insert
s in the message. If it wouldn't be nowrapping style (along with some other styles) there could be many
tags eliminated from the Messages file. If some styles must be kept nowrapping, then
tags must be allowed in the message keys: it's much better to have a message
" than having 2 separate messages that by accident would be traslated independently each other.
Should be easier to specify an alternative location for DSpace than
. Perhaps other
properties should be permitted to be relative to
? Or somehow refer to it? (e.g.
. Then you could just change
to move the whole install. Done
- Clear up handling of dates in Dublin Core, and corresponding display code. Dates can only be parsed by DSpace if they're in IS08601, UTC/GMT timezone. Harvested dates might be different.
LDAP authentication: Should have been implemented as a separate implementation of
rather than added to
. Needs to be cleaned up as part of moving to StackableAuthenticationMethods