LICENSE EXPIRED
buy Balsamiq Wireframes now to continue editing your mockups.

Terminology Used in the MOCKUP --

Action -The bean identifier i.e.action_id of the actual action class as configured in the SPRING XML file like--

 <bean id="{action.id}" scope="prototype">     <constructor-arg type="java.lang.String" value="{action.id}"/>
     <property name="processingAction" ref="{action.api.id}"/>
     <property name="requiresUI" value="{true/false}"/>
 </bean>

Step-Container of Actions mapped to outcomes

Outcome-Numerical code which will map one step to the next step.

Process-Container of Steps in a certain order

For example- Analogous XML can be specified as---

    <!--Standard workflow step-->
   <workflow start="traditional" id="default">
       <step id="selectcollectionstep" role="submitter" userSelectionMethod="submit">
           <outcomes>
               <step status="0">editstep</step>
           </outcomes>
           <actions>
               <action id="selectcollection"/>           </actions>
       </step>       
   </workflow> 

In the above screen the process belongs to the level where the user is currently present.So,it can be community-specific or collection-specific or whole intance-specific.


                             

The order of steps to be taken will be determined in the order in which they are created in the above screen.


  • No labels

4 Comments

  1. Jim Ottaviani

    Hi Gaurav:

    Could you please clarify whether the processes you're outlining above are for

    • creating a new submission UI, to be done by a repository/collection manager, or
    • creating a back-end workflow for an administrator to check a submission after it is completed by an end-user.

    Given the use of the word "submission" I suspect it's the former, but right now I'm having difficulty making the leap from the abstract scheme shown above to how a repository manager would build something that would create/modify a submission form (as currently happens via editing "input-forms.xml").

    I may be missing something obvious here, of course. If so, my apologies!

    Jim

    1. Gaurav Kejriwal

      Dear Jim,

      Thanks for the comment.Actually the UI is meant for creating a new submission-workflow.So like I had mentioned in the Gsoc mailing list I am currently working to make the submission-workflow configurable via the admin UI.So,there will be a XML file which will replace the item-submission.xml and will contain the configurations for discrete actions.

      And the admin UI will allow the repo/collection manager to add add steps(which will contain actions) to a particular workflow.

      So this is not related to modifying a submission-form but it is related to modifying/configuring a submission-workflow and as I had mailed in the mailing list,I started doing this part of the project first .

  2. Jim Ottaviani

    Hi Guarav:

    I just saw your note on the mailing list, and here's my initial feedback. Could you provide a few concrete examples of how the UI you propose will work in practice? Right now, the level of abstraction is too high for me to see how using this would play out for a repository manager. Here are my suggestions for a few specific use cases...

    (1) Creation from scratch: A repository manager has just created a new DSpace instance and wants to set up the default submission process, which will have the following steps, in this order:

      Choose Collection
      Accept License
      Describe Item
      Upload Bitstream(s)
      Verify and Complete
     
    (2) Cloning/re-ordering: A few years later the repository manager wants to set up a custom submission process for a specific collection, and all they want to do is change the default (described above) by moving the "Accept License" step to the very end.

    (3) Adding/modifying: Minutes after finishing (2) above, the repository manager realizes they wanted to offer a Creative Commons option, so they add that as a step to the submission process, just before the "Accept License" step.

    Those seem to me the most likely scenarios repository managers will encounter.

    Thanks,

    Jim

    1. Gaurav Kejriwal

      Hi Jim

      Thanks for your comment.I am giving below a brief detail to explain the use-case you've given.

      One important thing to note that the process and steps being created in the above UI will just be a container of actions which will come from a Spring Config file.

      1.To create a default submission-process the repo manager will have to go to the "Select/Edit Process" option under context menu from the instance's home-page.Important thing to note here is that the new Process will be created at the level from which the admin gets into the "Select/Edit Process".

      So,he will add a new process named("traditional") using Screen1 above.

      2.Similarly they will create the new steps like a.Select Collection b.License Step etc.by going to screens which appear on clicking the hyperlink on "traditional".

      3.Regarding the case related to moving "Accept License" step to the end currently the UI supports it.

      We can do this by mapping the outcome "0 "of the 2nd last step (i.e.Verify) in this case to "License Step".(This can be done by the EditOutcome screen)

      "0" corresponds to the default behavior i.e. in case all actions in VerifyStep perform normally they will return "0" and "License Step" will be called once last action of "VerifyStep" is finished.

      4.To add a new step before "LicenseStep" we will create a new "CreativeCommons" Step via normal process of creating step and map outcome of the step which will be before it to "CreativeCommons"

      So,the actual action for each step will be in Spring config file and we can combine any of those actions any number of times via the UI to generate a step.

      Please tell in case I can give any clarification.If you may like,I will upload snapshots of the above use-case .

      Gaurav

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.