Welcome to My World
When I first met with clearleft, to talk about them doing some front-end design work, I mentioned that I was proposing to build a solution based on Lotus Notes/Domino. The reply was something along the lines of "Isn't that email or something". Needless to say they've not worked with Domino before.
This to me is a good thing. They can design a site without having to worry about abiding by the dos and don'ts of Domino. Part of their process is planning the "information architecture". They can do this without even thinking about the form/view paradigm or categories and twisties. It's then down to me to make sure that Domino delivers the goods. Hopefully this separation from technology will help produce something ground-breaking as far as Domino goes.
Do they need to know anything about Domino though? I can't decide.
In the brief introduction I gave them to "my world" I talked about a couple of things. Firstly, that you can't change the doctype used, which affects the CSS used, as it means it has to be coded for quirks mode. Secondly, I talked about Domino's own HTML. That it likes to make all the HTML on its own. That it's possible to override this. That we can add to the Head and control content within the Body tag, but pretty much everything else it out of our hands.
What else would they possibly need to know? Maybe they should know that most pages will have a form element on them, even when it's not really needed. Again this can sometimes affect CSS-based layouts at the pixel level. To try and help them out I've created this PDF which shows the basic HTML that Domino spits out. To do this I created a Form with nothing on it whatsoever. This is a "best case scenario" for them to work with. What I can't decide is whether to show it to them or if I've missed anything off it.
Skip to the 
You can subscribe to an individual
I'd add to the pdf the fact that you can add content to the head section of a html document (your form).
Also, you may want to mention the page design element.
Should you give them your pdf? Yes. They have a high interest in the html, if I interpret their web-site correctly.
I do agree with you that a domino developer shouldn't say too much about domino to a client. Let the client express themselves in the way they want to. Pin them down on what they really want, then work out how to provide it.
In my experience, Domino is versatile and there is usually some way to provide what they want.
Dietrich nailed it pretty well. I would show the PDF to them but along with the usual points about shorter dev times because so much is "done for you" versus the longer dev times where you need to do everything from scratch.
Some clients and/or some projects will need that level of total control, but the vast majority can live without it.
Definitely let them know as much as they want to know about the framework you are working in.
Re: doctype, if it's available to you, you can do this:
"Upgrade Domino to at least version 6.5.3 and set the DominoCompleteDoctype environment variable in notes.ini or preferably in a configuration document in the Domino Directory. It has 3 different values:
0 = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
1 = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2 = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> "
{Link}
and setting '1' will cause IE6 and Moz to use standards mode.
I wish everybody stuck to one standard when designing for Domino. I use Blogsphere for my blog. So when I switched the server to either 1 or 2 (See Andrew's entry), Blogsphere totally broke.
Y'know, it is possible to read that setting and adjust your output accordingly. Of course it's extra work, but when you're writing something where you don't know what the end server is set as then it makes sense.
@Andrew - I really wish that setting was at the database level rather than the server...I mean, how hard could it be?
Andrew, incredible piece of information! I wonder where Bo Frederikson got the info from. Did I miss something in the release notes? I don't think so.
I'm off to try this immediately. Once again, great stuff!
One short note on the original topic: I think that PDF is just fine. And I don't think I would mention pages at all. Not only because I don't like them, but in the first place because it doesn't provide them with any meaningfull information. In the end, there's nothing you can do with a page that you can't do with a form. (Yes, I know, except for making them the default startup option for a db on the web, but Jake already has the best workaround of them all for that).
So Jake - should I download that pdf or not then? And doctype number 1 (standards mode, transitional) would make life a little easier than trying to remember how quirks mode deals with stuff :-)
Jake,
If you do not have access to the Notes ini (or the right version of notes), couldn't you just post to an Agent ? i.e. Build your own HTML forms.
This only becomes a real pain in my experience when you have to have a file upload control.
You would still have all the other useful stuff just not standard Notes forms.
Jake - you considered using anything like dominoblog.com for your content management?
That will let you use any html you want and any doctype you want. This results in perfect web standards output.
regards
Steve
I just "armtwisted" some customers to activate DominoDocType=1. A lot of their applications broke. Primary culprit were pages where the content type needed adjustment (from default to text/javascript or text/css). However there were some VERY nasty "bugs".
CSS can be a beast (go buy Topstyle Pro to tame it). In Quirx mode an entry like margin : 20; is acceptable (even if it is not valid). In Standards mode it must be margin : 20px; (or another valid unit). Also we found that some propriarty extensions (like expression()) didn't work anymore --- but who would use something like this anyway ---.
After the fixing exercise the clients saw the advantage: Faster rendering and more precise CSS layout.
:-) stw
It's already in the code sample of your PDF, but it may be worth pointing out. Domino doesn't let you enter the "first" content within the body.
We worked with a web design company that used Visual QuickMenu Pro, by OpenCube.com, and a requirement of this menu is that the script tags to create the drop down menus *must* be the first element within the body.
Hi Jake,
I agree with you that Domino creates it's own HTML, but you only need to worry about this HTML when the document is in EDIT Mode.
You can easily create a form for READ Mode that allows you to specify all your own HTML (i.e. Set the "Content Type" to HTML).
To do this you will need to create 2 Forms, READ (i.e. for READ mode) & EDIT (i.e. for EDIT Mode). Then all you need to do is to create a READ View for opening the documents in READ mode. Within the READ View you need to override the Form used using the "Form Formula", to point to the READ Form.
I always use this method for getting around the problem above.
Hope that helps.
Later
Patrick Niland
True, Patrick, but when you use "Treat content as HTML", you give up Formula Language, which can be right useful even in read mode. Let's take something like @Command([ToolsRunMacro]) -- if you use a Formula action, you get all of the data associated with the document context for free. To do the same thing in a "pure web" environment, you need to use Formula on the form to create JS-usable hooks to the current content/context, then use JS to corral all of that data and append it to a GET request to an agent. Oh, and a simple hide-when on a single button/hotspot will completely remove all of the associated functionality -- you don't need to worry about exposing "internal data" to anyone who shouldn't be using it, ever.
There is Ideal Output, and then there's using the platform's strengths. We don't have to revert to "Notes on the web" in order to create effective (and usable) web sites/applications -- we've come way too far for that. But we also don't have to throw away everything that came in the box.
*Disclaimer: oddly enough, the only times I've ever been _forced_ to get out of control with tons of hand-crafted client-side JS and super-complex HTML were when I've have to _exactly_ duplicate a Notes client application on the web. Default Domino may look like Notes on the web, but it sure don't act like it.
Hi Stan,
Yes & No.
You can still use Formula throughout the Form. The only sections you lose from the Form are the Form Coding Areas (e.g. Window Title, HTML Head Content, HTML Body Attributes, WebQueryOpen, WebQuerySave, etc...).
All these can be replaced, except for the WebQueryOpen and WebQuerySave. Since we are in READ mode, we do not need the WebQuerySave.
Therefore, the moral of the story is..... If you need the "WebQueryOpen" Agent to show your Form in READ mode, then you CANNOT use the method i suggested, else it should be fine
Later
Patrick
P.S. Stan, thanks for the correction...!
@Hark the DominoCompleteDoctype setting was mentioned in the fixlist:
{Link}
Yes, someone actually reads it ;-)
The bad news is left at the bottom:
"Note that the different DOCTYPE settings will not affect the HTML generated by the Web Engine."
@Colin. I think the DominoCompleteDoctype setting should be in the website document, since your CSS will need to work across multible databases.
@Jake. I suggest you turn "Use Javascript when generating pages" off, to take back some control of the resulting code. :-)
Great work, Jake.
Regards
Bo Frederiksen/BoFrede
Am I the only one, or does the link to the PDF appear to be broken?
Patrick, I'm not talking about Formula Language to compute values -- I'm talking about Formula Language to DO STUFF. And no, you absolutely CANNOT leverage that on "Treat as".
@Doug:
To get the first entry into the body you need to hack the body attributes. If you put in a > the body tag actually closes. Then you can put it whatever you need. Just make sure that the Domino generated > is used up (eg with "<!-- End of hack --" )
:-) stw
Hi Stan,
OK.... I agree it removes the Formula Language to DO STUFF (i.e. Actions, Tables, etc...) and that you have to write the HTML yourself.
I over-stepped the mark, by stating "Treat As HTML" would suit all circumstances, but from my point of view i have gotten to the stage that i find writing my own HTML it easier and simpler than letting Domino do it.
I found that i was spending way too much time , trying to get Elements (e.g. Tables, Actions, etc...) to display correctly on the Web.
Anyway, that's just me!
Later
Patrick
I'll go along with you on the tables and whatnot, but hotspots and whatnot? Nah -- CSS will do wonders. Beats the heck out of trying to recreate a lot of the functionality you get free with Formula when Formula is appropriate (like passing cntext parms to agents and so on). The only time I'll use "treat as" now is when I'm doing stuff that Notes "doesn't do", or when the content-type is something other than HTML.
@Stephan: Yup! We came up with the exact same solution to get the first entry into the body.
Just didn't know if it was something to mention.
Jake,
I think by providing the base html that domino generates, you have done all you need to do. From that, the CSS that clear:left creates should be able to accomodate any anomalies from the extraneous domino html.
Maybe I don't understand this whole quirks / strict mode thing, but if I write my CSS to the W3C standard, isn't it irrelevant if I am in strict or quirks mode? I thought this was only as issue for the opposite case, where I originally wrote sloppy CSS, and then tried to render it in strict mode? Am I missing something?
I posted that blog and did a runner for the day...catching up now. Thanks for all your feedback!
@Richard. Probably, yes. But don't lose any sleep over it.
@Mark/Steve. When thinking about doing stuff like that I start wondering what the point of using Domino at all is.
@Jason. I can't remember exactly but there *is* a difference when you have the same CSS, no matter how correct, but different doctypes.
Jason, the most noticeable difference between quirks and standard compliant mode in IE is, that IE has treats the box model wrong, when in quirks mode.
According to CSS 2 standard, margin and border do not account to the width of an object, so the overall width is margin-left + border-left + width + border-right + margin-right. When in quirks mode, IE substracts margin and border from the object's width, which might have quite a massive influence on your design, even (or especially) if your CSS is absolutely fine.
Furthermore, in standard compliant mode IE no longer knows some of it's proprietary extensions, like the use of JavaScript expressions in CSS (which won't bother you, of course, if you stick with standard compliant CSS).
Jake,
The others kind of mentioned it already, but in Domino you do have full control over the HTML output, including the doctype, without using agents or pre-generated documents that contain the HTML.
Many argue that this beats the purpose of using Domino at all, but I disagree. Many developers, and I believe you are one of them (looking at your example databases), are using pass-thru HTML everywhere. If this is so, the next step to full (X)HTML output control is rather small.
I build my own Domino blog template this way, and it's output is a 100% XHTML. An article describing the technique can be found here:
{Link}
Don't forget one little item. Domino automatically generates the text and bgcolor attributes on the <BODY> tag. I know the guys at clear:left are into standards, and these attributes are not part of XHTML or HTML4.01.
This always annoyed the heck out of me, but in the end you have to take the good with the bad, don't you?
Also, I have always turned "use javascript ..." off in my databases to tighten up the code as suggested by Bo.
@Anura - this is probably a really dumb question but how do you get rid of the automatically generated "submit" button when in edit mode if you turn off "use javascript..."?
Colin. I've been doing some testing of a database with "use javascript" turned off, to see how feasible it is. To hide the button that Domino generates there are several method. All described here - {Link}
Thanks Jake - I've seen that site before but it made little sense to me at the time. Now that I've removed my button using a "hack", I wonder if the cure isn't worse than the desease?
Colin. This will be the subject of my blog tomorrow. Is the cure worse than the disease? I don't think so. I used the hack whereby an empty button is added to the form. It doesn't appear in the HTML at all - just as an ugly reminder when I look at it in Designer. The trade off is to have hardly any JS on the page and no needless Form elements. Definitely worth it!
Hi Jake, I've been tasked to update a classic Notes Web database... Expect to see me lurking around Codestore.
Kudos for leaving the resource online!
Hope you're doing well.
Hi Andrew. Long time!
I'm doing well thanks. Busy learning and doing all sorts of stuff. Mainly Angular. Not done any Domino work for ages now.
The kudos should go to Prominic.net really as they continue to host the site free of charge.
Jake, can blog about stuff other than Domino? I'd love to read about what you are doing in Angular.
Hey Jake, your blog is still here!
After a 10 year hiatus, I am delving back into Domino briefly.
On a project to migrate Notes data in SQL, which will be consumed by SharePoint at some point.
Cheers John