Goodbye _doClick(v, o, t)
Notice any change around here (the arrow is a big clue, view source for another):
Like most of us I tend to leave this setting ticked, give it little thought and simply put up with the needless JavaScript it creates. Not no more though! From now on I intend to disable this feature from the off and struggle through without it. After a few rough calculations I worked out it would save me 250MB of bandwidth use every month just by turning it off for this database (about 3% of total).
This change is one part of my upgrade to v6.2 of codestore and came about following some investigations I am doing in to designing for accessibility with Domino.
There's a little more to disabling this feature than you might first imagine. First, you have to make sure that you don't use @Functions in any links, hotspots or buttons. Then there's the inevitable "This is Domino, so you need to hack it" part. You have to add a hidden button to every form, otherwise Domino will needlessly add them for you.
This is easy for me as the way I develop sites means I only have to add a button to one subform, which exists at the bottom of all forms. In this case I a chose the classic method:
This button has no text and no formula defined. Domino then thinks there's already a button so it won't add another. Even though the button we've added doesn't render in HTML as it's empty. The end result in HTML is like this:
With clever use of a comment it almost looks like there's no hack being used and I actually wanted that HTML to appear where it does. Nice.
Another bonus is that Domino no longer creates HTML Forms when in read mode. This all makes for much tidier source code. Take a look. You'd be hard pushed to tell this was a Domino site. Now I can update the PDF I created and feel a little more pride about my tool of choice.
If you get a spare moment today turn off this setting for a database of yours and see how you well it works.
The war is far from over, but I just won another small battle against Domino and its HTML...
Skip to the 
You can subscribe to an individual
Although, if you are in a intranet environment where bandwidth aint so important the javascript and the @formulas make for very fast development/maintenence.
Deactiving javascript output is great, and it certainly works perfectly for reading, but now, regarding forms and views, how do you replace basic actions which requires domino commands, such as collapsing or expanding a categorized view (@Command([ViewCollapseAll])) ? Or submitting a form with or without "closing the window" (@Command([FileSave]) and conditionnal
@Command([FileCloseWindow])) ?
Spug. You could replace the fast in that sentence with lazy and it would just as applicable to Domino. Which is my topic for tomorrow.
YoGi. The trick is to not try and make your web applications like Notes apps. In my eyes the whole problem with Domino websites is that Lotus made it too easy to duplicate Notes apps in the browser. This could be a good thing, but, more often that not, is a bad thing. The web browser is not the Notes client! I can't remember the last time I developed a website that even used twisties. The key is to Think Different TM. More tomorrow...
Jake - agreed. It's the websites that surprise me when I find out they are run on domino which impress me now-a-days. I work mainly on internal applications, these work on both notes clients and web browsers. The web browser versions are what impresses people, they just don't believe they're developed in-house and are also surprised that they're based on domino as they look nothing like a typical notes app. I'll be turning off that tickbox and see what happens, I don't often use @Commands in web apps anyway so maybe I can also get rid of that damned _doClick!
Jake - you're right.
I work as web developer in small applications, not in the main thread of the business, what we call here in Spain Microcomputing, opposite to the great mainframe computing.
Most of our problems in getting Notes Databases work in Web environment were due to the point of view. Sure you'd have to develop WEB APPLICATIONS using DOMINO as the tool it is and not inverse.
Bad idea to build Notes Applications with WEB as the tool.
I celebrate finding you're blog. I finally feel somebody understands me.
I dunno what you're going to tell us exactly tomorrow, but my fear is that thinking different is a thing, thinking performances and maintainence is another.
If your suggestions for categorized-views like (or whatever which is more complex than a basic view) require WQO agents, i don't think it's suitable for environments with thousands of users. Categorized views might be very nice and usable once styled, and you might custom their behavior with a bit of DOM and JS. And they are generally pretty fast and the cpu usage stay low.
Sure, you can do what you want with Domino. But if it has to be slow or unmaintainable because full of crappy hacks, well, just use something else which better fits your needs : php, python.. Don't waste your time and your client's money.
YoGi. You should know I'd never use "crappy hacks" or unnecessary WQO agents!
All I'm saying is that, wherever possible, there has always to be a simper way of getting to information than categories views and twisties. Show me a non-Domino site that uses twisties!
Sure, internally they are good for intranet apps that replicate the features a user is used to in the Notes client. I just don't think replicating Notes functionality is the best solution.
Jake, I think you're spot on.
The best Domino apps are the ones that don't look like Domino. It's shocking the number of professionally designed Domino-based websites that just look like a Notes app viewed via a browser....
With DOM-scripting and CSS we already have the ability to create a far better UI than the Notes client ever could, so why not use it?
Er... what's going on with your time-stamps on comments?
All of the comments suggest we're in work much earlier than usual!
Non-Domino sites using twisties do exist! At least one:
{Link}
Moreover, this site happens to be a quite large and tidy one too, although not very cool (governmental). Twisties are used in the menus only. The good thing about twisties is their simplicity, ensuring they will look OK even when they are very small.
Don't be so emotional about twisties ;-)
I wonder; are we casting aside one of the major selling points of the Domino platform? Being able to develop and deploy apps quickly is a major pillar of the Domino solution and are we taking this away, in an effort to be more like other platforms?
I would definitely agree that there is a time and place for this, and that twisties are an abomination (as are tabbed tables), but I'll wait to see the real value proposition of this alternative.
@ YoGi.
Categorized and sorted views are a VERY handy feature in Domino and we all use them a lot . However it is often better to craft the HTML generated by them by hand than to rely on Domino. Passthru view/treat as html forms actually perform much faster that views/forms where Domino needs to generate things you actually don't want (that way).
So see Domino as a high performance development platform where the database is live when the server is live. How many times did you run in untrapped JDBC/ODBC errors with non-performing DBs on other platforms.
And with Ajax you can have your twisties (or +- signs as they are in fashion now) without a full roundtrip to the server and even better looking.
As Jake said. Web applications with Domino as a tool.
:-) stw
Jeff. Domino is indeed amazing if you want a quick way to build a web application. However, speed is not always the issue. How many times does a client say they expect all their requirements met within a week!? Well, ok, possibly some do, but they'll get what they deserve. Not all clients see speed of development as the key factor. If the client wants a site where the most important factors are that it's accessible and usable then Domino sites aren't going to cut the mustard by default. We the developers have to know how to deliver while still using Domino. For accessible sites this means not using any JavaScript and so we have to include hidden buttons on our forms. Not pretty but it's a necessary evil.
I'm not taking away Domino's selling point. I am just making sure that Domino can fit the bill in the case of the project I am on currently.
Hey, it's not like it will take three times longer if you're forced to do things the hard way, without the help of _doClick().
Well said, Jake.
Developing stuff quickly is one thing, but try to get the HTML to validate and pass accessibility tests - and this is before you put it in front of a human to test!
I've spent a lot of time and effort over the last decade re-writing many of the standard (i.e. quick but, in the long run, unsatisfactory) Domino web features.
BTW: I thought you said (a while back) that the first thing you did when developing a Domino database was turn off JavaScript. Or perhaps it was Mike Golding?
Thanks Arka. I don't think it was me that said that. Not sure if it was Mike either. Notestips.com still has _doClick() and I don't remember him having done it while we worked together in London.
You can use javascript in a accessible solution. The "key" is not to rely on the javascript for the function/site to work. The site should "gracefully degade" if javascript is turned off. Much more important (in my experience) is the structure/order of the generated code, that you tag different sections of your page with logical information describing the section, last modified information in links (title attributes, alt attrbutes) and so on....
Javascript isn't all evil, but should be used in such way that it doesn't break the site if turned off in the user-agent.
I agree Fredrik, but how feasible is that? Say you have two buttons - one called Draft, the other Publish. Pressing them uses JS to set the value of the status field before submitting the document. With no JS what would happen? Nothing. The form is broken! How can this degrade without a complete rethink of how it works. Instead you would need one standard submit button and a toggle status field with options of Draft or Published.
If you going to support the use of no JavaScript, why not just use none in the first place? The only time I can see degrading being useful is with rollover menus and other DHTML. With applications and forms it's best avoided altogether.
Your a genius! *me slaps forehead* I haven't used view/form actions in ages so why the hell do I keep that box ticked !?!?!?!?
"If you going to support the use of no JavaScript, why not just use none in the first place? The only time I can see degrading being useful is with rollover menus and other DHTML. With applications and forms it's best avoided altogether."
You're gonna have a hard time convincing the AJAX croud!
Andrew. The new wave of Ajax applications are a whole different kettle of fish - a whole world apart from the simple accessible solutions that are required by certain organisations.
I'm not trying to say JS is bad and should be avoided. I think Ajax is amazing and the future of a part of the web. I'm just trying to demonstrate how things can be done differently with Domino.
In accessibility terms, use of JavaScript is OK as long as your page doesn't require it in order to function. So you can use it to enhance the user experience, but you can't require it.
Believe it or not, it is possible to have pages that are enhanced by JavaScript but still work when it is not available. See {Link} for an excellent tutorial on this.
I feel I should write more but it's late. |-O
Make no mistake, I can see the advantage(s) and I look forward to more on this.
Does this mean that your site can no longer demonstrate javascript examples? as it would seem for example the radio button quiz on your site does not function any more.
I just thought I would mention it as no one else has discussed it yet so far, maybe this is not a problem.
I do like the sites style but it would seem that navigation is less clear since my last visit.
Still in my opinion the best domino web site on the www :-)
Keep up the good work.
G.
ex-domino specialist
Maybe I should read all the comments before posting! OK, no javascript great :-)
G.
Glyn. Glad you still rate the site and still visit.
I've not disabled JS on the site as such. Only you, in your browser, can do that. I've just removed the reliance on it for the site to operate.
There are articles on here that might break, such as the quiz. Not because it needs JS per se, but because it needs a document.forms[0] to exist. By turning off JS at the DB level the default form dissappears in read-mode. I'll go and add one to the article now...
Never underestimate the power of twisties. Even Google uses them (with a nice javascript list menu 'twist', of course). Try to personalize your Google homepage at {Link}