Adding Ajax to Domino Views
After seeing the Ajax on Rails demo yesterday I bet I know what you thought - can we do that in a Domino View? Me too.
Well, I spent wasted an hour or so trying to squeeze all the necessary code in to Domino Views and $$ViewTemplate Forms, before I gave up out of angered frustration. It was all going well until I hit a snag and Domino returned a 500 error:
Application Exception - Documents treated as HTML cannot be edited
Without going in to the details of why I got to this point (or how I'd managed to forgot this clause) I just want to ponder one question — why?
Why can't I edit a document that I've told Domino to output as HTML? I guess it's because Domino doesn't trust me to get it right. Domino's a control freak and thinks we're all idiots. Say I have a form with one field on it, called FirstName. If the form is treated as HTML and I request it via a ?OpenForm URL command, the HTML sent to the browser should simply be:
<input type="text" name="FirstName" value="">
That's it. No other HTML. Just the field. The fact that you would rarely ever want to do this is not the point. The point is that in this dawning age of Web 2.0, Ajax and whatnot this kind of control is essential. We need the control. Without it we are left to resort to ugly hacks.
All is not lost though. I still think I can get the code to work with a plain old Domino view. It's just that I am going to have to use multiple Views and their associated Form Formula as well as duplicate Forms to cover read, edit and new cases. Then some WQS agents to spew out HTML when things get saved. I might be able to get it working but it won't be pretty. Domino development never is though is it. Leave it with me.
Skip to the 
You can subscribe to an individual
Hi Jake,
Have you considered creating a form in HTML that submits to an Agent?
This will get around Domino security for forms!
I have used this trick many times. All you need then to do is to extract the information from the "Request_Content" field.
(NOTE: The only trouble with this is that you can only pass back 32K of information to the Agent, as this is the field size limit!)
Later
Patrick
To get something similar to work I embedded the view on the form rather than using a $$ViewTemplate. When the form is opened the fields are hidden and then when the add new entry is used I show the fields without having to go back to the sever to get them.
I then do edit and delete in the same way as your Rails with AJAX demo, except that instead of going back to the server to get the field values, I just use the innerHTML of the table cells of the row that is being edited, and then insert them into the fields.
Hope that makes sense!
I hit the "Documents treated as HTML cannot be edited" problem a while back, when creating a structured query feature for a Domino app.
In that case, I wasn't dealing with Domino views - I was actually writing a replacement for them. I was able to get round it by creating a control document that the user edited. As that document was never updated, one would suffice for the many users accessing the feature.
It was a slight pain having to deploy the document - and ensure no one could delete it :-)
'May not help what you're trying to do, but I thought I'd mention it.
Thanks guys. I'm not really looking for a workaround though. Just want to know why.
With any solution I come up with I want it to be simple and portable. If we're writing code to make an Ajax-like View we want it to be portable. Adding the feature to another view should be a doddle and not a hassle that involves copy/paste/editing numerous agents and forms.
I really believe the main reason is just security. Bad developed PHP apps prove it every day that trusting a developer to make it right it not always a good thing. More Control also means more responsibility and I am not sure that what works for codestore would work for others.
Henning. Why would it be insecure to edit a document treated as HTML?
Hi Jake,
You can edit a form treated as html.
Use ?readform instead of ?openform
Regards,
René
It is stupid Jake. Just another example of a mediocre web rendering engine showing its age. The solution is to start using WebSphere. Didn't you get the memo?
Rene. By definittion ?ReadForm is not editing anything. It's READing it.
Jeff. Glad to have somebody else on my side ;o)
Jake,
I believe snapps (look at ben pooles lotusphere wiki) has a working demo of this. I kinda used it yesterday. Look at course 310. When you go their site, there should be a pdf download and a snapps.nsf. The db download should have a edit in view.
FWIW - they said it was a pain initially, too.
Hi Jake,
Had a thought! Why not just use a hidden IFrame to show/hide the form/document to create/read/edit documents!
All you need to do then is to show the hidden IFrame and open the form or selected document in it.... Therefore you do not need AJAX to do it!
This should be the quickest & easiest way of doing it!
Later
Patrick
its simply a granularity problem.
The domino guys envisioned the usage of their stuff like this or that *only true way*. Now with change in underlying technology (javaScript/html -> ajax) the vision of the usage pattern does not reflect reality no more.
It occurs in nearly all layers which makes things easier, though maybe on a minor scale than in Domino. For ex: We needed a hack for paging of hibernate resultset from spring last week. That's a no-problem with hibernate pure.
I don't think that Lotus did it really intentionally. Just creating a layer above low level stuff.
And if you weren't capsulating some of the low level elements together, the layer would not make much sense.
I think that its worse in Domino for the simple reason that they often think of a non-developer as a builder of domino applications.
Jake, I suppose you've seen this demo/tip allready don't you? (see website link above)
++++++++++++++++++++++++++++++++:
Risi Kumar Sahi created a great example of "AJAX code" named InViewEdit. This code makes it possible to edit a document directly in a view (like notes client 6 functionality).
++++++++++++++++++++++++++++++++++
Now, I'm sure you have already figured out a way of doing it, but here is my take on it: (using prototype.js)
The trick is the "EditDocument&Seq=1&__Click=0" part...this will trick Domino into thinking you are submitting a normally edited document. You must of course have an existing form, and the field names must match, but you knew that;)
..I know it's a bit of a hack, btw...
Oh, and I didn't test this piece of code, but I have used this method before.
var dbUrl = new String(location.href.slice(0, location.href.indexOf('.nsf')+4)); //url to database
function postMe(docUNID) {
var url = dbUrl +'/0/'+docUNID+'/';
var pars = 'EditDocument&Seq=1&__Click=0&'+serialize(myForm);
var myAjax = new Ajax.Request( url,
{ method: 'post',
parameters: pars,
onComplete: showResponse });
}
function showResponse(originalRequest)
{
//put returned XML in the textarea
alert(originalRequest.responseText);
}
Doesn't this just stem from the fact that Domino won't let you, unless using a workaround, submit to a form that does have a corresponding Domino field on it. This 'Documents treated as HTML cannot be edited' must simply be to prevent non-elite developers like yourself from bending and stretching Domino.
Jeff Crossett said it best. But here's my spin anyway. ;-)
Domino is a concept from the last decade thath thorugh sheer will of its users has hung on till now. The big thing is to realize its limitations and find yourself perfectly happy to use the appropriate technology for the job. In fewer and fewer cases is it Domino.
The choices are now numerous. If you havn't bothered to learn at least one other by now, be it on your own head (unless you're just getting started, in which case, do yourself a faveor and pick up also .net or ruby or php or java while learning Domino).
Here's the soapbox back for whoever was next.
This has been a bugbear of mine for a while. I want to have complete control over the html, but I also want to have domino be aware of the edit mode. I don't even need domino to generate html for the fields, I just want to be able to have the form open in edit mode and put the current value where the field is. Effectively this would be just like read mode except @IsDocBeingEdited would return true. Now what's so hard about that? I wouldn't particularly mind if the fields generated there own edit mode html, usually that's what I'd want to use, but I could cope with out, and from time to time I'd want to override what domino would give me by default.
Alternatively why not have an option that turns off generation of the html outside the body. E.g. by selecting that option domino would not generate the preamble, html, head, body, form tags etc. Other than that behave exactly the same. No?
It's a huge pain... but I'm using a combination of ?SaveDocument and ?CreateDocument URL commands or posting to an agent and stripping content from the Request_Content CGI variable, View form formulas, and $$NavigatorTemplates to produce what should be very basic functionality: non-Domino generated Domino Data Management!
The problem is, for every one of us that complains and wants the option to hand-code our own stuff, there's 5,000 lazy developers that would rather let Domino do it's oh-so-nice rendering... even if it does make 3rd-party solution integration a painstaking ordeal.
Maybe they're just making it easier for us people who know *how* to hack around these shortcomings to find consulting work... ;-)
All kidding aside though, for all that Domino can do, it can be a painful process to take it to the next level, and quite frankly has people (such as yourself) looking for more "I'm a geek and I can do my own thank-you-very-much" freedoms in their solutions engine.
I'm certain that IBM wants to accomodate their product adopters requests... but there's one big issue here: backwards compatability. How many applications would blow up, and how many current "Domino Developers" would break their environments day-after-day if you allowed some of the things that we're asking for? 1/5000 might really thrive with this added functionality, but the 5000 are going to have a hell of a time - which reflects poorly on the product.
It's been said in the past time and time again that LND can make for lazy developers... and I think that they could be the very root of the issue as to why Domino's not moving forward as fast as it should.
But I digress....
It's a matter of details -- "Treat as" doesn't render widgets or a form tag with an action, and the widgets located at the action are the "CGI script" for a normal Domino POST. There is, then, no native way to process a "Treat as" form, and there cannot be one. Domino is being reasonable here, even if there are a (relative) handful of developers who can be trusted to get it right. And please try to remember that we are in the minority -- all one has to do is wander over to the developerWorks fora to see what the general population looks like.
Well said Chris, and a very sobering reminder from Stan. Maybe we could use something like a Domino design equivalent to DocTypes. That way the lazy developers can still pump out spiraling loads of default views in quirks mode, but others can turn on strict mode and have alot more control (like basic access to the users session information!!!).
I am still holding out for some glimmer of hope that IBM may give us an XHTML engine for Domino, but I think I have a few years to think about that.
I'd definitely look for that in "Domino Next", Jeff -- Mark Vincenzes (the current "voice of Domino's web engine") had been floating XHTML balloons and seems to understand which end is up. I have no idea how they plan to make sense of rich text (since the internals are conceptually similar to HTML 3.2 and end-users just plain don't do styles), but....
There were two postings here from March 4 that are now gone.
Ron Yuen made a good comment on using
?ReadForm.
Mark. I accidentally deleted them while removing spam. It was an honest mistake. I've mailed Ron to apologise and he's sent me the DB he mentioned. I'll take a look and get back.
Thanks.
I think you have the answer to your question though, right? What Ron said is consistent with my understanding of how it works.
The semantics of ?EditDocument and ?OpenForm imply using the Domino generated HTML, so those URL commands don't make sense in "treat as HTML mode" ( where Domino doesn't generate any HTML).
I don't think it is a case of security or "we don't trust you".
Jeff,
What "user session information" are you after?
What do you expect out of the "XHTML engine". Just valid XHTML, or something more?
I know you're not looking for a work around. But if you were, you could not use a domino form at all, but rather a domino agent to print out a form for you.. Then you wouldn't have to worry about these gotchas..
Does that make sense?