CODEWITHSUNDEEP
xpagesxpinc
user1409217
user1409217

Reputation: 412

Repeated fileDownload control each displays the same list of files?

I'm creating a student assignment submission application using xpages (8.5.3 FP3 UP1). The details are:

  1. Student can do any number of submission. For each submission, a unique SubmitID will be created. For now,

    a. The Form (Submit) - 2 fields only (SubmitID, SoftCopy-RTF type)

    b. The View (Submit) - 2 column only (SubmitID, AttachmentNames)

    c. Examples of SubmitID are: submit1, submit2

  2. For each submission, student must select what course/subject that submission is for (eg: Maths, Physics etc). Therefore I've already created another form for the teacher to create the list of subject

    a. The Form (Subject) - 1 field only (SubjectName)

    b. The View (Subject) - 1 column only (SubjectName)

    c. Say for now 2 subject has been created - Maths & Physics

  3. I've created 2 xpage:

    a. Submit.xsp - to create new submission (using form - Submit)

    b. SubmitView.xsp - to display the list of submission (using view - Submit)

  4. For Submit.xsp, here's where my problem begins:

    a. The controls in here are as follows: SubmitID EditBox, Repeat Control(inside is a CheckBox, a fileUpload, and a fileDownload)

    b. The repeat is based on the list of subject available. The CheckBox title will be each of the SubjectName. In the OnChange event of the fileUpload control, each time after a file is browsed, the checkbox will get checked and this worked.

    c. The fileUpload should only update the accompanying fileDownload but instead the attachment that I just uploaded is reflected to every other fileDownload control. I'm doing full refresh on the fileUpload OnChange because that's the only way for the fileDownload to be updated. What is wrong here and what should I do to get the result that I wanted? Saving the document and opening it later in both read-only or edit mode is fine although each subject still display the same list of uploaded files. Both fileUpload and fileDownload are binded to the SoftCopy field.

Upvotes: 0

Views: 373

Answers (1)

Tim Tripcony
Tim Tripcony

Reputation: 8086

Unless I'm not correctly interpreting your description, you're binding multiple upload / download controls to the same item ("SoftCopy"). Because these controls are always bound to an item, not to each other, a download control will show any attachments stored within the source item, regardless of how they got there. To limit display of attachments in a download control to those sent via a specific upload control, they must be stored in an item unique to that pair.

For example, if each pair were bound to a subject-specific item, such as "SoftCopy_Maths" or "SoftCopy_Physics", then each download would only display attachments stored within that specific item. You don't know what subjects will be defined, so you can't define these fields on the form, but that's okay... you don't need to. NSF has no schema, so a field need not be defined on a form for a control to be bound to it; the item will be created when the document is saved, even if the form does not define it. Strictly speaking, even the form itself need not exist.

We typically bind controls to items using dot syntax, e.g. #{currentDocument.SoftCopy}, but array syntax is equally valid, e.g. #{currentDocument["SoftCopy"]}. So if you wrap these controls in something that establishes the dynamic item name as a variable or property, you can use array syntax to target that dynamic item. Two of the best ways to do this are data contexts and custom controls.

For instance, you could surround the contents of the repeat in a panel, and define a panel-specific dataContext that associates the variable attachmentItemName with the concatenation of the item name prefix and the specific subject. Your upload and download controls can then be bound to #{currentDocument[attachmentItemName]}.

Alternatively, you can move the same content to a custom control that accepts the data source and item name as properties, in which case your value binding might look like #{compositeData.dataSource[compositeData.attachmentItemName]}.

Apart from very minor differences in runtime performance, either approach is equally valid.

Upvotes: 3

Related Questions