Ferdy's Cry For Help
Last week Ferdy Christant mailed me with a "cry for help". He was so desperate that he offered a treat from my Wishlist if I could help. Obviously this got me interested in his problem and I decided to shelve some time for it. I soon found that the more I thought about it the more intrigued I became. In the end I came up with a solution that meant that I both got the book (thanks Ferdy!) and a nice little application that I can now share with you all (hope Ferdy doesn't mind ;o)
The problem was one of URL lengths. If you use the HTTP GET request to submit data to a server you are limited in the amount of data you can send. This limit is down to browsers, OSs and servers to fight it out amongst each other. What you need to start thinking about when you start worrying about the length is using the POST method instead.
Ferdy was using (is this starting to sound like an article?) views with check-boxes to hold the UNIDs of selected documents. A button then sent all the selected UNIDs to the server via the URL. Obviously it doesn't take long to reach the limit (generally about 1024 characters). My first suggestion was that he POST them all to a Java Servlet that could process them. Not possible though as Java wasn't an option in his environment. Then I remembered this little trick and hit upon an idea. The result was a view from which you can POST any number of document selections to the server for any kind of processing necessary. Probably something you have to see to truly understand the benefits of. Anybody interested? I can write a full article about it if so.
On another note, I made a change to the DomBlog and released v1.0.2. If you're interested in keeping up to date with any future changes your best bet is to read the online copy where I will blog all the relevant changes...
Skip to the 
You can subscribe to an individual
Sounds like a great article idea... go for it, Jake!
I have a web app where users can select multiple docs. The issue i hit right away was figuring out a way for users to select a few docs in the view, then do a next/previous or search so they can get more, but still remember the docs they selected previously when they wanted to perform an action on them. I set it up so next/previous ran an agent before going to page that would grab unids and store them in a temporary document. When user was ready to perform final action i would grab that doc and loop through unids and then blow it away. Maybe not the same issue but sounds somewhat similar. Jake you need to make this text field larger.
That would be a very interesting article Jake, i hope you to write it and be able to read it soon !!
I probably will do, thinking about it. In the mean time here's an example. It should make sense...
Good thing youre sharing the technique we discussed. I'm having one little cosmetic problem while implementing it: a two line gap between te form domino generates and the one we define ass pass-thru. I checked the source but there's nothing between the end of the first form and the begin of the new form. This makes my design look really ugly, does someone know a way to control form positioning using CSS or in another way?
Thanks in advance,
Ferdy
Sounds strange Ferdy. What browser's that in??
Jake it's in IE 6. Just try a simple example in notepad: open and close two form tags, put some text between the form tags of both forms, save as html and check it out. There's room between the text of the first form and the second, while I want it to be seamless :(
That's easier than in sounds Ferdy. I'm trying to get used to my new iBook (ealry xmas present ;o)
Will give it a go. Now what's Notepad called? TextEdit I think...
Okay. You're right. There is a gap. Probably normal but you can get round it using CSS:
form {margin:0px;
}
I'm stunned by the user-friendliness of that Mac already ;)
sorry my connection is really unreliable right now so i dont know if my previous post got throught. I wanted to say: Excellent Jake! This is what I call help, it works!
another idea: instead of using a ?createDocument action, you can send your post to a ?OpenAgent url and parse the request_content field of the documentContext...
I would love to read an article about this Jake. Sounds very interesting.
Jerome. Good idea! Not tested it but I can't see a reason it wouldn't work and, hence, make it an even lot simpler solution... nice!
Jerome, sounds even better but I think that will work on all forms but a $$Viewtemplate form. I've tried something similar before, the agent could access the context fields but they were all empty. I hope you can prove me wrong and get it to work on $$Viewtemplate forms as well.
Wahey, glad you've com across to a Mac Jake ;-)
As jerome suggested - I have been using this method for multiple delete and copy to other database agents for a while now - all based on code from codestore naturally.
I really wish I could post a lot of my code/db's but these 'confidentiality clauses' really are a pain :(
Confidentiality clauses shmauses. Do you think this site would exist if I paid any attention to nonsense like that ;o)
What do they expect you to do? Forget everything you eer discovered while you work there!
The way I write about things on here means I try and never give away anything that could damage or threaten the "confidentiality" of a former employer... I hope.
On a slighty different note ... looks like either someones been *hacking* or testing embedded html ... try *reading* the comments on the latest entry in *domlog* ... its *horrorbull* !! ;o)
Damn. Okay, so I need to strip HTML from all fields on the form ;o) Ha ha, very clever...
I think you describe a problem which I came across. I had a generic getKey lotus script function which I made to retrieve values from QUERY_STRING and REQUEST_CONTENT fields. It allows be to pass a parameter which indicated the value of the key to return. I then had to modify this to return multiple values for the likes of checkboxes etc. I also added another function which decoded the HEX values in the URL returning true characters, so I could then email contents off to users without them wandering about the meaning behind %20 etc.
That FORM whitespace had me stumped for ages until I found the margin fix for it a few days ago. Why would there be any margin be default for a page? A form is usually transparent to the user surely?
Can I ask a more basic question? How do you get the checkboxes in the view?
Just display a certain field type in the column?
Patience Ian, patience... all will be revealed!
Ian,
No, you should create HTML in your column that generates a checkbox, they should all have the same name but a different value, preferably the UNID. I can't give you the example code here because HTML gets removed in this comments field. Email me if interested.
I know this is cheating, but have you considered simply using the NoteID instead of the UNID? The NoteID is only 8 chars instead of 32, this giving you four times as many docs that can be processed from a view via standard URL parameters before you hit the 1024 limit (I can get up to 50 docs this way, and I don't allow views longer than that).
That method doesn't have the other advantages of Jake's solution, but it might be easier for some people.
FYI: NoteID isn't unique across replica db's, but it's unique within an individual db. So unless you've got a load-balanced cluster running, it's just as valid as a UNID. If you DO have a load-balanced cluster running, you can afford to hire Jake to write something much cooler!
Looking forward to the article, Jake!
Or... you could use this method and then there is no need for all of that other stuff...
http://www.notestips.com/80256B3A007F2692/1/MGOG58QVCW
Good idea Rob! Hadn't thought of that.
Another reason to use the POST method is from a purist's perspective. Although the W3C are sketchy on their definition of the two methods it's clear that they don't really recommend using GET to *work* with data. Use GET to get stuff and POST to do stuff. There are other reasons too, which I will cover in the article..
Damn it! Must start reading everything you've got on your site soon Mike. Is there anything else on here that you've already done? ;o)
Will probably still write the article though as there are some subtle differences in the way I've done it that may be useful.
I'm working on a similar problem. My users want to update multiple fields from multiple documents at one time. For eg. They want a view like display of documents and have fields on each row which they can modify and submit it for batch update. After lot of trial & error I have now come up with a solution. I'm creating html fields on the fly in WebQueryOpen agent and replacing them into display fields present on the form. I also have hidden fields which accept multiple values on the form corresponding to the html fields that are created on the fly as notes wont accept html fields, so thats a bit of hack.
Initially I was trying to use javascript in view column to create html fields but notes does not recognise them.
I have to display more than 10,000 documents which makes it a bit slow but I'm now allowing users to select documents on one screen from a view (with check boxes) and display those documents with fields on the next screen. It works like a charm.
Ferdy, I've used the post to ?OpenAgent URL in a $$ViewTemplateForm with no problem. Instead of parsing Request_Content, parse out the name of the checkbox field. For example, in my view, my checkbox field is called selectThis. Therefore, in my agent, I can set doc=session.documentcontext, then print or parse doc.selectThis.
Cancel that last post; it was actually parsing the Request_Content, not the field name itself. But it did work from a $$ViewTemplate.
I'd be interested. I've done some embeded forms via views using post methods and java agents, but would be interested in this solution as well.
BTW - completely side tangent - do you plan to/are you set up to have your blog get sent out via RSS feed? LJ now has it set up so that you can add syndicated feeds to your friends list.
I'm sorry, I didnt explain my siuation in detail. I'm not using checkboxes, because I don't think they are pretty. I'm offering my users a HTML view in which they can just click a row and it gets highlighted using CSS. When they click again, it gets the normal color. Now, when the user has selecteded document(s) I process them using the solution Jake and Mike provided. Only difference is that it looks different, in my opinion better but thats for your users to decide. It's a small difference, but more work to get it working not using checkboxes. I do feel stupid now, can anyone explain what request_content is, I thought i knew all about CGI variables :(
Ferdy, I'm w/ you on request_content, very nice on the highlight row option, never thought of that, very elegant, think i'll use it.
Sure would be nice to have the highlight row stuff in the article Jake. Hint, Hint. =)
If Ferdy's kind enough to share it I will add it in...
Jake, of course you can share my higlight technique, it's in the template of iDocuments I've send you. Check out the column formulas in the view and the CSS documents in the administration section. I can't share it otherwise, I'm sorry but this text box is too small and it's hard to post html code. Hint, Hint =)
Ferdy,
When (only a?) post request is sent to an agent, the DocumentContext is a "&" delimited string of FieldName=FieldValue pairs.
I wrote an Collection-like object that walks through the RequestContentParser field with .GetFirst and .GetNext methods. It's at http://www.openntf.org/projects/codebin/codebin.nsf/0/4045c9fdfe73743488256bff0072fa1a
John,
Thank you, an excellent solution for passing values using the URL, but not when youre passing lots of data, or am i wrong?
BAH! You were probably confused because my comment didn't make sense! I apologize. Let me try again:
When you are passing lots of data to a LotusScript agent, you want to use a post method from the browser. If you do this, your agent's LotusScript code can access the field names and values via NotesSession.DocumentContext.Request_Content(0), which is a single string of "FieldName=FieldValue" pairs delimited by ampersands ("&").
To help parse this Request_Content string, I wrote an Collection-like class named RequestContentParser that walks through the Request_Content field using .GetFirst and .GetNext methods. You're welcome to use it if you like. It's at http://www.openntf.org/projects/codebin/codebin.nsf/0/4045c9fdfe73743488256bff0072fa1a
I'm sorry my previous comment was so bungled!
Ah! That does make sense. I wasn't aware of a field like that. Btw, I love that openntf code bin....good stuff!
I have written agents that use REQUEST_CONTENT to retrieve data from a post.
It's a really nice way to process data (regardless size). The drawback is that you manually have to handle sting encoding/decoding, list, checkboxes and so on...
The createDocument method takes care of the encoding/decoding parts for you. Both techiques are very, very usefull, and which to use depends on the situation....
It's really nice to use the agent method if you want to create XML from the input data....
Perhaps a bit out of context but anyway :)
Another way to manipulate documents in a view without having to visually reload the view is for example to have a hidden iframe included in the form that displays the view.
The iframe can then be used to send commands to the backend system (for example execute an agent that excepts parameters and that deletes a document in the view)
The agent then returns a javascript that executes a function in the parent document (for example hides the row for the deleted document) or display a message if the operation was unsuccessfull... or whatever it might be....
Maybe Codestore and Notestips should join forces! ;-)
As an alternative mechanism for the checkbox column, don't forget about the view property that was added in an R5 QMR (might have been 5.0.5 or 5.0.6):
"For Web Access: Allow Selection of Documents"
With that option selected, Domino will generate the checkboxes automatically.
Larry:
CodeTips - The Revenge of Notes
Could make a good movie! - erm... maybe not!
what jerome mentioned is very feasible. I have used the same technique mentioned to post to a java agent, the code (roughly) looks like this:
/*get document context*/
Session session = getSession();
AgentContext agentContext = session.getAgentContext();
Document dcx = agentContext.getDocumentContext();
/*init vector and hashtable*/
String strRequestContent = "";
Vector dcxItems = dcx.getItems();
/*search the item list for request_content*/
for (int i=0; i < dcxItems.size(); i++)
{
Item iItem = (Item) dcxItems.elementAt(i);
if (iItem.getName().equals("REQUEST_CONTENT") || iItem.getName().equals("request_content"))
{
strRequestContent = iItem.getValueString();
break;
}
}
/*parse request content string using
string parsing _or_ javax.servlet.http
functions*/