Problem Editing & Saving Existing Document on the Web

HCL Domino Domino Forum
1

I am having a problem editing and saving an existing document from the web.

If a user clicks an Edit hotspot (which just contains @Command([EditDocument]), and then clicks another hotspot to approve a document, everything is fine, however, if I try to have the approval hotspot place the document into edit mode AND approve the document, updates are not made to appropriate fields and the document is not saved.

Here is the code I have in the onClick event of the hotspot:

var frm = document.forms[0];

url=location.href;

url=url.replace(“Open”,“Edit”);

window.location.href=url;

frm.dspStatus.value = “Approved”;

frm.Change.value = “Approved”;

change=location.href;

change=change.replace(“Edit”,“Save”);

window.location.href=change;

If I remove the last part (from change= to change;), I can see that the document is placed into edit mode, and that the fields are visually updated. If I place an alert to display change after the replace line, the correct url is displayed, it just doesn’t update the window.location.href. If I set window.location.href=“http://…” and the whole url including savedocument, I do receive the message “form processed”, but the fields have not updated, although the document properties indicates that it has been updated.

If I replace the whole savedocument portion with just frm.submit(), I receive the error message “Invalid syntax” on the frm.submit() line.

If I use the first part of the code to set the window.location.href to include editdocument, and then programmatically click a button using frm.CallDeanApproveAgent.click(), and use formula language in the button of @SetField, again, I can see the fields visually set, however, the minute I introduct @Command([FileSave]), I receive the message “@Function is not valid in this context”.

I understand from this forum that editdocument is done through a POST, while submission is usually done through a GET, so I have entered method=“POST” in the Other field of the HTML Tags tab of the hotspot properties in both of the buttons, but with the same results.

I have tried this in both IE 6 and Firefox Mozilla, with the same results.

This shouldn’t be rocket science, and yet it has me stumped. I do not want to open the document automatically in edit mode, as a) not all users have edit access to the documents (I do with the IDs I have been using to perform the update and save), and I want to preserve the look of the document in read mode should the user want to print it.

Any assistance would be greatly appreciated!

2

Subject: Problem Editing & Saving Existing Document on the Web

3

Subject: RE: Problem Editing & Saving Existing Document on the Web

I thought that if the url contained the unid of the document, then I would be assured that I have the same document - no?

I can’t seem to use the @Command([FileSave]). Even if I just call a button from the hotspot and the button has the whole thing in formula language, (@Command([EditDocument]); @Setfield… , I’m perfectly fine until I enter @Command([FileSave]). Then, I receive the “@Function is not valid in this context”. This is why I’m totally stumped. What I’m trying to do isn’t hard, but for some reason, I’m not able to do it.

I do have a $$Return field, which just contains a url, but even if I remove that I receive the same error message.

4

Subject: RE: Problem Editing & Saving Existing Document on the Web

5

Subject: RE: Problem Editing & Saving Existing Document on the Web

Thanks so much for the suggestions. I have tried the agent (and just tried it again in various ways), and still no joy.

I’ve also tried adding the save to a LotusScript agent that sends email (which is also generated by the code) and which executes perfectly, but again, no joy with the saving of the document.

The bizarre thing too is that there is no error generated. When I initially asked IBM support about this, they said that the system sometimes just ignores that which it can’t execute and just continues with the portion of the code which it is ok with.

Such a simple thing, and yet it just doesn’t want to work. If you think of anything else, please do let me know.

6

Subject: RE: Problem Editing & Saving Existing Document on the Web

By chance is there a saveoptions field on the document?

I normally do this type of thing via lotscript and webquerysave agents, it always works as long as there is no saveoptions field on the document.

7

Subject: RE: Problem Editing & Saving Existing Document on the Web

Nope - no saveoptions field. The bizarre thing is that it saves everything beautifully, if I put the document in edit mode first. But it’s when I try to put the document in edit mode AND then make changes to the document all at one go, that the problems arise.

I have tried the agents route, and again, the code executes everything else, including sending mail, but just will not save changes to the fields on the document.

8

Subject: RE: Problem Editing & Saving Existing Document on the Web

9

Subject: RE: Problem Editing & Saving Existing Document on the Web

Maybe I’m misunderstanding, Willy.

If I don’t want the document to automatically be placed into edit mode, but want it done through a button click, how would I use the onLoad to facilitate this? Are you saying that I would use the button click to do a reload of the document, and, would that cause the onLoad to re-activate again?

10

Subject: RE: Problem Editing & Saving Existing Document on the Web

The button click would put the document into edit mode so that you can make “sticky” changes. That’s about all you can do from “read mode”* in the browser – unless you call an agent (as Mr. Lorenzo pointed out several layers back).

You can use the onload event of the editable document to do your additional client-side processing. The problem then becomes one of determining when the additional onload code should fire. If you were to use @Commend([EditDocument]) or the JS option you have been using thus far (simply replacing Open with Edit in the URL), you won’t be able to do that. However, if you add an additional parameter to the query string, like this:

location.href = location.href.replace(/OpenDocument/i, “EditDocument”) + “&action=ShortActionName”;

then you can look at the URL in the onload code to see whether or not to run the action process:

var re = /ShortActionName/i;

if (re.Test(location.search) {…}

*There is no “mode” as such in the web browser. The “read” version of the document and the active form are two different web pages as far as the browser is concerned.

11

Subject: RE: Problem Editing & Saving Existing Document on the Web

Excellent! I’ll give that a go.

Yup, I read what Willy had indicated, and believe me, I tried, but the document just would not update. Ever have one of those apps that just gives you no end of grief?!! This one has fought me every step of the way.

Anyhow, I didn’t know you could use &action in that particular way, but it does make sense.

Thanks so much for the advice!

12

Subject: RE: Problem Editing & Saving Existing Document on the Web

There’s no particular meaning to “&action=” – it’s just somethng that’s very unlikely to be a field name. Domino will ignore arbitrary query string parameters unless you use them in server-side code yourself, but will not hide them or redirect, so they’re available to your browser-side code as well. (Adding a random arbitrary query string param has become the standard way to beat IE7’s aggressive cache.)

13

Subject: RE: Problem Editing & Saving Existing Document on the Web

14

Subject: RE: Problem Editing & Saving Existing Document on the Web

That is excellent and it works perfectly!

And the explanation about the EditDocument really helped me understand where I was encountering problems.

Many thanks Willy, to both you and Stan, for helping me understand and work around the problem I was having!