[Dspace-tech] Eperson is not defined- error
When clicking the link Forgot your password? on Manakin 1.1a (DSpace 1.4.2) I get the following error. Any ideas what wrong? -Mika --- org.mozilla.javascript.EcmaError: EPerson is not defined. ReferenceError - context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/EPerson/eperson.js - 220:0 Cocoon stacktrace [hide] EPerson is not defined. context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/EPerson/eperson.js - 220:0 ReferenceError Error calling continuation context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/EPerson/eperson.js - 220:0 [EcmaError] context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/EPerson/eperson.js - 220:-1 context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/EPerson/sitemap.xmap - 105:36map:call context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/aspects.xmap - 124:72map:mount context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/sitemap.xmap - 274:80map:mount context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/Submission/sitemap.xmap - 399:27map:serialize context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/Submission/sitemap.xmap - 375:26map:generate context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/Administrative/sitemap.xmap - 797:31map:serialize type=xml context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/Administrative/sitemap.xmap - 265:38map:transform type=Navigation context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/Administrative/sitemap.xmap - 264:44map:transform type=SystemwideAlerts context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/Administrative/sitemap.xmap - 263:19map:generate context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/aspects.xmap - 120:34map:serialize type=xml context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/aspects.xmap - 119:43map:transform type=PageNotFound context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/aspects/aspects.xmap - 118:22map:generate context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/TDS/sitemap.xmap - 171:34map:serialize type=xhtml context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/TDS/sitemap.xmap - 168:84map:transform type=NamespaceFilter context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/TDS/sitemap.xmap - 167:78map:transform type=NamespaceFilter context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/TDS/sitemap.xmap - 161:33map:transform type=i18n context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/TDS/sitemap.xmap - 157:44map:transform context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/TDS/sitemap.xmap - 142:45map:transform type=IncludePageMeta context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/TDS/sitemap.xmap - 118:55map:generate type=file context:/file:/tmp/Jetty_0_0_0_0_8048_dspace.war__dspace__n8dysb/cocoon-files/Jetty_0_0_0_0_8048_dikk.war__dikk__-ajb4mj/webapp/themes/themes.xmap - 63:45 map:mount
Re: [Dspace-tech] Dspace 1.5 customizable submission
Just a quick FYI for those interested (and listening in on this thread): I've implemented Graham's Configurable Submission suggestions in preparation for 1.5 beta (and 1.5 final release). So, if you look at the current 1.5.x branch in DSpace SVN, there is now a single 'item-submission.xml' configuration file containing the configurations for BOTH the XML-UI and JSP-UI. A step configuration now looks like this in the item-submission.xml: step headingsubmit.progressbar.describe/heading processing-classorg.dspace.submit.step.DescribeStep/processing-class jspui-bindingorg.dspace.app.webui.submit.step.JSPDescribeStep/jspui-binding xmlui-bindingorg.dspace.app.xmlui.aspect.submission.submit.DescribeStep/xmlui-binding workflow-editabletrue/workflow-editable /step The Configurable Submission documentation is also updated in [dspace]/docs/submission.html (when you download the 1.5.x branch). Let me know if there are questions, or if anyone notices any bugs. I did some pretty thorough testing, so it *should* be bug-free...famous last words. :) - Tim Tim Donohue wrote: Graham, Ok...I'm coming around, and I agree with your argument about forcing people to do things the 'right way' in terms of Java programming, and also better supporting both UIs. I'll take some time this week to dig into the 1.5 code and see what a change like this would involve. Assuming there's no major walls or sticky points in moving this route, I should be able to implement this relatively easily and quickly for 1.5. - Tim Graham Triggs wrote: On Mon, 2008-01-07 at 11:01 -0600, Tim Donohue wrote: (1) No ability to easily change the review JSP without recompiling. But, that may not be a big deal...as you noted the same is currently true for the JSPs used to create the various submission forms There is nothing to say we couldn't have optional extended configuration - so it could be made possible to add additional input-jsp and review-jsp elements to the configuration - or even attributes to the jsp-binding element. That said, the only time that really becomes useful is if you want to specify what is eseentially the same step in different submission workflows, with different LF for each. (2) If someone wanted to create a custom step for JSPUI-only, they'd have to still create two separate classes: (1) Processing Class and (2) JSP binding class. The current way, you'd just need to create a single Processing Class which implements the JSPStep interface. That is absolutely no bad thing. Firstly, although you would have to supply two separate classes, the difference in the amount of code involved is negligible. More importantly, it means people do things the right way - so if they want to move from JSP to XML ui in the future, or they want to share their custom step with our members of the community that may be using a different interface, it's all a lot easier. On the plus side, your idea does vastly simplify the configurations. The only other option your suggestion brings to mind (which would keep the API mostly as-is), would be to take an in-between route and create a configuration looking more like: step headinggeneral.progress.describe/heading jspui-binding processing-classorg.dspace.app.webui.submit.step.JSPDescribeStep/processing-class review-jsp/submit/review-metadata.jsp/review-jsp /jspui-binding xmlui-binding processing-classorg.dspace.submit.step.DescribeStep/processing-class xml-ui-classorg.dspace.app.xmlui.aspect.submission.submit.DescribeStep/xml-ui-class /xmlui-binding workflow-editabletrue/workflow-editable /step I prefer my 'simplistic' configuration, as forcing people to deal with the class seperation now provides them with long term benefits, and improves the community's ability to collaborate. Here, the UI binding is down at the configuration level...and it would allow the jspui-binding and the xmlui-binding to change more over time, as necessary. As a potential example, configurations/options for various steps could eventually be placed as such: as mentioned above, the configuration could still allow for: step ... xml-binding.../xml-binding jsp-binding.../jsp-binding jsp-form.../jsp-form jsp-review.../jsp-review /step or preferably: step ... xml-binding.../xml-binding jsp-binding form=... review=../jsp-binding /step G This email has been scanned by Postini. For more information please visit http://www.postini.com - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech --
[Dspace-tech] Creative Commons Enigma
Hi I noticed some really strange behaviour in our DSpace installation. It is the Creative Commons licensing. When the setting in dspace.cfg is set to true Creative Commons settings ## # are Creative Commons licenses used in submission? webui.submit.enable-cc = true the Creative Commons section of the submission process has TWO separate steps. The first one is the one that has the iFrame that displays the Creative Commons webpage in it, and there are two choices that the submitter can set before accepting the license. After that, there is another step that asks another time whether the submitter wants to accept the Creative Commons license. This page is much simpler and has no choices, only two buttons - either I Grant the License or I Do Not Grant the License . The strange thing is that the first stage points to a version of the CC license that is NOT the one that we want to use, and that I have entered in the default.license config file. We want to use the Canadian 2.5 license, but it displays - AND attaches - the generic 3.0 CC license. That second stage does point to the Canadian 2.5 version license - but it is apparently discarded. The strangeness becomes more apparent when I do this: Creative Commons settings ## # are Creative Commons licenses used in submission? webui.submit.enable-cc = false In that case, there is no longer the first step (the iFrame one) - but the second step (the one with the url to the Canadian version and the I Grant the License or I Do Not Grant the License buttons) STILL comes up. But submissions do not have the CC license attached .. which does make some sense, since it is disabled. So I'd really like to know: - what makes this second step appear even though the CC is disabled in dspace.cfg? - How can I turn it off? - where can I make the first CC license point to the right CC license version (Canadian 2.5) ? It is not in the default.license .. since that is set to the Canadian one. - if we could get the second step to work with the right CC version that would be even better, since it is much simpler than that brittle iFrame mechanism My gosh, this is *complex*. thanks in advance, maike -- Maike Dulk - Programmer / Analyst McPherson Library, University of Victoria (t) 250-886-5709 / (e) [EMAIL PROTECTED] -- Harthon gerithach aeair vilui / I hope you will have kind seas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Report title on statistics page
thanks Stuart! It is working like a charm now. :-) maike On 7-Jan-08, at 11:05 PM, Stuart Lewis [sdl] wrote: Hi Maike, For some reason the generated reports keep on displaying the title Statistics for Edinburgh Research Archive on neptune == our server name The dspace name setting in dspace.cfg is set to our own name, and I can find nowhere in the messages.properties, the stat executables, the dstat.cfg or anywhere else where this can be changed. I did restart the tomcat server after doing the necessary changes. Have you changed the last two lines in [dspace]/config/dstat.cfg: # the name and url of the service being reported on host.name=Edinburgh Research Archive host.url=http://www.era.lib.ed.ac.uk/ Once those have been changed, you will probably need to (AFTER TAKING A BACKUP) remove all the files: [dspace]/log/*.dat (NOT *.log) which are the data files created by the statistics log analyser. These dat files hold the Edinburgh name and URL. You can then re-run all the stats scripts (including the stat 'initial' scripts) and hopefully the problem might be solved. Thanks, Stuart _ Gwasanaethau Gwybodaeth Information Services Prifysgol Aberystwyth Aberystwyth University E-bost / E-mail: [EMAIL PROTECTED] Ffon / Tel: (01970) 622860 _ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
