On Sep 22, 2008, at 9:19 PM, Gary Browne wrote:
Hi allIt's great how everything in DSpace 1.5 is maintained within the source code directory, makes support so much easier. Only thing is, there are exceptions. I just had a complaint (well, a query) from my repository manager that the sidebar news that he changed had reverted to the previous version. This happened after I had done a rebuild and deploy. So I made some changes to the sidebar news from the GUI (JSP) and sure enough, the changes are written to [dspace]/ config/news-side.html, rather than [dspace-source]/dspace/config/ news-side.html. The news-top.html seems to suffer the same fate ie: everytime I rebuild, the news html pages in the install directory are overwritten with those from the source directory (as they should be).
I think this exposes two issues.1.) a possible miscommunication that the [dspace-source] is something that is used by the [dspace] at runtime. Something I think should be avoided.
2.) That the ability to edit these files in the UI and store them in SVN causes a conflict. Ultimately a better solution would be to have this "Content" stored with other content in the repository, rather than in the configuration directory as a configuration (yet another bad practice).
Anyways, for now you'll want to make sure that your manager gets their content to you so that it can be preserved across your upgrades.
Would be great if this behaviour could be changed to reflect the general ideology of maintaining changes within the source - unless I'm mistaken about this ideology? I guess currently DSpace has no way of knowing where your source code is? Maybe it could be db driven? I'm happy to look at the code myself if anyone thinks this is worthwhile.
Well, the problem is similar to what I state above, the confusion is actually between "source" and "content", unfortunately we stuff in the config directory thats really "content" (the news sections). Yes it should really be stored either in the db or in the bitstream repo.
Anyways, great points and I'll add it to my list of req/issues for 2.0. Conversely, I suspect what we are actually talking about here is establishing a db table for "Site" and actually querying/editing ti when these fields need updating. And that might be a great small project to work on for a 1.5.2 release.
Cheers, Mark
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
