On Feb 26, 2009, at 12:34 PM, Kim Shepherd wrote: >> From: Mark H. Wood [mailto:mw...@iupui.edu] >> Sent: Friday, 27 February 2009 5:14 a.m. >> On Thu, Feb 26, 2009 at 04:31:28PM +0200, mikan.d.dspace listmail >> wrote: >>> At the moment Dspace uses input-forms.xml to map different forms for >>> each collection. Has any effort been made to allow administrators to >>> do this via web UI? >>> This would greatly reduce the need for system-admins to touch DSpace >>> installation and should be added to future feature requests. >> >> This sounds like a good thing. It would automate a very tedious >> process that uses information which is much more accessible to the >> machine than to the human. It's possible to get the database out of >> sync. with the form designs, but then it was always possible to get >> the >> mapping element out of sync. with the actual form designs too, and >> (either way) it's not too hard to build a periodic check if this >> becomes a serious issue. >> >> Would you submit a feature-request tracker item on SourceForge? >> >> I think that this should be an ordinary editable attribute of the >> collection, so that the collection's admin.s can do it without >> bothering/waiting for the site admin.s. > > +1! > > That sounds like a great idea to me, too.. at the moment, repository > admins can edit their metadata registries, bitstream format > registries, etc. but still have to wait for me when they want to map > a collection to a new form in input-forms.xml (which in itself is > tedious to maintain, as Mark points out). > > Even just getting the mapping in would be great, but I'd also love > an 'Edit Input Forms' page with a similar layout and function to the > Metadata Registry page, ie. Type the name of your form element, > choose the input type (text,combo,checkbox, etc) from a dropdown > list, set required yes/no, assign controlled vocabs if necessary..
This would make sense if Input Forms / Configurable Submission had a number of pre-existing "stock" steps and forms that made sense for individual collections/communities. However, the tendency is to need development of these forms to introduce new stages/steps. So this would be good from a configuration standpoint, but as soon as the user wants something that stretches beyond that, it will return to being a development task. While I would think it helpful to have this configurable on a collection by collection basis, if we are to learn from the 2.0 work, configuring which collection (or in DSpace 2.0 "Entity") has which steps (and forms) would be a standalone "Service" with its own data model and persistence. The Data Model would be used to both manipulate the submission workflow and its steps as well as the source for rendering the interface. Thus it would borrow heavily from the existing Data Model, but the persistence of that Data Model would be up to a storage layer implementation. Mark ~~~~~~~~~~~~~ Mark R. Diggory http://purl.org/net/mdiggory/homepage ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
