Re: [Dspace-tech] DSpace/Maven help request - update dependency version
As its not in the maven central repository. We would need to release it ourselves under org.dspace.dependencies or see if someone else can push out a new version of tm-extractors for maven central. To release into our repository, we just need to author a pom.xml file for the tm-extractors and package the jar... I set this up, but had some issues with sonatype failing to let me see the staged release on their side. I did release to the central repository. Still waiting to see it show up here: http://repo2.maven.org/maven2/org/dspace/dependencies/dspace-tm-extractors once available, give it a try and see if it fixes your issues. Mark On Wed, Oct 6, 2010 at 11:11 AM, Keith Gilbertson keith.gilbert...@library.gatech.edu wrote: Thanks Graham and Tim. I hadn't seen that. On Oct 6, 2010, at 11:52 AM, Graham Triggs wrote: That version of tm-extractors is quite old. There is a newer version on the Google site - http://code.google.com/p/text-mining/ - but it will take a bit of work wrapping things up for general use. It has dependencies on newer versions of POI than 0.4, and some distinct improvements to it's robustness. G On 6 October 2010 16:39, Tim Donohue tdono...@duraspace.org wrote: Ugh -- sounds like you've entered dependency hell. Though, I think the one shred of good news here is that it seems to only have a dependency conflict in one place in our codebase. It looks like (at a glance) if our WordFilter can be re-written to no longer need the org.textmining project, you *might* be OK (i.e. hopefully it wouldn't snowball on you). But, that would require finding a Word document text extractor that is as good as (or better than) that 'org.textmining' one, and then hoping it doesn't cause another dependency conflict. Not sure of any alternative Word text extractors, off the top of my head, but maybe others know of one? - Tim -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Scalability issues report, dsp...@cambridge
DSpace scalability issues report, per wiki template: 1. dsp...@cambridge, The University of Cambridge, UK. Technical contacts: Tom De Mulder, td...@cam.ac.uk (systems manager) Simon Brown st...@cam.ac.uk (DSpace developer) 2. a. DSpace version 1.6.2 with extensive local patches, using JSPUI Size: 137 communities, 258 collections, 200k items, 12TB, 436k bitstreams (excluding licenses) b. PostgreSQL 8.4.4 c. Tomcat 6.0.24 standalone d. Separate servers for webapp, DB, storage and ancillary functions Webapp/DB servers are HT 8-core Intel servers running Ubuntu Linux with 16GB of memory and fast local storage Java memory: -Xmx2048M -Xms2048M 3. a. - Unless Tomcat is restarted, it will consistently fail due to lack of memory in less than 48 hours. - Batch importer: will fail on large batch imports (order of thousands of items), performance degrades with size of repository and of batch. - Search indexer: fails on large repositories, slowing down and eventually running out of memory. - Assetstore: random structure causes large overhead on filesystem for no real gain See also our poster, presented in Gothenburg: http://tools.dspace.cam.ac.uk/DSUG09%20A2%20poster.pdf b. Installed vanilla DSpace 1.6.2, imported 200k randomly generated items, ran siege against it, watched it not cope. We've done profiling in the past, but not for 1.6. However, we've not noticed significant changes in the code that has issues. c. We have patches for the indexer; batch importer; thumbnail and PDF text extraction; assetstore structure; dark item masking in OAI and browse code 4. We can't commit to volunteering unless this can be incorporated into the work we need to undertake in our primary capacity of running the University's Institutional Repository. However, we would be willing to try and make this happen. -- Tom De Mulder td...@cam.ac.uk - Cambridge University Computing Service +44 1223 3 31843 - New Museums Site, Pembroke Street, Cambridge CB2 3QH -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Scalability issues report, dsp...@cambridge
(Apologies for replying to my own email.) One metric the template didn't ask for, I just noticed, is the number of hits per second. We average about 2 hits per second, which is very low, even if most of these hits are actual page views, not just layout elements. However, both our webapp and database servers are under constant load, the latter in particular. Actual load average numbers are meaningless for comparison because they depend so much on the way the OS kernel implements them, so I won't give them. Suffice to say, though, that we had to ask the people running our university search engine and similar services to throttle their index rate so the servers wouldn't get overloaded. Also of note is that the problems are mostly on the database and webapp end, there are no problems with I/O (disk or network). -- Tom De Mulder td...@cam.ac.uk - Cambridge University Computing Service +44 1223 3 31843 - New Museums Site, Pembroke Street, Cambridge CB2 3QH -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
I'm really having a hard time with this. In order to understand the code a bit more, I'm trying to find the line in the themes dir that would put the message Find Itme in the url: http://dspace-test-area/admin/item So I looked at http://dspace-test-area/DRI/admin/item which contains: document version=1.1 − body − div id=aspect.administrative.item.FindItemForm.div.find-item interactive=yes rend=primary administrative item action=/admin/item n=find-item method=get headFind Item/head So I figure I need to look for some match on the dri:div where id=aspect.administrative.item.FindItemForm.div.find-item But I can't find it. I have tried removing code to see if I can find it that way, but after a whole day of it, I can't find it. How does 'Find Item' make it to the browser window. Thank you! Jose -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Thursday, September 30, 2010 10:26 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for dri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using the xsl:apply-templates or xsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class=ds-table. If you search for ds-table in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xsl file) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Jose, I'm not sure I fully understand the question? Manakin works much differently than JSPUI -- so there is never really a one template to one page relationship. XSL Templates (in a theme) are usually used across many different pages in the system. Also, obviously many templates are used to generate a single page. The template you are looking for should be either in your Theme's XSL file or in the main 'dri2xhml.xsl' file (which is where most of the default templates reside -- as this file just basically transforms DRI into XHTML). If you are having trouble finding the exact template, sometimes it helps to look at the DRI structure of that page (add ?XML to the end of the Manakin URL, orXML if there's other stuff on the querystring already). You also may find it useful to use a tool like FireBug (http://getfirebug.com/) to analyze the structure of the generated XHTML, so that you can search through the templates in your Theme's XSL to find where that structure is generated. Hopefully that's helpful. Let us know if any of this doesn't make sense. - Tim On 9/29/2010 3:48 PM, Blanco, Jose wrote: I'm trying to get a better understanding of Manakin, and I've made a change in the aspect ConfirmItemForm.java And would like now to experiment with the theme that handles the display of DRIs coming from this aspect, but I can't find the template that is responsible
[Dspace-tech] recent webinars - recordings now available
The recordings of 2 recent webinars are now available on the duraspace.org website: http://duraspace.org/resources.php. Please see the full descriptions below. Valorie Hollister Director of Community Development, DSpace Project DuraSpace vhollis...@duraspace.org DSpace 1.6 Usage Statistics: How Does it Work? -- September 22, 2010 Join Ben Bosman, CTO @mire, as he explains how @mire’s open-source version of the “Content and Usage Analysis” DSpace module released with DSpace 1.6 can work for you. The DSpace 1.6 statistics solution offers logging of usage data including bitstream downloads, item display page visits, and collection and community homepage visits. This presentation will dive into the implementation details of this new statistics solution by outlining the following topics: •the storage of the statistics data; •various potential usage scenarios of the different statistics; •some of the opportunities for improving the statistics in future DSpace releases or customizing local requirements. DuraSpace Open Integration Architecture: A Pathway to Interoperation -- September 28, 2010 *What will it take to integrate a set of unique open source technologies in order to benefit the communities that rely on them to create accessible and durable digital resources? * Join Brad McLean, DuraSpace CTO, for an “All About Repositories” web seminar co-sponsored by DuraSpace and ORACLE where he will address that question. He will provide an update on DuraSpace’s technology strategy including a high level overview of each of DuraSpace’s three major open source preservation platforms: DSpace, a turnkey institutional repository; DuraCloud, preservation support over cloud computing platforms; and Fedora, a framework and toolkit for building digital repositories. This presentation will outline a proposed pathway to coexistence and interoperation of all three technologies. Brad will review updated roadmaps for each project and present current and future integration and migration plans. Each of these projects has a vibrant ecosystem of collaborating projects, from which examples will be highlighted illustrating practical integration approaches among and between these systems. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
Hi Jose, Text labels are not set in the XSLT, but rather are defined in the i18n/messages.xml file. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Blanco, Jose [blan...@umich.edu] Sent: Thursday, October 07, 2010 7:20 AM To: Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question I'm really having a hard time with this. In order to understand the code a bit more, I'm trying to find the line in the themes dir that would put the message Find Itme in the url: http://dspace-test-area/admin/item So I looked at http://dspace-test-area/DRI/admin/item which contains: document version=1.1 − body − div id=aspect.administrative.item.FindItemForm.div.find-item interactive=yes rend=primary administrative item action=/admin/item n=find-item method=get headFind Item/head So I figure I need to look for some match on the dri:div where id=aspect.administrative.item.FindItemForm.div.find-item But I can't find it. I have tried removing code to see if I can find it that way, but after a whole day of it, I can't find it. How does 'Find Item' make it to the browser window. Thank you! Jose -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Thursday, September 30, 2010 10:26 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for dri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using the xsl:apply-templates or xsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class=ds-table. If you search for ds-table in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xsl file) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Jose, I'm not sure I fully understand the question? Manakin works much differently than JSPUI -- so there is never really a one template to one page relationship. XSL Templates (in a theme) are usually used across many different pages in the system. Also, obviously many templates are used to generate a single page. The template you are looking for should be either in your Theme's XSL file or in the main 'dri2xhml.xsl' file (which is where most of the default templates reside -- as this file just basically transforms DRI into XHTML). If you are having trouble finding the exact template, sometimes it helps to look at the DRI structure of that page (add ?XML to the end of the Manakin URL, orXML if there's other stuff on the querystring already). You also may find it useful to use a tool like FireBug (http://getfirebug.com/) to analyze the structure of the generated XHTML, so that you can search through the templates in your Theme's XSL to find where that structure
Re: [Dspace-tech] manikin question
Hi Dave, Meant to get back to this discussion -- but, as you can see, it has taken me a while to do so :) On 10/1/2010 4:22 PM, Walker, David wrote: If the goal here is to add an input button to the interface -- on the 'confirm item' page, let's say -- I think it would be *significantly* easier if the developer could just open an XSLT file, find the 'confirm item' template, and just add the button like this: input type=submit If someone wanted to then change that button to a link or an image, I think it would, again, be significantly easier for them to locate the 'confirm item' template, find that input element, and then change it to: a href= Done. Easy. The way Manakin does it now, by comparison, seems both unnecessarily complex and unnecessarily restrictive. To add a button to the interface, the developer has to write several lines of Java code to create a pseudo-button DRI element and add it to the XML response. And then if someone wants to change that element, they have to either wade through a bunch of XSL templates to find the right one that can override buttons, or edit the Java source code and then recompile and redeploy Manakin. And that's just for this one very simple use case. If you need to make (even slightly) more complex changes to the interface, like actually *moving* elements around -- putting that button above or below a different interface element, for example -- then you have to edit Java code (cumbersome), or make large-scale changes to the XSLT (a lot of work). That just seems ten times more difficult than opening-up an XSLT file, and just editing actual HTML directly. Am I wrong? I think you have some good points you've made, and I appreciate it. However, it is worth pointing out a small flaw in this logic (at least for HTML buttons or forms in general). Obviously, as we both know, a button won't do anything unless there's some server-side code which understands how to process that request. I agree with your point, that there may be ways to make it much easier to add simple HTML elements into Templates. However, there will still need to be some Java code behind a button, which understands what that button needs to do when it is pressed. So, maybe it's worth looking at a specific example here to make sure everyone is on the same page. Let's look at how the Administrative Aspect works in Manakin, specifically the single form that allows you to Edit Metadata for an Item. Here's the general flow of how Manakin creates that specific form (within the larger page): (skipping over some underlying logic in Cocoon sitemaps, just to simplify) (0) Manakin sees you have the Administrative aspect enabled (it is possible to *disable* an aspect, so if you did NOT have the Administrative aspect installed/enabled, then you would be unable to access this form and your DSpace install would essentially be 'read-only'). Assume you are logged in as an Admin, so it will show you this form. (1) The 'org.dspace.app.xmlui.aspect.administrative.item.EditItemMetadataForm' class generates the DRI version of this Form -- in DRI this form is actually a dri:div interactive=yes. This dri:div also includes a dri:list of all editable metadata fields, along with a few dri:field type=button elements which represent the buttons. (2) Assuming you are using the Reference Theme, it is loaded by Manakin called. (3) The Reference Theme calls the structural.xsl. In this file, the template matching dri:d...@interactive='yes'] is matched, and the XSLT processing continues to match all the other templates in that file to built the XHTML (for simplicities sake, I'll refrain from listing them all -- plus as we've all already agreed this is a bit complex/confusing at times). (4) The XHTML is built, CSS is applied the page is shown to the user. (5) The user then edits some fields, and presses the Update button (6) This request is then processed by Manakin (Cocoon, actually). Specifically, it's processed by the 'administrative.js' file under the Administrative Aspect's config folder. This is a Flowscript file (Cocoon's flowscript format is essentially javascript, but can embed some Java calls). (7) In that flowscript file, the 'processEditItem()' method of the 'org.dspace.app.xmlui.aspect.administrative.FlowItemUtils' class is called. This method includes the Java code that actually *saves* the metadata change, and updates the Item in DSpace. So -- the reason for this exercise is to show that there's unfortunately a lot of complexities here, that we may be able to improve upon or clean up over time. For example: A. I think Dave makes a good point that we may wish to try and push more of the XHTML generation to the XSLs themselves (and simplify the amount of content the Aspects themselves are generating -- to ease the ability to customize pages). Whether or not this does away with DRI (or if it just makes
Re: [Dspace-tech] manikin question
But how does it get from that file to the page? -Original Message- From: Walker, David [mailto:dwal...@calstate.edu] Sent: Thursday, October 07, 2010 10:58 AM To: Blanco, Jose; Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: RE: [Dspace-tech] manikin question Hi Jose, Text labels are not set in the XSLT, but rather are defined in the i18n/messages.xml file. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Blanco, Jose [blan...@umich.edu] Sent: Thursday, October 07, 2010 7:20 AM To: Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question I'm really having a hard time with this. In order to understand the code a bit more, I'm trying to find the line in the themes dir that would put the message Find Itme in the url: http://dspace-test-area/admin/item So I looked at http://dspace-test-area/DRI/admin/item which contains: document version=1.1 − body − div id=aspect.administrative.item.FindItemForm.div.find-item interactive=yes rend=primary administrative item action=/admin/item n=find-item method=get headFind Item/head So I figure I need to look for some match on the dri:div where id=aspect.administrative.item.FindItemForm.div.find-item But I can't find it. I have tried removing code to see if I can find it that way, but after a whole day of it, I can't find it. How does 'Find Item' make it to the browser window. Thank you! Jose -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Thursday, September 30, 2010 10:26 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for dri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using the xsl:apply-templates or xsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class=ds-table. If you search for ds-table in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xsl file) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Jose, I'm not sure I fully understand the question? Manakin works much differently than JSPUI -- so there is never really a one template to one page relationship. XSL Templates (in a theme) are usually used across many different pages in the system. Also, obviously many templates are used to generate a single page. The template you are looking for should be either in your Theme's XSL file or in the main 'dri2xhml.xsl' file (which is where most of the default templates reside -- as this file just basically transforms DRI into XHTML). If you are having trouble finding the exact template, sometimes it helps to look at the DRI structure of that page (add ?XML to the end of the Manakin URL,
Re: [Dspace-tech] manikin question
Hi, Jose: would put the message Find Item in the url I'm guessing you actually mean in the title of the page? I believe your answer is somewhere in this file: dspace-src/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/administrative/item/ FindItemForm.java Two methods are of interest here: addPageMeta and addBody, they define the content for the Find Item form. Does that help? --Hardy -Original Message- From: Blanco, Jose [mailto:blan...@umich.edu] Sent: Thursday, October 07, 2010 10:19 AM To: Walker, David; Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question But how does it get from that file to the page? -Original Message- From: Walker, David [mailto:dwal...@calstate.edu] Sent: Thursday, October 07, 2010 10:58 AM To: Blanco, Jose; Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: RE: [Dspace-tech] manikin question Hi Jose, Text labels are not set in the XSLT, but rather are defined in the i18n/messages.xml file. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Blanco, Jose [blan...@umich.edu] Sent: Thursday, October 07, 2010 7:20 AM To: Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question I'm really having a hard time with this. In order to understand the code a bit more, I'm trying to find the line in the themes dir that would put the message Find Itme in the url: http://dspace-test-area/admin/item So I looked at http://dspace-test-area/DRI/admin/item which contains: document version=1.1 − body − div id=aspect.administrative.item.FindItemForm.div.find-item interactive=yes rend=primary administrative item action=/admin/item n=find-item method=get headFind Item/head So I figure I need to look for some match on the dri:div where id=aspect.administrative.item.FindItemForm.div.find-item But I can't find it. I have tried removing code to see if I can find it that way, but after a whole day of it, I can't find it. How does 'Find Item' make it to the browser window. Thank you! Jose -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Thursday, September 30, 2010 10:26 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for dri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using the xsl:apply-templates or xsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class=ds-table. If you search for ds-table in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xsl file) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc:
Re: [Dspace-tech] Scalability issues report, dsp...@cambridge
Hi Tom, First off, thanks for sharing your details, and some more specifics about the memory issues you are seeing. Much appreciated. I've got a few followup questions, if you or Simon don't mind answering them. Just trying to get a better understanding of where the core problem(s) reside, so that we can make useful suggestions to you (and find ways to resolve issues in DSpace itself). I've also noted a few areas where you might be able to achieve some temporary benefits (if you need something temporarily, at least until we can fix any issues in DSpace). On 10/7/2010 5:32 AM, Tom De Mulder wrote: DSpace scalability issues report, per wiki template: 1. dsp...@cambridge, The University of Cambridge, UK. Technical contacts: Tom De Mulder, td...@cam.ac.uk (systems manager) Simon Brown st...@cam.ac.uk (DSpace developer) 2. a. DSpace version 1.6.2 with extensive local patches, using JSPUI Size: 137 communities, 258 collections,200k items, 12TB, 436k bitstreams (excluding licenses) b. PostgreSQL 8.4.4 In order to better understand your PostgreSQL configs, would you be willing to share how your work_mem and shared_buffers are configured? Or, if you could share the whole Postgres config, that could also help. I just know there are sometimes ways to performance tune PostgreSQL for larger sized databases (which yours surely is, based on the amount of content). If you've already investigated PostgreSQL performance tuning, it'd be good to know as well. Here's some very basic info from our wiki (and much more off the PostgreSQL site as well), which shows settings we'd be looking to tune for potentially better DB performance: https://wiki.duraspace.org/display/DSPACE/PostgresPerformanceTuning http://wiki.postgresql.org/wiki/Performance_Optimization c. Tomcat 6.0.24 standalone d. Separate servers for webapp, DB, storage and ancillary functions Webapp/DB servers are HT 8-core Intel servers running Ubuntu Linux with 16GB of memory and fast local storage Java memory: -Xmx2048M -Xms2048M Obviously, throwing more memory at this issue may not be a long term solution. But, you could think about (even temporarily) providing more memory to Java (beyond the 2GB) to see if that can temporarily lessen the frequency of these memory errors (likely, they may still occur at some point though). I'm not sure if this is possible temporary fix or not (depends on whether the rest of that 16GB of memory is already allocated to other applications) 3. a. - Unless Tomcat is restarted, it will consistently fail due to lack of memory in less than 48 hours. - Batch importer: will fail on large batch imports (order of thousands of items), performance degrades with size of repository and of batch. - Search indexer: fails on large repositories, slowing down and eventually running out of memory. - Assetstore: random structure causes large overhead on filesystem for no real gain See also our poster, presented in Gothenburg: http://tools.dspace.cam.ac.uk/DSUG09%20A2%20poster.pdf Could you actually send us a few of the out of memory error messages you are seeing? You may be seeing out of memory errors either from PermGen (OutOfMemoryError: PermGen space) or from Heap (OutOfMemoryError: Java heap space). So, it'd be good to determine which type(s) of memory error it is. We might be able to help you tweak your Java settings to at least temporarily avoid these errors being thrown. (Again, likely not a permanent fix, but may help temporarily until we can fix any memory usage issues in DSpace.) Also, knowing the type(s) of memory error may be able to help us determine what the cause in DSpace may be. b. Installed vanilla DSpace 1.6.2, imported 200k randomly generated items, ran siege against it, watched it not cope. We've done profiling in the past, but not for 1.6. However, we've not noticed significant changes in the code that has issues. It'd be good to get an idea of what wasn't coping well in the vanilla DSpace 1.6.2 tests you ran. For instance, did accessing DSpace suddenly become extremely slow (e.g. browsing/searching), or was it the import script that slowed down (or maybe it was both)? I guess the question is what did you have the SIEGE program (http://www.joedog.org/index/siege-home) testing? Was it just doing random accesses of the website and noting very poor performance or receiving more out-of-memory errors? If you could, it would also would be wonderful if you would share your scripts for randomly generating 200K DSpace items. This would allow us to do the same testing locally to replicate exactly what you have seen. Plus, this seems like it could be a great testing tool for the whole community (we are always looking for a decent set of test data). Sure, we could probably rewrite the code from scratch, but it's always better to just grab a copy of
Re: [Dspace-tech] manikin question
Yes, I see how it gets set here: findItem.setHead(T_head1); I think what is causing me so much trouble is my lack of knowledge of DRI and cocoon. I was expecting the DRI object to be completely converted to HTML by the themes, but that is not the case, right? Some tags in the DRI object are handled by cocoon, right, and this is one of them. For now I've just been trying to understand the code because I'd like to make a change to the withdraw confirmation page. I'd like to add a pick list for the user to select the reason for withdraw. How I create this pick list is still a mystery to me. I've been looking at the creation of the pick list for the advanced search page as a guide. Actually, hoping that I could copy paste and change a few things, but I don't think it's going to be that easy. I'm going to read: http://scott.phillips.name/wp-content/uploads/2009/05/tdl-manakin-training.pdf\ to see if it can help me. I found the jspui interface a lot easier to understand. -Jose -Original Message- From: Pottinger, Hardy J. [mailto:pottinge...@umsystem.edu] Sent: Thursday, October 07, 2010 12:29 PM To: Blanco, Jose; Walker, David; Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: RE: [Dspace-tech] manikin question Hi, Jose: would put the message Find Item in the url I'm guessing you actually mean in the title of the page? I believe your answer is somewhere in this file: dspace-src/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/administrative/item/ FindItemForm.java Two methods are of interest here: addPageMeta and addBody, they define the content for the Find Item form. Does that help? --Hardy -Original Message- From: Blanco, Jose [mailto:blan...@umich.edu] Sent: Thursday, October 07, 2010 10:19 AM To: Walker, David; Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question But how does it get from that file to the page? -Original Message- From: Walker, David [mailto:dwal...@calstate.edu] Sent: Thursday, October 07, 2010 10:58 AM To: Blanco, Jose; Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: RE: [Dspace-tech] manikin question Hi Jose, Text labels are not set in the XSLT, but rather are defined in the i18n/messages.xml file. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Blanco, Jose [blan...@umich.edu] Sent: Thursday, October 07, 2010 7:20 AM To: Tim Donohue Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question I'm really having a hard time with this. In order to understand the code a bit more, I'm trying to find the line in the themes dir that would put the message Find Itme in the url: http://dspace-test-area/admin/item So I looked at http://dspace-test-area/DRI/admin/item which contains: document version=1.1 − body − div id=aspect.administrative.item.FindItemForm.div.find-item interactive=yes rend=primary administrative item action=/admin/item n=find-item method=get headFind Item/head So I figure I need to look for some match on the dri:div where id=aspect.administrative.item.FindItemForm.div.find-item But I can't find it. I have tried removing code to see if I can find it that way, but after a whole day of it, I can't find it. How does 'Find Item' make it to the browser window. Thank you! Jose -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Thursday, September 30, 2010 10:26 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for dri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using the xsl:apply-templates or xsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking
Re: [Dspace-tech] manikin question
Hardy, I cannot recall seeing any diagrams which describe the flow of specific aspects in Manakin. But, it's possible Scott or others on this list may know of some? The best diagrams I know of are those from Scott's slide stack (which you already linked to). Those are a great overview of how Manakin (and Cocoon) work in general -- though they don't dig into the flow of very specific aspects. That all being said -- if anyone wants to generate such a diagram(s), I'm sure it'd be highly useful to many people in the community! :) - Tim On 10/7/2010 11:14 AM, Pottinger, Hardy J. wrote: Tim: thank you for that walk-through of the Administrative aspect. It is very timely with some work that I'm doing. I'm curious, has anyone produced documentation, say perhaps a diagram (or several), of the various aspects and the flow of processing for them? I'm thinking something a bit more specific than Scott Phillips' excellent Manakin training slide stack (http://scott.phillips.name/wp-content/uploads/2009/05/tdl-manakin-training.pdf). The DSpace wiki has a great intro/overview of aspects for Manakin ( https://wiki.duraspace.org/display/DSPACE/Create+a+new+aspect+(Manakin) ) , and the JavaDocs for the XMLUI API (http://projects.dspace.org/dspace-xmlui/dspace-xmlui-api/apidocs/index.html) are helpful, too. But, if anyone has something more visual, to explain the flow of specific aspects, I'd love to see it. Thanks! --Hardy -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Thursday, October 07, 2010 10:00 AM To: Walker, David Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Dave, Meant to get back to this discussion -- but, as you can see, it has taken me a while to do so :) On 10/1/2010 4:22 PM, Walker, David wrote: If the goal here is to add an input button to the interface -- on the 'confirm item' page, let's say -- I think it would be *significantly* easier if the developer could just open an XSLT file, find the 'confirm item' template, and just add the button like this: input type=submit If someone wanted to then change that button to a link or an image, I think it would, again, be significantly easier for them to locate the 'confirm item' template, find that input element, and then change it to: a href= Done. Easy. The way Manakin does it now, by comparison, seems both unnecessarily complex and unnecessarily restrictive. To add a button to the interface, the developer has to write several lines of Java code to create a pseudo-button DRI element and add it to the XML response. And then if someone wants to change that element, they have to either wade through a bunch of XSL templates to find the right one that can override buttons, or edit the Java source code and then recompile and redeploy Manakin. And that's just for this one very simple use case. If you need to make (even slightly) more complex changes to the interface, like actually *moving* elements around -- putting that button above or below a different interface element, for example -- then you have to edit Java code (cumbersome), or make large-scale changes to the XSLT (a lot of work). That just seems ten times more difficult than opening-up an XSLT file, and just editing actual HTML directly. Am I wrong? I think you have some good points you've made, and I appreciate it. However, it is worth pointing out a small flaw in this logic (at least for HTML buttons or forms in general). Obviously, as we both know, a button won't do anything unless there's some server-side code which understands how to process that request. I agree with your point, that there may be ways to make it much easier to add simple HTML elements into Templates. However, there will still need to be some Java code behind a button, which understands what that button needs to do when it is pressed. So, maybe it's worth looking at a specific example here to make sure everyone is on the same page. Let's look at how the Administrative Aspect works in Manakin, specifically the single form that allows you to Edit Metadata for an Item. Here's the general flow of how Manakin creates that specific form (within the larger page): (skipping over some underlying logic in Cocoon sitemaps, just to simplify) (0) Manakin sees you have the Administrative aspect enabled (it is possible to *disable* an aspect, so if you did NOT have the Administrative aspect installed/enabled, then you would be unable to access this form and your DSpace install would essentially be 'read-only'). Assume you are logged in as an Admin, so it will show you this form. (1) The 'org.dspace.app.xmlui.aspect.administrative.item.EditItemMetadataForm' class generates the DRI version of this Form -- in DRI this form is actually adri:div interactive=yes. Thisdri:div also includes a dri:list of all editable metadata fields, along with a
Re: [Dspace-tech] manikin question
Obviously, as we both know, a button won't do anything unless there's some server-side code which understands how to process that request. Oh, yes, of course. Obviously, there needs to be Java code that can processes the incoming request and do something about it: Getting data from the database, for example. And then passing that data back to the interface layer for display. My point is that the Java code should be *solely* concerned with those tasks. It shouldn't try to create the interface. That's not it's job. It should be concerned with the business logic, not presentational logic. Now, the presentational layer can't be *completely* disconnected from the business logic layer. That wouldn't make any sense. And I don't think I ever said that. What I'm saying is that the two need to be *separate* from each other. They are not (or at least not enough) now in Manakin. I'm still not 100% sure that DRI could be done away with (you haven't swayed me completely yet). Let me try some more, then. ;-) For any presentation layer to create an interface, it needs data. So, in Manakin's case, the Java code needs to create XML that contains enough data for the XSLT (which I'm arguing should be the sole presentation layer) to actually render a page that the user can see. Let's take the search results page as an example. Not only does the Java code need to actual fetch the search results themselves and add that to the XML, but it also needs to tell the interface some things about the result set as a whole: These are results 1 to 10 of 340, for example. To achieve that, the Java code could simply put something like this in the XML response: search_results total340/total start1/start end10/end ... /search_results The XSLT could then create the *presentation* of that data like this: div class=searchResults Results xsl:value-of select=search_results/start to xsl:value-of select=search_results/send of xsl:value-of select=search_results/total /div (putting aside things like i18n, just for simplicity sake here, of course.) This is what I mean by *semantically* marked-up XML. The XML here isn't trying to tell me anything about how this data should be displayed. It doesn't need to. Moreover it *shouldn't*. It just needs to get me the *data*, and then the XSLT can create the display, slotting in that data in the places it needs to go. This is how all web templating systems work -- they layout the interface using HTML, and then slot-in the data where it needs to go. So why do I need DRI? Why create what is, in effect, a presentational XML layer? As Master Yoda would say: Create HTML or do not, there is no intermediary quasi-presentational XML. Currently, DRI includes some of the data we will need. But we don't need DRI itself. Just give me the data! --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, October 07, 2010 7:59 AM To: Walker, David Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Dave, Meant to get back to this discussion -- but, as you can see, it has taken me a while to do so :) On 10/1/2010 4:22 PM, Walker, David wrote: If the goal here is to add an input button to the interface -- on the 'confirm item' page, let's say -- I think it would be *significantly* easier if the developer could just open an XSLT file, find the 'confirm item' template, and just add the button like this: input type=submit If someone wanted to then change that button to a link or an image, I think it would, again, be significantly easier for them to locate the 'confirm item' template, find that input element, and then change it to: a href= Done. Easy. The way Manakin does it now, by comparison, seems both unnecessarily complex and unnecessarily restrictive. To add a button to the interface, the developer has to write several lines of Java code to create a pseudo-button DRI element and add it to the XML response. And then if someone wants to change that element, they have to either wade through a bunch of XSL templates to find the right one that can override buttons, or edit the Java source code and then recompile and redeploy Manakin. And that's just for this one very simple use case. If you need to make (even slightly) more complex changes to the interface, like actually *moving* elements around -- putting that button above or below a different interface element, for example -- then you have to edit Java code (cumbersome), or make large-scale changes to the XSLT (a lot of work). That just seems ten times more difficult than opening-up an XSLT file, and just editing actual HTML directly. Am I wrong? I think you have some good points you've made, and I appreciate it. However, it is worth
Re: [Dspace-tech] manikin question
Well, one thing which occurs to me is that dri:field type='button'/ should instead be something like dri:action/ and let the Theme figure out whether it wants to lay out a button (or anything else) which links to the action. These button fields are really just abstract handles for things the user can ask to have done. If they weren't *called* buttons, they wouldn't look like presentation. If we do away with DRI we will have to invent something almost like it. We still need some way to build a bag of structured, labeled data and action handles, so that when a Theme reaches into the bag it can know what to grab and make good use of XSL facilities to do so. What's going on here, it seems to me, is that the current design strives for separation of concerns between data and presentation across the Aspect/Theme boundary but perhaps has not quite achieved it, compounded with the use of terms in DRI which we are conditioned to think of as presentational. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ pgpngMSDxtC9l.pgp Description: PGP signature -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] DSpace Global Outreach Oct 5 Meeting Notes
The notes from the DGOC October 5 meeting are available at: https://wiki.duraspace.org/display/DSPACE/DGOC+October+5%2C+2010. The next meeting will be on November 2. Please see my previous post below for additional information. Feel free to contact me with any questions or feedback. Valorie Hollister Director of Community Development, DSpace Project DuraSpace vhollis...@duraspace.org-- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
We still need some way to build a bag of structured, labeled data and action handles, so that when a Theme reaches into the bag it can know what to grab Yes, right. And this is really easy to do: labeldata/label It'll probably need to be more complex than that, of course -- but not much. If we do away with DRI we will have to invent something almost like it. But what I just described above is nothing like DRI. Unless you count the fact that they are both XML. DRI tries to accomplish a whole bunch of things that a simple attribute-value pair does not. But, IMO, those things are unnecessary. All we *need* is a simple mechanism to get data to the interface. Anything beyond that just complicates and confuses the process. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Mark H. Wood [mw...@iupui.edu] Sent: Thursday, October 07, 2010 10:40 AM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Well, one thing which occurs to me is that dri:field type='button'/ should instead be something like dri:action/ and let the Theme figure out whether it wants to lay out a button (or anything else) which links to the action. These button fields are really just abstract handles for things the user can ask to have done. If they weren't *called* buttons, they wouldn't look like presentation. If we do away with DRI we will have to invent something almost like it. We still need some way to build a bag of structured, labeled data and action handles, so that when a Theme reaches into the bag it can know what to grab and make good use of XSL facilities to do so. What's going on here, it seems to me, is that the current design strives for separation of concerns between data and presentation across the Aspect/Theme boundary but perhaps has not quite achieved it, compounded with the use of terms in DRI which we are conditioned to think of as presentational. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] customize DSpace 1.6.2
Dear all... I am trying to customize de DSpace 1.6.2. I could change the metadata and change the input-form to use the new metadata added too. In the input-form, there are lots of types-input. I´ve used the dropdown as type-input, but i would like to add a textfield with a button to possibity adding a new item in the dropdown. e.i there is a dropdown with 3 itens, item 1 , item 2 and item 3, so is there any way to add a item 4 in the dropdown by the UI? If so, how can i do that? Another doubt.. I´ve seem some tutorials that explain how i can modify the messages of UI, in the JSPUI, and in all them people say that the message.properties is in C:\DSpace\config\language-packs\, but in my case this file is in C:\dspace-1.6.2-src-release\dspace-1.6.2-src-release\dspace-api\src\main\resources\, then when i do some change in messages, the modification doesn´t appear in the UI. Am i doing anything wrong? Thanks for yours attention and sorry for english mistakes. Att, Thiago. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Turn embargo off?
I built 1.6.2 with |embargo.field.terms = SCHEMA.ELEMENT.QUALIFIER and ||embargo.field.lift = SCHEMA.ELEMENT.QUALIFIER commented out thinking that would disable embargo. When I try to enter an item I get | java.lang.IllegalStateException: Missing one or more of the required DSpace configuration properties for EmbargoManager, check your configuration file. So I commented out the rest of the section on embargo and did an ant update. I still get the error. How can I turn off embargo? Marvin -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Scalability issues report, dsp...@cambridge
Hi Tom, Thanks for this extra level of information - it will really help. A few random questions come to mind: d. Separate servers for webapp, DB, storage and ancillary functions Webapp/DB servers are HT 8-core Intel servers running Ubuntu Linux with 16GB of memory and fast local storage Java memory: -Xmx2048M -Xms2048M Is there a reason why you only allocate 1/8th of the system memory to the application? Have you found that adding extra doesn't help? - Assetstore: random structure causes large overhead on filesystem for no real gain Are you able to expand on the overhead that is caused, and from your profiling, explain how the structure could be improved? My gut (and uniformed) instinct would be that since asset store reads are completely random depending on the items being viewed at the time, the layout of directories would be irrelevant. Writes may be slightly less efficient, but since writes only tend to occur once, they are of less consequence. - Search indexer: fails on large repositories, slowing down and eventually running out of memory. Do you have any percentages on the amount of page views that relate to browse, and how many relate to other views? I'm curious if browse from the front end is causing an issue too? The reason I'm asking, is that with the potential inclusion of the dspace-discovery layer in a future version, this could replace the database-driven browse system with solr. Not only will this provide a richer faceted search, but it could likely offer a good performance boost for browse-related functions. It also offers another way of scaling-out, by putting solr on a different server. 4. We can't commit to volunteering unless this can be incorporated into the work we need to undertake in our primary capacity of running the University's Institutional Repository. However, we would be willing to try and make this happen. That would be great if you could, and we'd all really appreciate your input. Users of the software such as yourself, or BioMed Central's Open Repository are pushing the software in ways that 95% of installations don't (yet). In order to push past these boundaries in terms of scalability the only way we can effectively do so is with the active participation of those who are encountering the problems. One of the joys of working in an open source environment is that we have the structures and process that enable this, and it is great to watch the results when everyone pitches in together to improve the software for us all. Cheers, Stuart Lewis IT Innovations Analyst and Developer Te Tumu Herenga The University of Auckland Library Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand Ph: +64 (0)9 373 7599 x81928 -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] handle problem
Hi Gaetano,
Could you check the value of dspace.baseUrl and dspace.url in
[dspace]/config/dspace.cfg?
Going by the information you've given, here are the recommended values for
your DSpace instance:
dspace.hostname = elea.unisa.it
dspace.baseUrl = http://${dspace.hostname}:8080
dspace.url = ${dspace.baseUrl}/jspui
If the variables used are making things unclear, this basically turns into:
dspace.hostname = elea.unisa.it
dspace.baseUrl = http://elea.unisa.it:8080
dspace.url = http://elea.unisa.it:8080/jspui
Recent versions of DSpace have /xmlui as the default webapp in
${dspace.url}, and I think this is why you're seeing this behaviour.
If you do change any of these values, you'll need to restart DSpace *and*
your handle server for the changes to take effect.
Hope this helps -- let me know how you get on.
Cheers,
Kim
On 7 October 2010 18:55, Gaetano Rufino gruf...@unisa.it wrote:
Hello All,
I am working on Dspace 1.6.2 JSPUI.
the handle is working , but if for example we use this URL:
http://hdl.handle.net/10556/115, we have this result:
http://elea.unisa.it:8080/xmlui/handle/10556/115, unfortunately we do not
use XMLUI, but use jspui.
So we should return such http://elea.unisa.it:8080/jspui/handle/10556/115.
How can we do?
Thanks,
Gaetano
__
C.S.I. Universita' degli Studi di Salerno
Gaetano Rufino
Ufficio Sistemi Tecnologici
E-Mail: gruf...@unisa.it
Tel: +39 089 966 350 Fax: +39 089 966 368/346
Tel. HelpDesk: +39 089 966 400
__
“*Sic parvis magna”*
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
David et al. I have been following this discussion and trying to determine an appropriate point of entry. So lets dive in... In @mire, we are highly invested in the DRI solution at this time, proposing a major change in DRI for DSpace 1.7 is not something that @mire will support due to the impact it will have on our clients dspace solutions. Likewise, discussion internally has lead to an opinion that breaking up the xslt into separate files for each page actually defeats the design goals of the XMLUI theming tier. I.E. having one file within which all customizations reside to manage your theme. Using separate files that are overridden introduces a variant to the current approach and possibly more confusion about which template is being applied. The current mechanism relies solely on xslt template priorities for the determination of what templates will be overridden in one theme and we prefer this approach. --- This said, however, I have always been interested in alternatives to METS for flagging the content necessary for rendering a view... The separation of DRI and METS was a bit of an evolutionary attempt to improve the performance and there are some kludges within it. the original design, embedded METS within the DRI, and this it served a container-ship role in aggregating all the data that was necessary for the view. Performance required the separation of METS under another pipeline for rendering that content. There are further kludges that introduce a pseudo XPath capability to retrieve only specific portions of the METS document... which is further complexity that end users are unaware of. It was this division of content that made the role DRI less clear. To be honest, the use of generating whole METS docs and handing them to the theme to enable the theme developer to add/remove content from the views is what broke the separation of concerns. It is the References and ReferencesSets that point at METS documents that violate the generation of content only in the aspect tier. This became very clear when working on Discovery, I became aware of the use of METS as a source for the search, browse and recently added resultsets in a search is a bit of over engineering and an attempt to model the older JSPUI approaches to selecting the fields from the actual Item object that should be present in search results... Its actually quite a pain to get around. This choice of approach actually makes it more difficult to use the output from the Solr search engine (return fields, hit highlighting, ranking info, etc) to assist in rendering. In which case, I was actually more interested in rendering the search engine results as DRI list elements and not as a set of METS references. I still feel this way, and in which case, for the long term, I'm promoting a solution for discovery that is still DRI centric. So, changing the use of DRI in this area will derail that development direction. So, to be clear, the ability to construct nested divisions, lists, options, meta sections is quite powerful for getting the structure of the content pushed into the presentation layer. We are talking here about not just the semantic structure of the page to be rendered but also the content of the DSpace item, community, collection etc. I see an argument here about form fields vs. links. And this is an example of why we want to use Aspects to generate the content of the page (including the required inputs) as opposed to having the theme developer do it. Adding a form field is a Aspect developer project, deciding if its a plain old textbox or some dynamic html rich text widget is a theming/branding activity. In fact, if one were to make any changes to DRI, it might be argued, based on the above examples, that Most of DRI interactive forms would have been better suited to be Cocoon CFORMS (http://cocoon.apache.org/2.2/blocks/forms/1.0/489_1_1.html). This would have made it very clear that Aspects produce page structural content (including forms) and that Themes simply style that content and give an opportunity to override some the output. This would have reused a key set of tooling already developed in the Cocoon community and in use today in projects such as Apache Lenya. CFORMS are the converse of javascript flow that Tim was talking about, rather than using CFORMS, TAMU instead invented a custom mechanism for representing interactive sections of content in DRI. CFORMS could be employed to replace Interactive DRI sections or at the theming layer to brand the existing DRI as CFORMS. Both are probably viable approaches. Mark On Thu, Oct 7, 2010 at 11:23 AM, Walker, David dwal...@calstate.edu wrote: We still need some way to build a bag of structured, labeled data and action handles, so that when a Theme reaches into the bag it can know what to grab Yes, right. And this is really easy to do: labeldata/label It'll probably need to be more complex than that, of course -- but not much. If we do away with DRI
