[
https://jira.duraspace.org/browse/DS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25672#comment-25672
]
Nestor Oviedo commented on DS-1127:
-----------------------------------
The bug Robin refers to it's not a bug introduced by this patch. That is the
normal behaviour of the org.dspace.submit.step.DescribeStep class.
In step 3 of that class's doProcessing() method, if either Next, Previous,
Cancel or ProgressBar button is pressed then the validation for required fields
is done.
Before this patch, when you were in page 2 and wanted to go back to page 1 to
modify something, you couldn't do it if page 2 was imcomplete. Maybe this patch
exposed the current behaviour as a new bug, because now you shouldn't have to
complete a field if it has no sense with the type you want to change to.
Here in SeDiCI we've been thinking in modify the mentioned Step 3 in order to,
when:
a. Previous button is pressed
b. ProgressBar button is pressed AND the new step is previous to this one
c. Next button is pressed
d. ProgressBar button is pressed AND the new step is next to this one
On (a) or (b) -> omit the validation.
On (c) -> do the validation as it is done currently
On (d) -> do the validation, but considering all the metadata defined in the
current page and all the previous pages
Our idea is to disable the validation when the user goes back in the submission
progress, and to validate all the needed pages when the user jumps to a new
submission step. In case of some validation error, the user should be
redirected to the first page with an error.
That way we ensure we always validate all metadata fields before to advance on
the submission process.
Anyway, we think this issue requires some extra careful analysis.
We would love to hear your thoughts on this, because this is something we need
to solve in our DSpace installation.
> Submission improvements: document type-based submission
> -------------------------------------------------------
>
> Key: DS-1127
> URL: https://jira.duraspace.org/browse/DS-1127
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API, XMLUI
> Affects Versions: 1.8.0, 1.8.1, 1.8.2
> Reporter: Nestor Oviedo
> Assignee: Robin Taylor
> Priority: Major
> Labels: has-patch
> Attachments: type-based-submission-classes.zip,
> type-based-submission.patch
>
>
> Document type-based submission
> As outlined in
> https://wiki.duraspace.org/display/DSPACE/Document+Type+Based+Submission,
> many repositories deal with several document types and the only approach
> DSpace has to offer so far is a collection based form definition.
> We found the following initiatives: https://jira.duraspace.org/browse/DS-464
> and https://wiki.duraspace.org/display/DSPACE/Document+Type+Based+Submission
> , but they are very old and it is very hard to integrate one of them in our
> 1.8.0 DSpace. Along with this problematic integration we also need some other
> features to the submission process, which made the integration yet more
> complicated.
> These initiatives propose to define a type-based form and/or pages, but we
> thought this would lead to a very complicated and redundant form definition,
> provided most document types share a lot of common fields. To avoid this
> replication, we propose to have a type-based field definition in the form
> configuration (input-forms.xml). That is, defining the forms and pages fields
> in the normal way, and only specify a type-restriction on those fields which
> are specific for some kind of document.
> The following excerpt is an example o a form definition:
> <form name="traditional">
> <page number="1">
> <field>
> <dc-schema>dc</dc-schema>
> <dc-element>type</dc-element>
> <label>Document type</label>
> <!-- other field properties -->
> </field>
> <!-- many others common metadata, like author, title, some
> date, language, etc -->
> </page>
>
> <page number="2">
> <!-- many others common metadata, like abstract, subjects,
> identifiers, etc -->
> <!-- Here we have a field specific for a theses -->
> <field>
> <dc-schema>theses</dc-schema>
> <dc-element>director</dc-element>
> <label>Thesis director</label>
> <type-bind>theses</type-bind>
> </field>
> <!-- many others common metadata, like coverage, some
> institution name, some other date, embargo info, etc -->
> </page>
> </form>
> The visibility of the type-based field depends on the dc.type field's value.
> This requires the dc.type metadata must be fullfilled before the rendering of
> any page with any type-based field.
> This approach allows you to mix fields, even though they are restricted to a
> document type. Also, you can define multiple document types in the
> <type-bind> element, separated with a colon (,). i.e
> <field>
> <dc-schema>dc</dc-schema>
> <dc-element>identifier.isbn</dc-element>
> <label>ISBN</label>
> <type-bind>theses,ebook</type-bind>
> </field>
> Other improvements
> Considering we have now a type-based submission, we need to be able to define
> the same field for different document types, with different attributes. A
> clear example of this in our repository is the ISBN metadata: theses may have
> an ISBN metadata while books must have it. Also, the label and hint of these
> fields could be different. To achieve this we avoided the limitation on field
> duplicity, allowing to define the same field multiple times.
> Another minor improvement proposed here was previously mentioned by Claudia
> Jürgen in https://jira.duraspace.org/browse/DS-334. We agree with Claudia in
> that the visibility and the required attribute are not related directly, so
> we removed that validation. We consider that the mandatory restriction makes
> sense only when the field is visible in a scope. Thus it is completely valid
> to define a visibility scope along with a required attribute.
> Attachments
> Here you can find two attachments: a zip containing the modified classes, and
> another zip containing the diff for all the modified classes (this diff was
> made against the 1.8.0 version).
> We attached diff files for you to have a quick overview of the changes made.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
