I have a curious problem… i have validation that runs when a document is to be saved (there is a filesave call in the Submit button). The validation works great when there is a new document - the doc is not submitted if validation fails. However, when I edit an existing document, the “return false” command does not stop the doc from submitting. In the code below, the “no good” alert pops up to signal that it failed validation (as I expected it to) but the doc is submitted. The “doSubmit” script contains my validation and seems to be working fine. Any ideas?
if ( doSubmit() )
{
alert ("Passed validation");
return true;
}
else
{
return false;
alert (“no good”);
}
Subject: javascript submit problem
I bet you are linking a .js file and not using the JS Header. How do I figure that? Your validation happens all nice and cheery when the URL is to a Form, but does nothing with a Document – which appears to be one folder “down” from the database root. To avoid that, create a full URL to the .js file:
“<script language=\javascript" type="tex/javascript" src=\http://” + @GetHTTPHeader(“Host”) + “/” + @WebDbName + “/myfile.js">”
Using an absolute URL means never having to say you’re sorry.
Subject: RE: javascript submit problem
Unless, of course, you’re sorry that you misspelled the MIME type and your users are on a Mozilla/Gecko-based browser. It should have been “text/javascript”.
Subject: javascript submit problem
Not really answering your specific question, but…
what I do is put the document.submit() function inside my javascript and call the javascript wrapper for it from the button. I never use the FileSave FileCloseWindow commands when submitting web pages.
i.e.
on form, save button, onclick=submitThisDoc()
inside submitThisDoc()
…
if (validThisDoc()) {
document.submit();
}
…
Subject: RE: javascript submit problem
There’s no reason to avoid @Function buttons – they can provide a good deal more functionality than an HTML or JavaScript can. F’rinstance – what’s the JavaScript command to save changes and continue editing? @Command([FileSave]) does that, and you can even use different validation for different submit actions if you know how the @Formula stuff works on the web. Validation for “Save and Continue” should not be as rigorous as it is for “Submit” – check data types to avoid 500 errors, but don’t require that everything be complete. You can always clean up abandoned documents with an agent. You can also hold off running WebQuerySave agents for documents that aren’t complete. (Consider, for instance, multiple file uploads to a single document. How many upload controls do you want to add to a form?)
The general aversion to @Formula buttons on the web seems to arise out of fear and misunderstanding. Take some time to look at what _doClick() does. Make use of the fact that one JavaScript function can check the arguments passed to another (particularly arguments[1] of _doClick(), which is the calling object). I’m not suggesting that you invest in thousand-line formulas – just that you leverage what Domino can do for you that you can’t duplicate with JS or HTML.
Subject: thanks for the advice
Stan,
I’ll be sure to take a closer look at what you are describing.
You make a good point about Quick Saving not requiring heavy validation. Definitely not a design consideration I had thought too much about.
I definitely tend to call WebQuerySave way too often when I know it’s not necessary.
Personally, I have an aversion to @function methods simply because I detest the syntax. Having to escape all the quotes and other special characters drives me crazy. I appreciate the speed and utility of @functions in the right places, but man, I just cringe every time I look at the code.
Granted, aesthetics shouldn’t be the sole reason to pick one design method over another.
Again, thanks for the advice.
Subject: RE: thanks for the advice
Believe me, I “get” the syntax issue. Writing formulas that wrtie JavaScript that writes HTML is oh so much fun…