How to Become a Yes Person With WQO Agents
It was interesting to read that somebody else is using WQO agents to render HTML in Domino pages.
Personally I steer well clear of that whole "let's create all the HTML, just so it's valid XHTML". It seems pointlessly fool-hardy to me and doesn't allow Domino to do the things it is good at.
Although I do find myself using WQOs more and more — to the point where almost every form in the databases I develop uses one. Yeah, yeah, I know. Performance is ugly. Whatever! I'm more interested in functionality than performance. Unless, of course, the performance sucked so much that the functionality as a whole suffered then I have no qualms about using WQOs and am yet to notice any performance loss at all.
I use WQOs when Domino falls short and I need to get exactly what I (read, the customer) wants on the page. This normally happens somewhere in the main content area of the page. The rest of the page design is still governed by a series of subforms and remains consistent across all pages in the site — regardless of whether a WQO is used to create any of the HTML.
I've even found myself using WQO to replace views as a means of showing sets of documents to users. This wasn't merely "because I can", but more because it was the only way I could get them to render how the UI design guys had intended.
Tomorrow I'll share some useful code and an example of what can be done. If you've never used this technique then I'm hoping it will open your eyes to a whole new world of web development with Domino. With it you can become a "yes" person, never needing to say no to a change request again.
Skip to the 
You can subscribe to an individual
I discovered that technique a while ago after throwing up my hands at how difficult it was to create dynamic web pages (embedded views, framesets,Javascript...)
I'm looking forward to your examples!
Used this a lot .. and performance as you say has never been any where near a problem that its been a bad option.
I would like to know though *why* performance on WQO is supposedly bad - I've never found a good answer (maybe I haven't looked hard enough?)
Performance was supposed to be bad because these agents are run one at a time and are queued by the agent manager. This meant that if you had 5 calls at the same then, the last web user would have to wait for the 4 previous agents to complete before their request got processed.
I would imagine that most WQO and WBS run in less than a second, and that most sites aren't getting thousands of hits an hour so it shouldn't cause any real problems.
As long as the WQO can return quickly enough under load then no one should have a problem using them. Too often there are rules that people get entrenched into following without thinking why. As long as the reason the rule was brought in to deal with is violated then why not. But that's more difficult to police and enforce and many people don't like to think too hard.
@Jason
I thought the sequential queuing would go away if you enabled "run web agents concurrently" in the server document. AFAIK, WQO agents are executed by the HTTP task.
Yes, I thought WQO agents were run by http and would run concurrently if this was enabled (and the help certainly says that this applies to WQO/WQS and agents started via a url command).
Maybe Jason's point was true with R5??
As far as I am aware the Agent manager does not have anything to do with WQO agents. The HTTP task looks after them.
Performance "myths" are from R5 days - a lot of work has been done in this area since then.
Performance WAS horrendous in WQO agents. But as Steve pointed out, that was a long time ago. A lot of developers have written off WQO agents since then, but there have been enormous performance gains in the 6.x and 7.x timeframes.
The BlogSphere blog template makes serious use of WQO agents, by the way. And the performance of it has improved over the days when it was based on subforms and embedded views.
My understanding was that WebQueryOpen agents ran just fine as long as:
1. Run Web Agents Concurrently was turned on (as mentioned above)
2. Unread marks were turned OFF on the database, per this technote:
{Link}
And I'm pretty sure Steve is right about the HTTP task handling web agents, not Agent Manager.
just IMHO, When doing web development with Domino.... Why to use WQO agents in year 2007 when we have Ajax?
The intention of a Web Query Open agent is to be used into a form that is displayed to the user to "execute" some code before the document is displayed to the user.
Today you can do the same optimizing the behavior of your web application.
So, when, possible, I prefer to use Ajax instead of a WQO agent, since the traffic between the client and the server is restricted only to the necessary piece of data to perform a specific task. This atomic behavior model is very useful and convenient, specially form the integration point of view. You can have Web Services that perform those "atomic tasks" so you can reuse the most convenient service to share it with another application/system/WS Client, etc.
When I say possible, I mean that sometimes you have a public web site/app, that must be viewed even for old browsers, so then makes sense to use an alternative, but the browser abilities today allow us the web developers to take advantage of the new techniques and leverage our skills, and results.
.::AleX::.
I've used WQO agents for years to build feedback forms in the browser. The client holds x documents with data in (e.g. question, answer type (radio, checkbox etc.) and options) and the WQO writes out all the necessary HTML to a field on the feedback form called myHTML which is inside a div called myHTMLdiv.
The onSubmit JavaScript pulls everything out of the fields into a Domino field called myResponse (multivalue) and them sets myHTMLdiv.innerHTML to blank. This means that Domino doesn't have a fit about the fields inside that div which it wasn't expecting. A WQS then processes the myResponse field for something suitable for the back end.
The advantage of this is that you don't have to know the names or quantity of fields in advance as Domino doesn't see them, and you can do things like pick up only certain questions according to a value passed in the query_string, e.g. Department=HR.
We haven't *noticed* any *major* performance issues, but then no everyone in the company simultaneously tries to fill these things in.
I am doing two Domino Web projects at the moment, using much agents triggered by AJAX. What is really worse is that the pages are rendered HTML 4.01 transitional and many CSS is broken in IE. Why do we develop with Domino for the Web at all in 2007? The IDE does not support Javascript very well, the whole code is scattered around different design elements, you have to program in Formula Language, LotusScript, Javascript and HTML. This really is not very productive.
While designing a Domino app for the client we really have an RAD tool at hand. But for web apps I will head for JBoss SEAM. This is the first Java framework (afaik) that allows you to develop very fast a complete web app including role based security, nice GUI with AJAX, workflows created with graphical GUI, persistent data store etc. Just consider this: To validate an input field with AJAX you only need one tag, that's all it takes. Or creating a nice databound table in the web, also just some tags in the XHTML page. Domino was a very nice tool for doing RAD in the last years, but now I think better tools are available. And: SEAM is freely available and Open Source.
Mark, I'm not going to dispute on your point (especially as I have no clue of SEAM), but: HTML 4.01 Transitional doesn't break CSS. Never.
What might break your design is the fact that IE has even more bugs in quirks mode than in compliant mode and that Domino - by default - omits the DTD if you let it generate the HTML; which consequentially puts browsers in quirks mode.
As of 7.0.2 you don't even have to live with that thanks to the new $$HTMLFrontMatter field, even if you let Domino generate the basic HTML.
However, I don't mean to say, that Domino Designer was an up to date RAD tool. It's shortcomings can become very frustrating, indeed.
Fabian, maybe I was a bit unspecific with the CSS problems. But that also is a result of me being annoyed of the clutter of the whole web project.
As we all know you can do almost everything with Domino, but you need to use workarounds over and over again. That is one reason why this site is so popular: Jake is a perfect Domino hack(er) and he makes a living from the weakness of the Domino IDE.
Hi Jake,
didn't you give Ruby on Rails a test run last year? How did that turn out?
Hi Jake,
didn't you give Ruby on Rails a test run last year? How did that turn out?
yes, queryopenagents used to be a nightmare, yes, performance has improved, but Alex Hernandez has hit on the way sites are developed now, get the response/structure back to the user and then start filling in the data via ajax etc. It's the future ! (actually, its the present)
Mark: "That is one reason why this site is so popular: Jake is a perfect Domino hack(er)"
I love comments like that ;o) Thank you!
Bo. Yes, I tried RoR and loved it. Sadly I have to stick with what I know best and what puts food on the table.
Gaz and Alex. I disagree entirely that we should be using Ajax to build content. Ajax should be used carefully and considerately. An alternative to older way rather than a replacement. Most of my clients insist on accessibility being built-in to their apps. Ajax might well be the future but I'm sure it's the present, yet. What does it matter anyway - whether you use Ajax or not to fetch the content? You're still getting it from the same place using HTTP GETs and the server still uses the same old code. The only difference is the reliance on JavaScript and needless round-trips to the server! The only point I can see to what you're suggesting is that you feel cutting edge when you show/explain it to the end user. Yeah, Ajax is cool, but we don't need to over-use it!
@Alex/Gaz ... 2 very good reasons why you need to use WQO agents...
1) You can run the WQO agent as a user with a higher level of security - e.g. Where you don't want to give access to users to see any of the data directly in a db. Ajax you would need either to call another agent to do that (so whats the point) and update the div.
2) Complex javascript & frameworks (Ajax) don't tend to work on mobile/pda browsers.
Jake, Gaz and Alex,
I agree with Jake. I love playing with AJAX, but it should be used to push or pull updates based on user actions and input. Building the initial page should be completed on the server where it will happen more quickly and not add unneeded traffic.
Cheers!
Charlie
I have the heart of a child. I keep it in a jar on my shelf.
---Robert Bloch
2 thoughts:
1.) Ajax doesn't necessarily take away the need for WQO agents, it is usually much easier to call a form to get your response. This deals with pesky things such as character encodings for those of us who have to think of that. Also, I agree with Jake on this, use Ajax only when you have need for it, not just because you can.
2.) What drags down WQO performance these days are in my opinion views that you access in your script. In my code I got down from a 500ms accesstime to 40ms just by changing my configuration documents (1 view, getting a bunch of documents at once) to a profile document. So try to keep your view access down to the bare minimum.
@Mark: I agree, Domino is no longer very RAD for web applications, but if you try to separate you logic a little bit, it can be OK. These days I try to use forms to only deal with display "things", and keep my app logic in script libraries (called by WQO/WQS agents of course)
And for those of you who would like to use Rails, but are stuck in a Java world, try Grails...it has the sweetness of Ruby and Rails, but is built on Groovy (and Java) :)
regards,
Bjorn
Thanks for mentioning me, Jake. At first I didn't notice, until I saw the reference to this post in Technorati. Although I wrote the post, I don't use WQO agents myself, except to render search results in XHTML because I didn't find another way. But maybe we should consider using more of these WQO agents for things that are extremely difficult to do otherwise.
I don't like WQO agents. They have a couple of draw back. The biggest: they allow lazy development. Instead of thinking about a sensible architecture the WQO servers as the band-aid glueing that app together. Not the stuff Jake does, but the stuff I see that corporate developers do, who have too much pressure to step back and think for a moment. Secondly: the performance hit is quite big once you have an application that is used constantly (as in thousands of documents created per working day).
So lets see if there are alternatives to the WQO way.
:-) stw
Hi Stephan. Everybody talks about the performance hit, but I'm yet to see it and nobody seems able to backup their claim or point to any evidence. Maybe some testing is in order...
"lets see if there are alternatives to the WQO way"
There isn't though, is there!? It's the only way to get things done some times. Whether it's lazy or not it's the only way I can feel happy with what I produce. Maybe I could revert to using features like the Notes standard calendar view? Hey, it works. But I just wouldn't be happy giving stuff like that to the customer. Nor would they I expect!
Jake
When talking about "mission impossible", when your only choice is WQO agent - I use it to display content of Rich Text fields from various documents on the single page. Just using notesRichTextItem.AppendRTItem(...) method - it works perfectly to achieve the ability to present rich text in views (that's a big lack of views in Lotus Notes client).
One of my colleagues suggested to run two WQO agents (we run some Agents with User rights and some with Developer and were facing issues if we needed both access levels) and to our surprise:
It works! Both WQO Agents can work on the Contect Document and pass data to the form!