IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

Update on 3/3/08: attached sample database containing the "generic default form" instead of the DXL of the form; this should be easier to use.
In best practices lists for Domino development, I've often seen the recommendation that you should designate a default form. I've been thinking about that, and it doesn't seem like a good idea to me.

If you set a default form to one of your regular forms used for editing documents, and try to open a document that contains an unrecognized Form value, you first get an error message ("Cannot locate form: formname"), then the document opens using your default form. Since the chances of a random document matching the fieldnames on the default form is fairly small, probably all or most of the fields are blank.

If there's no Form field, the default form opens with no error message, so the user has no hint that there's a problem except for the odd blank fields. There's no message to look up to see what it means.

I think this sequence of events will not suggest the real problem to a typical end-user; viz, that someone pasted in this document from another database and we don't know what to do with it. Furthermore, the user could do some harm by going ahead and editing the document, producing a document that looks OK but has many fields not visible in the UI -- wasted space.

What happens if you don't have a default form is not terribly user-friendly either, but at least they aren't allowed to edit the document to produce a Frankendoc. If there's a form field, you get the same "Cannot locate form" message, then another message, "Cannot locate Default Form", then nothing -- it doesn't open. Still a bit cryptic for the end user, but at least they are unable to bull ahead and make things worse.

If you want to provide a friendlier UI, I think you need to define a special default form designed for the purpose. A sample database containing such a form is attached. This displays a user-friendly explanatory message, and a table showing all the items in the document, to give the user a clue where it might have come from.

Attachments: defaultformScreenshot.gif
Generic Default Form.zip
genericDefaultForm.dxl

Andre Guirard | 7 December 2007 01:00:00 PM ET | Plymouth, MN, USA | Comments (9)


 Comments

1) isn’t there something else...
Charles E. Robinson | 12/7/2007 3:25:19 PM

I can't remember exactly what, but I thought there was something else that required you to specify a default form or you get errors. I know that sending a doclink requires a default view or you get errors and I thought there was something similar about having a default form. Hopefully someone else will come up with that, or maybe it's a holdover I'm remembering from R5 or something.

P.S. I don't see any attachments. :-)

(Andre adds: oops! Forgot to put in the link. Try now.)

2) ... yes, there is something
Joerg Schlusemann | 12/8/2007 2:28:17 AM

NotesDocument.RenderToRTItem needs a default form for some (rare) situations

3) re: Default form, how necessary?
Andre Guirard | 12/8/2007 4:51:46 PM

@2: The facts of the situation are: RenderToRTItem and ComputeWithForm work fine if you set the Form field of the document, provided the form you specify actually exists. If you don't set the Form field, and there's a default form, it will use that form. Otherwise, you get the error "Special Database Object Not Located." I'm not sure what it does if you specify a form that doesn't exist.

I think the situation here is basically the same as for manually opening a document. Even if you select a default form, the chances of it being the right form to use for RenderToRTItem are fairly slim if you have multiple forms in your database. You really need to specify what form to use by assigning the Form field. I'd prefer to get an error message I could look up to find out what the problem is, as opposed to having it do the wrong thing with no explanation.

The most common situation where you might try to use RenderToRTItem and the Form field is blank, is when you try it on a document that's open in edit mode and has never been saved. Making that form the default form will avoid the error and make it work the way you intend, but so will adding the statement doc.ReplaceItemValue "Form", "somename" -- but you can only do the former with one form, and the latter still works if you copy the form to another application, so it's better for reuse.

4) Doclinks?
Julian Robichaux | 12/9/2007 9:50:41 AM

I seem to remember that creating doclinks with code (AppendDocLink or @Mailsend) gives an error if there's no default form defined. Could be only in certain situations (or older clients) though. I'll have to test around a bit.

5) same problems with default view
Patrick Kwinten | 12/10/2007 6:15:54 AM

I had the same problem just recently that I needed a default view assigned for a LS function (can't remember directly which one) but it took me some time to figure it out...

I hate such things....

Thanks for the tip, by the way!

6) Seems to be better as of R7
Julian Robichaux | 12/10/2007 1:23:01 PM

Update: I did some light testing, and can't reproduce the problem in R7. Maybe something that got fixed along the way. Here's a link to a technote that describes what I was thinking of:

{ Link }

Sadly, there's nothing on the technote that specifically says "Fixed in 7.0" (other than the fact that 7.0 isn't listed in the affected products list, which doesn't always indicate a fix).

7) re: Seems to be better as of R7
Andre Guirard | 12/10/2007 2:48:20 PM

I can see why the methods mentioned in the technote might need a default view, but why should they require a default form? And, based on a quick search of our databases, it doesn't appear that there has been a change to the NotesNewsletter class since 6.5.

It's true that the lack of a default form can lead to the same error message (as I said previously). But that it would do so in this situation doesn't make sense -- why would AppendDocLink care anything about the form, even if the form name were blank? All it needs to create a link is the UNID of the note and of a view (hence the need for a default view, in case the NotesDocument doesn't specify one). I think the technote was in error in implying that a default form could be involved in this particular case, and I've submitted a correction.

8) Very good idea
Fabian Robok | 12/11/2007 2:41:43 AM

Sometimes life is amazing. For all of your (Notes) developer life you've been told, that having a default form is good practice ... until someone stands up and asks "why?".

If all potential bugs are sorted out, you are absolutely right: Making one of your standards form the default form must be considered worst practice.

9) Description or request
Ron Kats | 1/9/2008 6:09:54 AM

I am very interested in the form, but cannot import the dxl (we use domino designer 6.5.6). Could you explain to me how the form is made or provide a dxl for 6.5.6?

My e-mail address famkats AT gmail DOT com

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact