Hi all…I’ve got an agent that is called from the web. What it does is basically on the back end create a document using a form (lets call it form A). This form has one field on it, a rich text field and my agent compiles a ton of html using data from a group of docs in the db and then fills this rich text field with all this pretty html…
The html is compiled to present essentially a spreadsheet look of a group of records for the user. They want to be able to edit it on the web like a spreadsheet and then have all the updated values saveed back to the original docs (the ones that are all compiled in real time to create this rich text field document)At the end it uses a print statement to open this spreadsheet form in their browser. The html contains inputs for fields etc. My users can then change these things on the web, but my question is, how do I get it to submit? I just put a save button into the html with a document.forms[0].submit in it, but notes doesn’t know WHAT its submitting. What I’d like to do is to update all the html in that rich text field with the changes made to the fields by the user on the web. After that, I’m thinking I’ll have some other agent that might run on the webquerysave (if that even works on forms w/ treat contents as html) that will parse that rich text field and then write the updated values to the original docs. Anyway, does anyone know how I can get this document (created w/ Form A) saved?
Thanks!
Subject: It sounds like a very difficult way to solve your problem
Why are you doing this in this particular way? Why not use Notes tables and regular fields? What is the business need which mandates this whole HTML approach? (Not meaning to be argumentative, but I want to understand before taking time to help with a convoluted solution if there is a simpler solution)
Subject: RE: It sounds like a very difficult way to solve your problem
Hi Ben…Thanks for taking the time to answer. Your questions regarding the design are good ones, in fact they are the same ones I posed to the “designers”. I recommended strongly that we not take this approach. Think of it this way, a notesview shows people summaries of records, but what they want is the ability to edit each column in that view…a “spreadsheet” with totals at the bottom etc. Each record represents a project for a particular facility. So, each user comes to the website, selects their facility and then we need to create this spreadsheet view (which can have hundreds of docs/records) in real time. When they make their changes, I will need to run some code on the backend to update any docs changed for that facility. I have no way of knowing how many records will be in a particular facility so there is no way to hard wire a notes form with tables and regular fields. Basically the whole thing is presented as html from one big rich text field. Anyway, the only piece missing is why won’t the thing post data back to the document!.. One approach I’m going to try today is to use JS to stuff the innerhtml from the RTF into another RTF and then do a submit. Then I can pick up the new rtf on the backend, parse for changes and write to the original docs…might work…but I wish there was a simpler way.
Subject: RE: It sounds like a very difficult way to solve your problem
There are a lot of simpler ways to do this. You could use IFRAMEs to present directly-editable versions of the individual documents inside table rows. You could use JS to concatenate the individual field edits into a single ordered array that you could return into a document for WebQuerySave processing.
Try this: make a form. Put an embedded view on it that restricts to category according to the current user’s facility. In that view, use pass-thru HTML to present an tag around some piece of data. Use any technique you like for unique naming the INPUT item, but I’d suggest the NoteID of the document. Call it something like “EditColumn”+@NoteID.
Then, on the form, write some onSubmit javascript to consolidate all the names of those INPUTs into one field’s data, with some useful known separator, and make sure that field is on your form. Then do the same thing with the data inside said fields, in the same order, again making sure that this consolidation field is on your form.
The Domino HTTP processor with disregard the fields in the incoming HTML that aren’t on your form, but no matter. You’ll have all the data you need in the two fields that you DID define. Then you can use a WebQuerySave agent to pick out those values, loop through them, find the back-end documents and update data if need be. It would be a fairly trivial piece of code.
With a bit of forethought and some good Javascript skills, this should take only a few hours to make a prototype of. Then you can take it back to your “designers” and demand a refund. 