I keep feeling like I am forgetting something obvious, but if I want to make a link hotspot that uses ?OpenForm to compose the document and then sets the subject field to a value, is there some standarde logic such as
or something like that? If not, would it be best to do this with JavaScript or some other way. I know I can just create the field and set the value, but then if the user wants to leave, the empty document with that field is left to be cleaned up.
and then using the DocumentContext to retrieve the values.
I think that will that work, although I’m not sure about feeding those values back to the new document. You can of course create a document and then OpenDocument rather than OpenForm but that means that the document will be saved at least once by the server even if the user decides to abandon changes. I suppose a clean-up agent can take care of WIP documents.
Subject: RE: Is there a way to set fields as part of URL when composing from the web?
I am actually initiating all this through an agent, so I have the DocumentContext and all. The problem is that I want to fill in a field on the form without actually creating the backend. It is the equivalent of a mailto: URL that allows you to specify the subject, which is use on my website quite a bit with a link such as Send Feedback. My guess is that if I really want to do this, I have to use JavaScript and first call the ?OpenForm and then set the field value, rather than just use a URL. It seems a shame.
Subject: RE: Is there a way to set fields as part of URL when composing from the web?
How complex is the target form? Would it be practical to print it from your agent with the appropriate values inserted in the HTML? (That wouldn’t be an option if, say, the form was swimming in hide-whens that are affected by the passed values or the groups/roles that the user belongs to.) You could grab an exemplar on schedule, tear it into print-before and print-after parts, then send the user a version of the form (with the appropriate graphics, actions, and so forth – it’s the actions and their offsets that force grabbing the form on schedule) with the fields filled in. If the form is a very simple one, you could create a version using the ?CreateDocument action URL, which just leaves the branding (graphics and CSS) to reconcile with the target.
Subject: RE: Is there a way to set fields as part of URL when composing from the web?
Again, it would be a good idea, but I need this to work with a form (actually, one of any number of unknown forms) about which I know virtually nothing except the name of the form and the field to which the value should be set. It is the equivalent, essentially, of
@Command([Compose]; “”; “TheForm”);
@Command([EditGoToField]; “Subject”);
@Command([EditInsertText]; “TheText”);
Could you do this with JavaScript with something like the following (bearing in mind that I don’t know JavaScript almost at all but am making this up from snippets I have seen elsewhere)?
… but it requires opening a new window/tab. You could open the form into a frame or iframe, but if you have no control over (and little knowledge of) the target form, your code could easily be defeated by unframing code (common on commercial sites) or by the form’s autoframe settings (common on Domino web sites – unfortunately).
Subject: RE: Is there a way to set fields as part of URL when composing from the web?
Actually, in this context, opening a new window is fine. The autoframing issue could still be an issue, but it also is not my problem. So, I think the code you suggest might be just fine. Thanks!
I’m sorry to be so cryptic, but this is for a new, optional feature in a product, and I want to support it without mandating any design changes for the form. That still leaves it in the hands of the people who will use the feature to determine whether a particular form will work. I just can’t mandate making specific changes to the form such as CGI variables.
Subject: RE: Is there a way to set fields as part of URL when composing from the web?
I figured as much – that’s why I pointed out the potential pitfalls with framing. You could add JS to look for newWin.document.frames first, then to look through the frames for the named element if it finds a frames collection. Load times could also be an issue, since the document(s) you are loading might not be available right away – putting the search code into a function and calling it with setInterval() and a short delay should clear that up.