PreviousNext…

Well I never 25 Feb 2004

During the course of testing the recent site tweaks, I learned something new about the Domino HTTP task — specifically, how the server renders embedded views on the web. It’s puzzled me for some time why Google doesn’t seem to index individual weblog posts on this site (articles and the front page are fine), despite my best efforts with robots.txt and meta tags. Well, all is now clear. I swear I wasn’t aware of this before: if a view is rendered within a $$ViewTemplate form, Domino assumes that you don’t want the content indexed. In other words, this gets inserted at the top of your HTML:

<meta tag="robots" content="noindex">

There’s nothing the coder can do about this, and it overrides any meta tags one may subsequently create. The approach does make sense in general terms — why would anyone want to index an ordinary dynamic view? — but my issue with it is the lack of control over the tag’s insertion. Why do these things have to be “all or nothing”? There are valid reasons for wishing to override this setting. Take benpoole.com: the whole site is predicated upon the concept of the Domino-rendered view. You are reading this content from a view, whether you’re on the home page, or viewing via the permalink. Unlike most Domino weblog designs, readers do not see posts here as conventional Domino documents. So, a dilemma! Thankfully, there is a work-around.

Instead of opening the view within its template thus: …/VIEWNAME?OpenView, do this:

…/$$ViewTemplate%20for%20VIEWNAME?ReadForm

Ugly eh? Same end-result, just nastier URL. However, this is now what I’m doing on this very site. I use Domino Developer Network’s re-direction system already, so no great shakes.

I hope this is useful to someone. Who knows, come the next Google-dance, perhaps people will be able to actually find this wee nugget of information :-)

Filed under, , ,

Comments

  1. I had heard of the problem before, but not the work around. Thanks for sharing this. While it doesn't effect my site much, I like to file away these nuggets so when people complain on the Gold forum or BP forum or in person at a conference, I have an answer.Ben Langhinrichs#
  2. I found a discussion mentioning this issue on the Gold forum from some time back, and discovered that some muppet called Ben Poole had contributed… sheesh. My memory.

    Another discussion about this setting is here.

    With regards the first link, one of the contributors was Tony Walters from whom we used to hear a lot — Tony, are you out there still?Ben Poole#

  3. Once you have decided to take the "?readForm" path many things are possible. In fact, this is the (not so easy) route to validation if that's a developer's goal. I have a drafted article about this, but this seems like as good a place as any to spill these beans…

    The readForm command will give you complete control over the HTML produced by Domino, aka 'nada'. Really. At this point you might as well set the Form property 'Content type = html' (second tab) and begin building all your own stuff, including valid xhtml1.1.

    Once you have done this you no longer need the ?readForm command for views, you can simply hit the same 'xyz?open&restrictToCategory=Lotus' as before.

    I have found the only place I need to use ?readForm explicitly is is for some specific forms, like an 'About' page. In fact, Ben, the error you received and told me about last week was because of this. The link still had '?openForm'.

    This causes an error because one cannot open or edit a form whose Content-type is set to 'HTML' (as above).

    Of course, this makes for other issues, such as editing and creating entries, but I have found it useful to do some form switching in views.

    I'll stop here, but this entry of yours has spurred me on to finish the article I have. I can share a lot more stuff then.

    Thanks as always, Ben, for the great content.

    AndrewAndrew Barker#
  4. To put it in British terms: Domino HTML Generation is pants!

    (I hope I got that right ;-))

    Seriously though, I don't let Domino do *any* of the markup for me if I can help it. I create the Treat Contents as HTML-view "view.html|view" and then a "$$ViewTemplate for view" and set that to "treat contents as HTML" and run from there. I am able to get great results in which I have complete control over and (when the application is completely designed like this), I can dynamically create what's normally static page-type design element information that the Domino HTTP task will still cache and offer at the 130 PPS (I think that's what the reported offering was) all without touching the designer client.

    Sure, setting up something like that takes more development time up front… but you're giving the user or app admin the proper tools to do the job without coming to you because they want "the last 10 docs instead of the last 5" or "this to be blue instead of red", etc.!Chris Toohey#
  5. You got it right ;-)

    I must admit, much of this site uses hand-rolled pass-thru HTML, rather than the default Domino stuff. But then I am very anal…Ben Poole#
  6. I hate passthru HTML. There are a few things that are hard (or impossible) to accomplish with standard Domino, but moving to passthru HTML leaves a horrid mess behind too much of the time. Just my opinion, mind you.Ben Langhinrichs#
  7. Heh heh. Well, I use it all over the place in my $$ViewTemplates and so on. It looks like crap in Domino Designer, but then that’s HTML for you.

    That’s the only “mess” I see, and I certainly don’t use pass-thru in general documents. Just normal HTML :-D

    The key thing that most templates use pass-thru for, I would hazard a guess, is to generate additional HTML forms in strange places (e.g. this very form I’m filling in now, which is actually within a view). That’s something that Domino just doesn’t do.Ben Poole#
  8. Ben (L) #6 -

    Well, I 'spose it depends on how 'horrid mess' is defined. I do not find it assaulting my senses any more than a lengthy piece in a script library, really. Something to get used to and comfortable with, like anything else we do.

    In fact, almost all of my html is generated / maintained in views, business rule documents, and subforms (a trick I took to heart from Mr. Howlett). The subforms I can even set to computed so that they take up no room on the form itself, other that its singular line "Computed Subform".

    Then , ala Mr. Poole, all of my entries are written using html. Well… almost. (I'll have more to say about that later.)

    I also find it helpful for using non-Domino forms (though I have not tried generating any in a view, at least on my site… very cool, Ben) as well as generating my own content and the like. Basically, I have learned a lot more about this medium since I have taken this approach.Andrew Barker#
  9. Hi Ben,
    simple "HTML" content type of the form can solve this problem.

    Fabian#
  10. Hmm. Yes, but I like my $$ViewTemplates to use Domino functionality: hidden fields, look-ups, and so forth. I think I lose this if I set the form to a straight HTML content type.

    Could be wrong though… I’ve not tested that with view templates.Ben Poole#
  11. All $$ViewTemplates functionality like: hidden fields, look-ups, … works fine. At least for us …
    :-)Fabian#
  12. Fixed your link Fabian!

    Hmmm… you’ve got me thinking now… Glad to see the Gecko fix is high on your list BTW! ;-)Ben Poole#
  13. "With regards the first link, one of the contributors was Tony Walters from whom we used to hear a lot — Tony, are you out there still?"

    Yes, although I no longer work in Notes/Domino full time. I'm easy to find; if you google tony walters, my personal website comes up as the first result, which is nice!

    I only found your mention of me by gooling tony walters weblog as a test. I still read codestore.net, notestips.com and benpoole.com from time to time.Tony Walters#

Comments on this post are now closed.

About

I’m a developer / general IT wrangler, specialising in web apps, the mobile web, enterprise Java and the odd Domino system.

Best described as a simpleton, but kindly. Read more…