Flow of control (Manakin)

(Ryan is working out some issues here. Once they are somewhat coherent, they should be moved to the DSpace wiki.)

Understanding various issues in Manakin's data flow.

Passing parameters
Parameters can be passed between Manakin pages in multiple ways.

In the Administrative aspect, a call to /admin/item?itemID=123:


 * 1) the sitemap passes to a javascript function (startEditItem in administrative.js)
 * 2) the javascript function does a cocoon.request.get("itemID"); to get the parameter value, does the edit function seprately, and finally redirects to the normal item view page.

In the Administrative aspect, with a call to /admin/item, and POSTing a continuation:
 * 1) This occurs when the request came from an administrative page, so a lot of data is already populated (and stored in the continuation)
 * 2) The sitemap passes this off to FlowItemUtils.java

In the ArtifactBrowser aspect, a call to /handle/123/4567:


 * 1) the sitemap calls various matchers (HandleAuthorizedMatcher, HandleTypeMatcher) and eventually calls ItemViewer
 * 2) each of these calls calls HandleUtil.obtainHandle, which
 * 3) *the first time it is called for a given Request, calls request.getSitemapURI; and parses the URI
 * 4) *on subsequent calls, it retrieves the existing handle from the Request

In the ArtifactBrowser aspect, a call to /feedback:


 * 1) the sitemap explicitly sends parameters to the FeedbackForm (but it is unclear where these values come from)
 * 2) these parameters are then available in the parameters field of AbstractDSpaceTransformer (parent of FeedbackForm)

Note: sometimes, an objectModel is passed around, and sometimes it is inherited from AbstractDSpaceTransformer. Why?

Formatting of the /feedback page (especially textarea width)

 * 1) the page template is constructed by the ArtifactBrowswer aspect (FeedbackForm.java) which subclasses AbstractDSpaceTransformer
 * 2) *the page contains a division and a form within the division
 * 3) *the form itself is an instance of a List (which is subclass of AbstractWingElement, and not itself a java.utils.List), with a type field that indicates it will be rendered as a form.
 * 4) *the textArea for comments is added to the form as an item within the list maintained by the form;
 * 5) **there exist constructors for both list items and textAreas that accept a string argument for rending hints. Not sure if these could have been used to set the width and height of the textArea, however the width is nowhere set within the aspect, so the generated DRI is passed through to cocoon.
 * 6) because text area height and width are required attributes, there are templates in dri2xhtml/structural.xsl (textAreaCols and textAreaRows) that provide defaults for these
 * 7) *these can be overwritten in the DRI document but no such values are provided in this case
 * 8) there is a template for textArea elements in Dryad.xsl which calls the textAreaCols and textAreaRows to get the defaults defined in structural.xsl
 * 9) since testAreaCols was generating a default of 20, Dryad.xsl has been adjusted to default to 60 width.
 * 10) *there is another textArea for user comments that is directly generated earlier in the Dryad.xsl, but that appears in different contexts (and with a height of 15 lines)