Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

CleanupTasks

Created by Unknown User (wiki_transfer), last modified by Tim Donohue on Apr 15, 2010

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

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

Add
```
/dspace/bin
```
wrapper scripts for all command-line tools
Remove calls to
```
System.exit
```
from any method that isn't
```
public void main(String[""])
```
Remove commented-out code, especially when there's no explanation as to why it's been commented out
Eliminate business logic from
```
jsp/edit-metadata.jsp
```
(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
```
public static final int
```
s etc
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 DCValue 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.)

```
Collection.countItems()
```
throws an
```
SQLException
```
, 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
```
CC_LICENSE
```
bundle, but a deposit license (the license that a depositor grants the host institution to redistribute/migrate an item) goes in the
```
LICENSE
```
bundle. Why not just
```
LICENSE
```
for both??
(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
```
nowrap
```
directive for
```
navigationBarItem
```
? If we need, we can insert
```
&nbsp;
```
s in the message. If it wouldn't be nowrapping style (along with some other styles) there could be many
```
&lt;br/&gt;
```
tags eliminated from the Messages file. If some styles must be kept nowrapping, then
```
&lt;br/&gt;
```
tags must be allowed in the message keys: it's much better to have a message
```
"Primary&lt;br/&gt;Bitstream
```
" 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
```
/dspace
```
in
```
dspace.cfg
```
. Perhaps other
```
.dir
```
properties should be permitted to be relative to
```
dspace.dir
```
? Or somehow refer to it? (e.g.
```
\{dspace.dir\}/search
```
. Then you could just change
```
dspace.dir
```
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
```
SiteAuthenticator
```
rather than added to
```
SimpleAuthenticator
```
. Needs to be cleaned up as part of moving to StackableAuthenticationMethods

No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.