5

I have a fairly straightforward and common use case. A panel, in which resides a repeat control. The repeat control gets its content from a view lookup by key. Below that repeat control is another panel. This panel has a data binding to a new notesdocument. The panel has a couple of fields on it for the new document and a submit button.

It all works, however after submit (presumably in the "postSaveDocument()" event) I want to call back up to the repeat control and have it re-perform its lookup and refresh its content.

I'm looking to understand syntactically, how I can reference the repeat control and its properties and methods from elsewhere on the document -- and secondarily (though I can look this up once I get the first part figured out) what the refresh() method would be for that that repeat control.

Ideally, I think its something like: xp:page.repeatcontrolname.refresh() -- though I know that isn't right.

I'm sure once I see an example, it will apply to a myriad of other things.

Update :

I discovered that the repeated elements were actually refreshing but I wasn't seeing a new entry added to the list. The reason, ultimately, turned out to be that to add another entry to the repeat list I needed a new "control" -- but I'd checked that box (on the repeat control) that said "Create Controls at Page Creation". It was preventing my XPage from creating another entry for the new document to display!

Declan Lynch
  • 3,345
  • 17
  • 36
Andrew Pollack
  • 140
  • 1
  • 11

3 Answers3

7

This article explains the syntax for doing what you describe:
http://avatar.red-pill.mobi/tim/blog.nsf/d6plinks/TTRY-84B6VP

Knut Herrmann
  • 30,880
  • 4
  • 31
  • 67
Tim Tripcony
  • 8,056
  • 1
  • 23
  • 34
  • Thanks, Tim. I'll check it out. These both look like articles I should read in any case. – Andrew Pollack Mar 01 '12 at 20:13
  • I'm about 99% sure this would do what I want, if I can get it working. It took me about an hour to find where to put that event, and I dropped the code in: ` XSP.partialRefreshGet("#{id:view:_id1:ExistingDevicesList}"); ` and....all I get is a dialog that says: "An error occurred while updating some of the page. _c9 is undefined" I'll keep looking. – Andrew Pollack Mar 01 '12 at 22:24
  • 1
    that is client side JS so make sure you have it in the correct place and the ID should just be the ID of the repeat control so 'XSP.partialRefreshGet("#{id:ExistingDevicesList}");' the #{id:xyz} gets translated at run time to the correct on-page ID of the control – Declan Lynch Mar 01 '12 at 22:30
  • Yeah, I think Tim's client side approach makes some sense, because the refresh needs to happen AFTER the new document has been saved. I know I could make it happen by just doing a full page re-load, and frankly I'm tempted to go that way -- but I think there must be a better way to do it. – Andrew Pollack Mar 01 '12 at 22:35
  • 1
    The #{id:someComponentId} syntax tells the renderer to translate the value into the client-side ID. So instead of XSP.partialRefreshGet("#{id:view:_id1:ExistingDevicesList}"), it should just be XSP.partialRefreshGet("#{id:ExistingDevicesList}")... at render time, the JS that will be emitted will be XSP.partialRefreshGet("view:_id1:ExistingDevicesList"), if "view:_id1:ExistingDevicesList" is the client ID of the "ExistingDevicesList" component... hope that makes sense. – Tim Tripcony Mar 01 '12 at 23:24
  • Tim, that makes sense -- I tried it again to make sure, and I'm definitely doing that. All I get back is "_c9 is undefinied" I may be targeting the wrong component, or using it wrong here. ExistingDevicesList is a repeat control but it isn't being filled in by ajax calls, so I'm not sure if the refresh is the right way to go. I'll keep playing. – Andrew Pollack Mar 02 '12 at 00:27
  • AGH! So, I was doing the right thing without all this work for the last 5 or 6 hours. BUT! In my testing I'd removed some fields. Well, "remnants" of code including the definition for another data binding were still SITTING THERE in the source view. I removed them, and now my xpage is rendering exactly the way I wanted it to all along using the "partialrefresh" and selecting the parent panel that contains both the repeat control and the new document fields. The only other thing I had to do was force a view.refresh() before the lookup to get the ids. Thanks all for your help. – Andrew Pollack Mar 02 '12 at 00:45
  • **FOLLOW UP** The problem may also have been in selecting the "Create Controls at Page Creation" on the repeat. That clearly does NOT do what I thought it did, and DOES cause the controls to ...well, be created only once at page creation -- leaving no room for another one when a new document was added. KILL. ME. NOW. – Andrew Pollack Mar 02 '12 at 00:50
  • Yes the "Create Controls at Page Creation" should be followed by (and never again) – Toby Samples Mar 02 '12 at 03:46
  • Toby, you've hit the nail exactly on the head. It's written as if it is a positive thing, but in fact it's a limiting option. If not as you say, it should be "Create Controls Only at Page Creation" – Andrew Pollack Mar 02 '12 at 14:06
  • xmage url not working, found here: http://avatar.red-pill.mobi/tim/blog.nsf/d6plinks/TTRY-84B6VP – Frantisek Kossuth Mar 18 '16 at 09:44
5

I have a feeling that this one captures the actual use case.

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Create_and_display_responses

The key setting that people tend to miss is "ignoreRequestParams".

1

Andrew,

The 'XSP.PartialRefreshGet' call was broken in Domino release 8.5.3 which results in the '_c9 is undefined' error.

Have a look at the article posted by Tommy Valand:
http://dontpanic82.blogspot.com.au/2012/03/patch-for-bug-in-xsppartialrefreshget.html

Basically to work around the problem a second argument is required to be passed to the call, for example:

XSP.partialRefreshGet("#{id:ExistingDevicesList}", "")