I was very happy and surprised, when I found your blog site (www.codestore.net).

It is a very interesting and helpfull site for webdomino designers.

I have some problems with the domino views and I found solutions for those on your blog site.

May I have a question to you: Where could I download the (viewform.nsf) example file?

..and please, updating the link of your donate.

Many thanks,

Zoltan

Please, I would like to know if you can help me How Can I do your cathegorized view by LastName(alphabetic list) ?...because I'm building something similar but with countries............

1000 thanks,

Carlos.

Do you know how to catch this?

Thanks in advance

A one form design is easily acheivable although it has the downside of old "max lines" problem to contend with.

$$ViewTemplateDefault allows you to get around the max lines problem with some sensible computed navigation links and generally works fine except for one of Domino's idiosycracies (is that spelt correctly?)

This being the inclusion of <meta name="robots" content="noindex"> which is automatically inserted by the server when it displays a "view". Whereas a form (or page)with an embedded view has no such annoying html inserted into it.

Why annoying ? Because use of $$ViewTemplateDefault seems to stop Google indexing a site and that is the only significant difference I can see

I understand. No views at all.

Why not app.nsf/0/unid?opendocument then ?

Mark

example app.nsf/myview/dockey?OpenDocument

I don't want someone to be able to access app.nsf/myview?OpenView

I didn't realize you could disable the view for web access and still use it for lookups on web based forms. Thanks!

Yes, two $$VT will work.

I like the idea of having one form for each type or category of information. I can see that this would be very useful in many apps.

I look forward to seeing the article.

Ethan

After considering your common scenario ;-) I still don’t see why you don’t use $$ViewTemplateDefault for your customer views, 1 $$ViewTemplate for admin and hide the lookup views from the web if you have a concern for people trying to open them.

Making sure only the views you actually want visible on the web is good practice. Trawl through all of those crazy lookup views and use the design properties box – your lookups will still work.

Jake I am not sure how having a separate form is any different to the $$ViewTemplateDefault after all it is a form isn’t it ? I can understand if you want to use editable fields but you could do this anyway couldn’t you as in your Simple Search box.

One other thing, I understand some search engines are not overly happy following parameterised URLs which could lead to problems (if this is important to you).

Mark

Great idea, I had tried this once before but couldn't get it to work, seeing your comment lead me to do try it again. It appears (6.5 client/server) that it only works if you use the generic name as the first alias. This makes it hard to see your real alias name in designer because it only shows the first alias name in the view listing.

For those questiong why not just use $$ViewTemplateDefault consider this common scenario:

I have a 100% web based applications with ~10 views for the customer side of the app, these are (now) displayed using $$ViewTemplate for cust, There is also an admin side that is (now) displayed with $$ViewTemplate for admin, $$ViewTemplateDefault is the same form as $$ReturnGeneralError to help secure lookup views from being exposed.

All of my views have three names 1)User Friendly 2)View type (cust,admin,sys) 3)Alias for script access.

The only minor drawback is that if you want to NOT use the $$ViewTemplate for cust you have to remove the cust alias. I tried using $$ViewTemplate for User Friendly and $$ViewTemplate for ScriptName to override the $$ViewTemplate for cust, neither worked.

If you have one of these views set to prohibit refresh design, all of the views will not update if you needed to push a change.

I think the opportunities here are in

* cleaning up your URLs,

* consolidating your design, and

* avoidance of being overly reliant on server side processing of query args which add a smidge to performance drag.

Keeping those goals in mind, as Jake says, there are more than one way to skin a cat - use what suits your situation best.

Christopher. AJAX is very cool. Although I don't think rendering a view is putting it to its best use though. Use AJAX where nothing else will do. Don't use it for the sake of it.

Why not AJAX? I am doing a similar functionality using AJAX and it just plain rocks!

@Yogi, you are going to have the same issue no matter what approach you take. Your application is either secure or it is not. I never have an "ALL" or "(ALL)" view.

Cheers!

@Chris H. - $$ViewTemplateDefault should never be used to control access to documents. There are just too many ways to easily bypass.

instead of using ?ReadForm, why not open a document. You could create 2 forms (one for the client, one for the web) and then configure all aspects of the view to show

- coloring

- menu at left/right

- text around etc

From the values entered in the form you compute the html that gets displayed around the view..

PM me for the sample DB...

;-) stw

Greg's method of one common alias sounds a lot tidier and is the kind of approach I'd prefer to use. However, there are other aspects to my method that I want to talk about, which are useful. As always there's more than one way to skin a cat.

YoGi. If a view needs to be secure it should be secured.

What if you got - like most of notes databases - an "All" view, through which people might discover sensitive data ? I guess it can lead to security issues.

Just put a nice message there instead of a view, like "Oi bog off and stop trying to open something your not supposed to!!"

Ok, maybe not quite that phrase...

Surely the best solution is the $$ViewTemplateDefault for all of the default views then just add additional $$ViewTemplates for special cases.

Mark