Pushing the Button
You all know I like to court controversy, so, without further ado, I'll begin my my latest opinionated diatribe with the following stament:
Domino lends itself all too well to lazy web development!
As we all know, the Domino web server came about as a way of making Notes client applications available in the web browser. For this reason Domino has always tried to mimic its Notes counterpart. To help us in the process they tried to make this as easy as possible. Often with terrible results. Java View Applets anyone? There mistake has been to assume that we want to mimic the Notes client. I guess at the time we did. Back with Notes 4.6 when Domino first appeared that's what we thought it was for. Only with time did web-only Domino applications come about. But it was too late. For reasons of backwards-compatibility we now have to put up with all its oddities. It will never be like PHP, which was built from scratch as a web development tool. I don't blame Domino for this. It just annoys me sometimes. Not only is it annoying but oftentimes it prevents me delivering what my clients want.
Now, I rarely develop sites for use in the Notes client. So why oh why do I still make use of the easy shortcuts to building an application. Am I guilty of being lazy? I think yes. Although over the years I've gotten better, no longer using twisties or action buttons, I still find myself being a lazy developer.
Sure, it's great that we can do everything the Notes client can do in the browser and do it so easily. But, while easy might well be fast, it's also not that far from being the same thing as lazy. We might be able to create web applications quickly, but this means we seldom think about or plan the application we're developing. I am guilty of this too. To fix a problem I often simply stick another button on the form or whatnot. Rarely do I step back and think about how it would be done in the web world outside of Domino. The real world, if you will.
Have you ever designed a web form with more than one button at the end of it? Instead of a solitary "Submit" button there are multiple buttons, with names like "Save As Draft" and "Publish Now". Each one representing a different option. Whether or not you rely on @Functions and _doClick() or your own code, this approach relies on JavaScript. Disable JavaScript* and the form no longer works. This is not good.
There are only really two types of buttons in web forms - submit and reset. Without JavaScript we can only really have one button on our form and that simply submits it to the server. So, how would we do this any other way? Well, let's take the above example, where the button would simply set a hidden Status field to either "draft" or "publish" before submitting the form. All we need to do there is un-hide the Status field. Make it a radio-button with a default of "draft". When they're ready the user simply changes it to "publish" before clicking the single submit button. Think about other web forms out there. Lots of them only ever have one button on, don't they!
Maybe it's a bad example, but you get the point, right? If you want to make accessible websites it can be done, but you will have to rethink your forms.
* For testing purposes, JavaScript can easily be toggled on and off with either the web developer bar for IE or for Firefox.
Skip to the 
You can subscribe to an individual
Apart from the fact, that the Domino engine was introduced with 4.5 (ahem ...): Yes. In general I think you are right. It IS a good idea to make a web site at least work without the need for JavaScript. Personally, I always love the KISS approach.
There are contradicting examples out there, though. Many web based forum software packages do provide customers with multiple buttons like "preview" and "post". vBulletin, the king of all forums, wouldn't look half as nice without JS. Stuff like WebSphere Portal - or worse - Workplace don't do anything usefull without JS enabled. DHTML is cool. Methinks. The key question is: Do users really care that much about user interfaces that stick to the classical paradigm of "submit button only"? Some may, the majority probably doesn't.
On the other hand, almost ironically, integrating Domino applications e.g. into WebSphere Portal is much easier to do, if the Domino app gets along without JS. Just recently, a valued colleague of mine and I had an interesting discussion about how to build a Domino form in this environment. The question was, how to establish a session for an anonymous web user without the use of cookies and JS (turning of this infamous form property, just as suggested). We came up with an interesting conclusion. When submitting a form again and again using the standard Domino generated submit button by setting the $$Return field to the same ?EditDocument URL every time, the UNID of that doc provides just that: A session, that is extremely unlikely to be picked up by any other user. This 32 character id does it's job just as good, as almost all session cookies (or some othre kind of URL rewriting) used on other platforms.
I hope that this is at least somehow related to the topic. It's past 2 am here, I had 2 beers already and feel like going to bed now ...
Just an FYI, you can use more than one submit button without JS. If your form method is set to "post", the name/value pair of which submit button was clicked can be pulled from the request_content field. You can then use that information to determine if the user is Saving/Approving/Publishing, etc..
Jeff - request_content doesn't work by default with Notes forms, although there is a hack available (just google request_content - the first entry is an IBM support doc)
My thoughts on this "battle" can be found on my blog if you are interested.
I agree to use domino as a web development environment itself and forget it's Notes in the backstage.
But, in the other hand, I consider Javascript a web tool more, as CSS or HTML itself so I prefer not to do without it. It's very usefull to avoid annoyances related to _doClick
I use more than a button per Form :) and I even use ACTIONS in my web developments. But I don't feel guilty nor lazy, because I am supposed to transform old Notes Client Apps to Web environment, and I want my users to keep filling confortable with my apps.
And finally, if you're not using @Funtions (@Formulas, here in Spain), no reason to use Notes. Use PHP. :)
It's good to see agreement for once ;o)
Harkpabst. You're right. The majority of users don't care about how many buttons there are. That's not the point though. The point is that the minority really do care. Not only that but they have been given a voice by government legislation (in increasing numbres of countries) which makes it the LAW that sites need to be made accessible to all. It's a case of horses for courses and whether you factor in things like users with no JavaScript depends on the needs of the customer.
Jose. Just because I don't use @Functions in links or buttons is no reason to drop Domino. Were you serious?
On the main point of Jake's post, I would have to agree: Domino does encourage lazy web development. This really stems from the product's (well intentioned?) efforts to give the developer a hand.
"Modern" web development - that tackles such issues as standards compliance, accessibility and usability - now requires an understanding of a number of disciplines, all of which are in a state of flux. This is the issue that Laurette's blog entry refers to.
It's a tough road to follow, but one that's worth it. IMHO.
As for the example, it is possible to have either multiple submit buttons per form or, as an alternative, multiple forms per page (Domino form).
Jake
In response to this blog and your response to my comment yesterday I absolutely don't think that lazy can be substituted.
I have developed many domino web sites both public and private and after years of pain have come to the opinon that the best approach is to stop fighting it and use the in built features.
The product of this approach is not lazy development but simple, maintainable, cost effective, radpid application development - Domino Development as its best.
Sure the cost this is that you cannot get *exactly* what you/client wants but you don't end up with a spiders web of hacks and other nasties just to make the $%^*%^ing thing behave. Junior developers, even with a loads of documentation will not be able to maintain this stuff.
This works for 95% of domino projects.
If this is really a problem or as in many instances your data is really relational then use PHP, J2EE, .NET or even Ruby on Rails!
I am not being lazy, I am trying to be practical.
Cheers
Spug
I see where you're coming from Spug but I can't agree.
My solution *never* use hacks. All I ever use are simple tactics to get what I want out of Domino. This is basically a combination of Passthru HTML, Fields and WQO/S Agents. If a developer can't work out what's going on he shouldn't call himself a developer. Junior or not.
More likely to be of confusion to a junior developer is a pure Notes application on the web. Can you not remember what it was like when you had to try and work out what the hell was going on? Still gets me now.
I think that the webadmin.nsf is a really good example for that it is possible to mimic the Notes clinet on the web and it really looks great in my opinion.
There are quite many users at our company that use both the Notes client and web interface for Notes apps and for them it just makes sense if they can work on both GUIs in a similar way.
One Person's Hacks are another person's masterpiece...
Jake,
I believe you are being too harsh on Domino and it's developers. Not all websites have too be compliant and backwards compatible. This is solely the discision of the client and not the developer.
If you want to start to point fingers and naming names, why not take a look at the clients themselves. We can only do what they tell us to do and try to point them in the right direction.
At the end of the day, Domino, i believe is a great tool and only does what you tell it to do!
Regards
Patrick
Jake,
My tuppence worth...
In general, I agree with you, but just a couple of points...
1. Are you saying that accessibility guidelines dictate that you're only allowed one button on a web form for submitting purposes?
and 2, in response to your 3:40 posting, should you find yourself in the situation where your company is doing very well and you find yourself needing to employe another developer, then I think you'll really have your work cut out trying to find another developer, (especially a junior) who can pick up and run with your code.
If its just you that needs to develop the app then sure, go with what you feel is best, just be aware of who will be following your path...
Ian:
I would have to dis-agree that Jake will have a hard time finding a junior developer to pick up and run with his code. The combination of "Passthru HTML, Fields and WQO/S Agents" is pretty straight-forward, even if you have only a little Domino experience.
Jake
I think you have raised a very important question here - why would you use Domino for web development at all?
I use it because I know it best (for now) and also develop a lot for the client.
Without the above two, I would us VS .Net and SQL databases.
With a true relational database I can use SQL to generate joined 'views' on the fly, VS allows better development of objects (if only for the collapsing code editor) etc etc.
So, serious question, what advantages are there in using Domino for web development? It seems to me a constant struggle to get it to work the way I want.
I would start saying….. It's a hard world outside Domino. When you get out of it and begin experiencing Non Domino web development, you'll miss the Domino good times. I saw people crying with J2EE developments, for instance… dealing with out of memory problems, servers down and the movie's evil….. the performance stuff (!!!!).
I think the world is far of being perfect, so I think is not so ugly keep the JavaScript issue on in your Domino web apps.
What I agree, is the lazziness topic. Domino lets you develop a web application quickly and you get excited thinking any thing could be done. But problems appear when you have to deal with "aggregated value details" which mean the difference between a high quality website and a "default domino web app". 2 simple examples I recently dealt with (all discussed in articles of this site):
- Manage web views (!!!)….. Next and previous button, order columns, etc, etc….. Using CSS, of course
- Control of attachments (What a issue!!…. specially for the unfortunately and still R5 developers)
I can assure you'll loose your lazzy feeling when you spend hours and hours overriding all the defaults that web domino gives you and try things work as experienced web users are used to in non Domino apps. I can tell you I'm not getting bored at all dealing with these "Domino shortcuts".
I often find develop apps that have the "generate javascript" option turned off. I've been building Domino web apps since v4.5 when lots of features weren't availible to the web. You had the core features: security, forms, views, agents and that was it. But that's all you *need*. You can build a website that will do almost anything and look and feel almost exacly like any other.
I want to build a web app, not a web enabled notes app. Way to often I see Domino web apps that are just plain horrible. Not just from a look point of view, but how they opperate. The developer clearly had no idea what was going on between the browser and the server, and didn't care. Domino just doesn't do a good enough job for the developer not to care.
What I love about Domino is the security and the ease of deployment. The thing I'd like to see is better berformance for java agents. If java agents could behave more like servlets then that would be excelent. In fact if they could have built in servlet (and jsp) support that would be even better... doh!
Patrick
Long time no hear;-)
In response to
"Not all websites have too be compliant and backwards compatible. This is solely the discision of the client and not the developer.
"
I'd have to disagree with you on this. I'm still working on an old mutual project of ours that had no compliancy in either code or accessibility. Granted accessibility was not part of the spec at the time but i'm still trawling through and fixing some of the bizarre code (not any of yours though ;-)
I believe that there is an onus on us, as developers, to write easy-to-follow code. If it were not for codestore i'd still be hacking together domino sites. Now if i even begin to think about putting in a "<Table>" I feel guilty. If we develop our application in a compliant, modular way then we are setting the guidelines for junior developers.
Mind you, this "lazy" coding is paying the rent!
We've taken a new approach to Domino. Domino/Notes is now just the backend. Legacy data lives in Domino while we work on porting it to something else. Every piece of Domino data is being surfaced through Portal via Web Services and let me tell you, it's glorious!
You made a post a number of years ago, about wanting Domino to do "less" for you (I believe it was in reference to the auto generated HTML that comes with views) and those words stuck with me. You made an excellent point at the time (and it's still valid today). The data engine has no business rendereing UI components for an application.
Kerr, we still have the old R5 servlet engine in R6, when I remember right. No JSP support, though, and this engine does not adhere to any official servlet standard.
And this is not going to change in the future. But we also have a limited use license of WebSphere application server with every single Domino server license.
Having been bouncing between Domino and WAS, I have to agree with a lot being said here, if not the interpretations of what it all means. Domino does give you far too many "helpful" crutches upon which to lean, and more often than not, they are a burden to work around. On the flip side, though, you have to build almost everything with WAS. Granted, there are many WAS features to ease the pain, like j_secure for authentication via the container, but mostly you are buliding everything, even simple views and lookups become a long chain of POJO's to keep the architecture flexible enough for growth.
Some of the things Domino does for you are a real blessing, and for small projects there should be no question as to which to use - Domino. Domino even has the advantage over PHP... your data structure is built on the fly for you... no MySQL to set up and design. But when it gets down to raw performance as well as highly precise design, Domino should be left off the table completely. PHP or J2ee via WAS or Tomcat or JBoss are going to cary the day in those battles.
Ultimately, you have to know the project scope and use the technology that fits IT, not that which fits you preferred skill set. Consider it an opportunity to be challenged and learn something new if the answer isn't "Domino" in every case.
Jake, I agree with some of the others here in thinking that maybe you should use another environment on some of your applications. Look at how much work you are adding to Domino sites to make them work the way you want and not work the way they were designed! In other environments you could dictate this without fighting the software.
VS.Net, yep Microsoft , gives me many of the drag & drop features of Domino Environment (Datagrids, Data Repeaters, Dropdown lists, radio buttons, etc). Granted, it might take a a couple lines of code to make DB connections but other than that it's pretty straight forward. Also, the components in .NET are much more customizable than the Domino counter parts, making them a blast to play with. I try to adhere to programming standards but I must be a bit lazy because I still want to use components that eliminate much of the dirty work and VS gives me the tools to do so.
I hate to sound like an MS sales person but I have been impressed with the VS.NET environment. I am sure that PHP, JSP, and classic ASP offer many of the same performance capabilities that .NET has over Domino, though I’m not familiar with the developer tools for those languages.
Domino still has its place here in our Texas office but we are trying to limit it to smaller internal applications. I still like Domino and don’t want to see it go anywhere, but its showing age and lagging behind the capabilities of other languages. Too bad release 7, being a server release, didn’t focus more on serving better Web pages.
Ian. Accessibility guidelines don't say anything about how many buttons you can have. They just say things needs to work without JavaScript.
Whether a developer picks up my "hacks" or a pure Notes app developed the Lotus way, they will have as big a hill to climb before they start running.
When I take on other developers they will be at a similar level to me, of the same mindset (I hope) and able to easily deconstruct my work or that of others.
Others. Why do I use Domino? Good question. Lots of reasons. One big one is that it's what people (and my customers) know me for. People rarely come to me with a problem and say "How do we do this?". Normally it's a case of "We need a Domino database to do this. How much would it cost?". Only rarely do I (and I *have*) tell them they shouldn't use Domino.
Another reason to use Domino is that most of my clients are small, budgets are tight and timescales are short. Using anything other than Domino is normally out of the question.
Even with the work I need to do to get Domino to do what I want it's less than it would take to do the same thing in other environments. For this I am grateful to Lotus.
There I admitted to it. Domino's great ;o)
I hope to get more in to other environments at some point, but for now I am stuck in a world of Domino.
Hi Jake,
It's good to hear that you finally admitted to liking Domino..... for awhile there i was thinking that you were going over to the Dark Side and turning this into an Anti-Domino website!!!..... :-)
Later
Patrick
P.S. Glen... nice to hear from you too... I don't condone bad design, coding, etc... It's just that you don't always have to make your website's compatible for all browsers etc... It's up to the client to decide what level of compliancy and compatiblity that they want!!!
I hate to be harping on about Ruby on Rails (I've done so in another comment recently) but that's what I've been playing with in my spare time lately (Domino development in time that's not spare). I actually have a site where I've been writing about my learnings with RoR and one of the things I wanted to do was two submit buttons on one form.
In case anyone is interested how it can be done in other environments here is the link: {Link}
Jake - I agree. I've seen far far too many *horrible* unmaintainable sites out there running on Domino, trying to get that last 10% of "look and feel" going.
And yes - some folk hack that up. I'm not suggesting you do - but I've seen a lot of kludges.
Sometimes I do wish the Domino interface generated "nicer" HTML code, and allowed more control. But you can see where they're coming from.
Its supposed to be a Rapid Appilication Tool. Someone far wiser than me once said notes went bad when they introduced lotusscript - it allowed far too complex applications on. There's more than an element of truth in that.
But hey - we're all programmers. We make the impossible possible. Well, aside from making me taller and thinner, obviously.
But good thread.. Keep the controversy coming!
(Some folks believe that all Domino bloggers sing in a sort of co-ordinated choir. A bit more disruptive arguments would kick us all on a bit farther..!)
---* Bill
{Link}
(possibly the ugliest hackiest Blog around!)
I must say that I mostly agree with you Jake. I do think, though, that it also depends on what your web app is supposed to do.
If your web is going to be a public website, it certainly should have no javascript and have correct HTML and CSS. However, if you are doing web applications that will only be used on the customer's Intranet, then I wouldn't be so strict. Mainly, because using the things that Lotus gives you, no matter how ugly we all agree they are, can give you the edge over a competitor's offer. Not only that, I have found that many times our customers wanted the same app they had in Notes, but in HTML.
As for the people that recommend using other tools instead of Domino, if you are not going to use some of its features, I disagree. Even without using Java applets, Domino javascript, and Domino generated views, it's much faster to develop a secure, standard, accesible, web site with Domino than with any other tool I have tried (Java and PHP, mainly).
That's not to say that it is always the best tool (I wouldn't recommend it if you need a relational database, for example) but, for what it does, it does it much better than the competition.
harkpabst, yeah I know. I was alluding to the fact that in the ND6 beta there was Servlet support built in at the db level, but they pulled it in favour of bundling WAS.
If your infrastructure and admins are on board with that strategy then that's fine, but in a few places the Domino admins won't touch WAS and the WAS admins won't touch Domino. Then you find the WAS servers and the Domino servers aren't even in the same country and all the ports are blocked and "No we're not going to turn on DIIOP. Have you filed Form 27 stroke A? In triplicate? Signed off by the global head of bureaucratic red tape?"
Suddenly ND6 (and now 7) with Servlet support built in at the db level sounds like such a nice idea. But yeah I know, it’s not going to happen. What probably will happen is a move away from using Domino as an application platform. Not Domino's fault, but that's what'll happen. YMMV